Android architecture is a layered structure that defines how the operating system works from the lowest hardware layer to the highest application layer. Each layer has its own purpose, responsibilities, and security boundaries. A clear understanding of this architecture is essential for pentesting because vulnerabilities often arise from how applications interact with these layers.

Android is built on top of the Linux kernel. The kernel manages low-level operations such as memory management, device drivers, process scheduling, and power management. It enforces strict separation between processes through user IDs and permissions. This isolation prevents one app from directly accessing another app’s memory or files. SELinux policies further restrict what processes can do, reducing the impact of malicious code. Kernel-level vulnerabilities are severe because they can compromise the entire device.

The Hardware Abstraction Layer sits above the kernel. It provides a set of standard interfaces that allow Android to communicate with hardware components. Manufacturers implement HAL modules so that Android can use components like the camera, sensors, fingerprint readers, GPS, and Bluetooth without knowing the device’s specific hardware design. This modularity allows Android to run on thousands of devices. If a HAL implementation contains flaws, multiple system services and applications relying on that component can become vulnerable. Understanding HAL interactions helps pentesters map how hardware input flows through the OS.

Native libraries form the next layer. These include libraries for database handling, encryption, graphics rendering, machine learning, audio processing, video codecs, and other essential tasks. Examples include libc, WebKit, OpenGL, and SQLite. These libraries are written in languages like C and C++, which are prone to memory corruption issues. Android apps can call these libraries through the NDK, which increases the attack surface. Pentesters inspect native libraries for insecure functions, buffer overflows, and misuse in the application code.

Android Runtime is responsible for executing application code. Earlier versions used Dalvik, while modern Android uses ART. ART compiles bytecode into native instructions before execution, improving performance and security. The runtime includes core libraries that provide essential classes for Java and Kotlin apps. It also handles garbage collection, memory management, and exception handling. Pentesters analyze runtime behavior to understand how the app allocates memory, handles objects, and interacts with system resources. Issues such as unsafe deserialization, insecure class loading, and misuse of runtime APIs often occur here.

Above the runtime is the application framework. This layer provides high-level building blocks that developers use to build apps. It includes services responsible for managing activities, application lifecycles, notifications, resource access, location services, telephony, content providers, windows, and permissions. These components define how apps communicate with the system and with each other. Many vulnerabilities appear in this layer because misconfigurations in exporting components, handling intents, or using framework APIs can create security gaps. Pentesters focus on identifying which components are exposed, how intents are handled, and whether privilege boundaries are properly enforced.

The application layer is the topmost level of Android architecture. It includes system apps such as phone, contacts, settings, and messaging, as well as user-installed applications. Each application runs in its own sandbox, created using the kernel’s process isolation. The sandbox limits the app’s access to files, memory, and system resources. Apps must request permissions to access sensitive features such as location, microphone, and camera. Pentesters examine how apps request permissions, store data, handle inter-process communication, and manage sensitive operations. Most security issues originate in this layer because apps often handle sensitive data improperly or expose components unintentionally.

Android architecture is designed to provide layered security. Each layer depends on the lower layers while enforcing its own restrictions. Understanding this layered design helps pentesters trace how data flows through the system, identify weak points, and assess how vulnerabilities in one layer can impact others. A thorough grasp of the architecture is essential for performing effective static analysis, dynamic analysis, and reverse engineering of Android applications.

Intel Dump

• Android uses a layered design from kernel to application level

• Linux kernel manages memory, processes, hardware drivers, and isolation

• SELinux enforces security boundaries and reduces attack impact

• HAL provides hardware interfaces that manufacturers implement

• Native libraries offer database, graphics, media, and crypto functionality

• Native code increases vulnerability risks through memory-related issues

• Android Runtime executes app code using ART and core libraries

• Application framework manages activities, services, intents, and system APIs

• Application layer contains sandboxed apps that interact with the framework

• Most vulnerabilities originate from misconfigurations or insecure coding in upper layers