Home > Android Pentesting

Android OS Architecture (Kernel → HAL → Runtime → Framework → Apps)

Android OS architecture is a deep, multi-layered system that controls everything from low-level hardware operations to application-level behavior. Each layer has its own components, security boundaries, attack surfaces, debugging points, and pentesting considerations. A complete understanding of the architecture is essential for analyzing how apps interact with the system and where vulnerabilities may occur.

Linux Kernel Layer

The Linux kernel is the lowest layer of Android. It is responsible for managing hardware, memory, processes, security boundaries, and input/output operations. Every component above it depends on kernel functions.

Core responsibilities:

  • Memory management through virtual memory and process isolation

  • Hardware drivers for display, sensors, audio, camera, modem, storage, and input devices

  • Process and thread scheduling

  • Power management and wake locks

  • System call handling

  • Security mechanisms including SELinux, namespaces, and cgroups

Android modifies the standard Linux kernel with additional patches to support features like Binder IPC, wakelocks, and ashmem. Binder is one of the most critical subsystems because it controls communication between processes. Every major system service and application uses Binder transactions.

SELinux enforces strict access control policies on all processes. This prevents unauthorized actions even if an application is compromised. Pentesting often requires examining SELinux contexts, checking Binder interactions, analyzing driver exposure, and identifying improper access controls.

A rooted device allows inspecting kernel logs, module configurations, and file system structures. Kernel-level misconfigurations can affect the entire device, making this layer the highest-value target but the most restricted under normal conditions.

Hardware Abstraction Layer (HAL)

The Hardware Abstraction Layer acts as the translator between hardware-specific drivers and higher-level Android services. It exposes hardware features through standardized interfaces so the system can run on diverse devices without modification.

Each hardware component has a HAL module responsible for implementing functions defined by Android’s hardware interface definition language.

Common HAL modules include:

  • Camera HAL controlling all camera operations

  • Location HAL handling GPS and GNSS data

  • Audio HAL managing input and output devices

  • Sensors HAL providing accelerometer, gyroscope, and other sensor data

  • Wi-Fi and Bluetooth HAL for wireless communication

  • Biometrics HAL for fingerprint and face authentication

Apps never interact with HAL directly. All access occurs through framework APIs, which internally communicate with HAL modules via Binder. A flaw in a HAL module affects all apps that rely on that hardware feature. Misconfigured HAL modules can expose sensitive sensor data or provide unintended behavior that attackers can abuse.

Pentesters analyze HAL interactions by monitoring system logs, inspecting Binder transactions, and tracing calls between the framework and HAL modules. On rooted devices, HAL behavior can be inspected more deeply by examining hardware interfaces allocated in system partitions.

Native Libraries and Android Runtime

Above HAL lie native libraries and the runtime. They provide essential capabilities that the system and apps depend on.

Native libraries include:

  • Bionic libc, Android’s lightweight C library

  • OpenGL ES for graphics rendering

  • WebView libraries for embedded browser functionality

  • SSL/TLS libraries for secure communication

  • SQLite for local databases

  • Media codecs for audio and video processing

These libraries are written in C or C++, making them susceptible to memory corruption vulnerabilities. When apps use native code through the NDK, they increase the attack surface because insecure JNI calls can lead to code execution.

Android Runtime (ART) executes application code. ART compiles bytecode into native machine code ahead of time instead of interpreting it. ART manages garbage collection, memory allocation, class loading, and error handling. It contains core libraries that Java and Kotlin apps depend on.

Pentesting at this layer involves analyzing decompiled bytecode, reverse engineering native binaries, hooking runtime functions, inspecting class loading behavior, and mapping how apps call dangerous native functions.

Dynamic instrumentation tools such as Frida inject scripts into ART to override or inspect method calls. This enables bypassing certificate pinning, hooking cryptographic operations, and monitoring sensitive logic.

Application Framework Layer

The framework provides the high-level environment where application components operate. It exposes system services through API interfaces. System services communicate with HAL and the kernel, while apps communicate with system services.

Key system services include:

  • Activity Manager for controlling the lifecycle of activities

  • Package Manager for application installation and permissions

  • Window Manager for display operations

  • Telephony Manager for cellular operations

  • Location Manager for GPS and network-based location

  • Notification Manager for app notifications

  • Content Resolver for accessing shared app data

  • Bluetooth and Wi-Fi managers for wireless connections

Framework components that apps use:

  • Activities

  • Services

  • Broadcast Receivers

  • Content Providers

If an app misconfigures any of these components, it can expose attack surfaces. Examples include exported activities without permission checks, content providers leaking private data, or broadcast receivers accepting untrusted intents.

Pentesters must understand how system services enforce permission boundaries, how apps register components, and how intents are passed between components. Tools such as drozer help enumerate and exploit misconfigured components. Framework-level vulnerabilities are common because developers often misunderstand how component exposure works.

Application Layer

The topmost layer contains all Android apps, including system apps and user-installed apps. Each app runs inside a sandbox created using Linux user isolation. The sandbox includes a private file directory, isolated memory, restricted access to system resources, and permission-based access to sensitive features.

Applications interact with every layer below them:

  • They request permissions enforced by the framework

  • They store data managed by the kernel and native libraries

  • They execute code handled by ART

  • They use hardware features exposed through HAL

  • They rely on system services provided by the framework

Most vulnerabilities occur in the application layer due to insecure data storage, incorrect component exposure, poor authentication logic, weak cryptography, flawed network handling, or unsafe WebView configurations.

Each app’s manifest defines its structure, permissions, components, and security boundaries. Pentesters analyze the manifest, stored files, databases, logs, external storage use, and network interactions to identify weaknesses.

Since the application layer depends on all lower layers, understanding the underlying architecture helps trace vulnerabilities beyond the app itself.

Intel Dump

  • Android architecture has five major layers linked from kernel to apps

  • Kernel manages hardware, memory, scheduling, drivers, and SELinux

  • HAL exposes hardware through standardized interfaces

  • Native libraries provide critical OS functions in C and C++

  • Android Runtime executes app code using ART and core libraries

  • Application framework manages system services and component interactions

  • Applications form the top layer and introduce most real-world vulnerabilities

HOME LEARN COMMUNITY DASHBOARD