The Android Software Stack

The Android software stack is a highly structured, multi-layered architecture designed to support a vast ecosystem of mobile devices. Understanding this stack is the most fundamental prerequisite for any AOSP developer, as it defines how high-level Java/Kotlin code eventually interacts with the underlying silicon.

Android is built upon five primary layers. Let us explore each layer from the bottom up.

1. The Linux Kernel

At the very bottom of the Android software stack lies the Linux kernel. Android relies on Linux for core system services:

• Hardware Drivers: Display, camera, Bluetooth, audio, and memory flash drivers.
• Memory Management: Allocating RAM and handling out-of-memory (OOM) situations.
• Process Management: Scheduling CPU time across thousands of threads.
• Security: Utilizing Linux user permissions and SELinux for strict access control.
• Power Management: Handling device sleep states and wakelocks to preserve battery life.

The kernel acts as an abstraction layer between the device hardware and the rest of the software stack.

You can inspect the running kernel version and build date via ADB:

adb shell uname -a

2. Hardware Abstraction Layer (HAL)

Directly above the kernel sits the Hardware Abstraction Layer (HAL). The HAL provides standard interfaces that expose device hardware capabilities to the higher-level Java API framework.

• Why it exists: Hardware manufacturers (like Qualcomm, Samsung, or Sony) have proprietary ways of driving their specific hardware. The HAL standardizes these operations.
• How it works: The HAL consists of multiple library modules. When the Android framework makes a request (like "turn on the camera"), it calls the camera HAL API. The HAL module then translates this standard command into the proprietary instructions required by the specific kernel driver.
• HIDL/AIDL: In modern Android (post-Project Treble), HALs run in separate processes and communicate with the framework via Binder IPC using HIDL or AIDL definitions.

// Example: A simplified AIDL HAL definition for a Vibrator
package android.hardware.vibrator;

@VintfStability
interface IVibrator {
    void on(int timeoutMs);
    void off();
}

3. Native C/C++ Libraries and Android Runtime

This layer provides the core environment required to execute applications and fundamental system services.

Native C/C++ Libraries

Many core Android components are built using native C and C++ to maximize performance.

• Bionic libc: A custom, lightweight C standard library optimized for embedded Linux devices.
• SurfaceFlinger: The system compositor that merges 2D/3D graphics layers and outputs them to the display.
• Media Framework (Stagefright): Handles audio and video playback/recording.
• SQLite: The standard relational database engine used by Android apps.
• OpenGL ES / Vulkan: High-performance 3D graphics APIs.

Android Runtime (ART)

Since Android 5.0, the Dalvik Virtual Machine was replaced by ART.

• Execution: ART executes the Dalvik Executable (DEX) bytecode generated from Java/Kotlin source code.
• Compilation: It utilizes a hybrid compilation strategy, combining Ahead-of-Time (AOT), Just-In-Time (JIT), and Profile-Guided Optimization (PGO) to ensure apps run as efficiently as possible.

4. Java API Framework

This is the layer that application developers interact with directly. It exposes the underlying native libraries and hardware capabilities through a rich, standardized Java/Kotlin API.

The framework includes numerous services that run constantly in the background (primarily within the system_server process):

• Activity Manager (AMS): Controls the lifecycle of applications and manages the navigation backstack.
• Window Manager (WMS): Manages window focus, z-ordering, and transitions (working closely with SurfaceFlinger).
• Package Manager (PMS): Keeps track of which apps are installed, their permissions, and their cryptographic signatures.

As an AOSP framework engineer, the vast majority of your time will be spent modifying code within this layer (specifically inside the frameworks/base/ directory of the source tree).

You can dump the state of any framework service from the command line:

# Dump the Window Manager state
adb shell dumpsys window

5. System and User Applications

The topmost layer is the applications layer, which includes both pre-installed system apps and third-party apps downloaded from the Play Store.

• System Apps: Core applications that ship with the device (Dialer, SMS, Settings, Launcher). Crucially, these apps often have elevated permissions and use internal framework APIs that are hidden from third-party developers (annotated with @hide).
• Third-Party Apps: Applications installed by the user. These apps are strictly isolated in sandboxes and can only interact with the system via the public Java API Framework SDK.