Android Operating System Architecture Part I: AOSP, Linux Kernel, GKI, HAL and Android Runtime

A technical examination of the foundations beneath Android—from AOSP and the Linux kernel to Android Common Kernels, Generic Kernel Image, hardware abstraction, native components and Android Runtime.

Category: Mobile Operating Systems / Android / Operating System Architecture

Updated: August 17, 2026
Reading Time: 10 minutes

In One Sentence

Android is a layered operating-system platform built around AOSP, aLinux-based kernel, hardware abstraction interfaces, native system components and Android Runtime, with these layers providing the foundation on which Android Framework services and applications operate.

Key Highlights

AOSP — the Android Open Source Project — provides the open-source implementation of the Android platform.
Android’s core architecture includes applications, the Android Framework, system services, Android Runtime, native daemons and libraries, HALs and the kernel.
The Android kernel is based on Linux and uses Android Common Kernels (ACKs).
Modern Android kernel architecture uses the Generic Kernel Image (GKI) approach to separate generic kernel code from hardware-specific vendor modules.
The Hardware Abstraction Layer (HAL) provides standardized interfaces between Android and hardware-specific implementations.
AIDL is now the preferred interface technology for new HAL implementations, while older HIDL-based HALs remain supported.
Native daemons and libraries provide critical low-level functionality used by Android’s higher layers.
Android Runtime (ART) provides the managed runtime environment in which Android application code executes.
Binder provides Android’s principal inter-process communication mechanism, with AIDL used to define many Binder interfaces.
The lower layers are deliberately designed to hide hardware-specific complexity from applications and higher-level framework components.

Introduction: Android Begins Long Before the Home Screen

When consumers say that a smartphone “runs Android,” they usually mean the visible software experience: the launcher, Settings application, notifications, applications and user interface.

Technically, however, the Android operating system is vastly more complicated.

The visible interface is only the uppermost part of a large software architecture that connects application code to processors, memory, cameras, displays, sensors, storage, networking hardware and security mechanisms.

The current Android Open Source Project architecture identifies a number of major layers and components, including the Android Framework, system services, Android Runtime, native daemons and libraries, hardware abstraction layers and the kernel.

Understanding those layers is essential if Android is to be treated as a serious operating-system subject rather than simply a smartphone brand or user interface.

A useful conceptual model is:

ANDROID APPLICATIONS
        │
        ▼
ANDROID FRAMEWORK
        │
        ▼
SYSTEM SERVICES
        │
        ▼
ANDROID RUNTIME
        │
        ▼
NATIVE DAEMONS & LIBRARIES
        │
        ▼
HARDWARE ABSTRACTION LAYER
        │
        ▼
ANDROID COMMON KERNEL / LINUX
        │
        ▼
DEVICE HARDWARE

This is a conceptual representation. Actual Android implementations involve multiple processes, IPC mechanisms, vendor components and specialized subsystems.

1. What Is AOSP?

AOSP stands for Android Open Source Project.

It is the open-source project through which Android platform source code is developed, maintained and made available for device manufacturers, developers and contributors.

AOSP’s official site describes the project as the place to develop, customize and test Android devices.

AOSP is therefore not simply an Android source-code archive.

It is the foundation through which the Android platform is engineered.

However, an important distinction must be maintained:

AOSP is not synonymous with every commercial Android smartphone implementation.

A commercial device can combine AOSP-derived platform software with:

vendor hardware implementations;
proprietary drivers and firmware;
Google services where licensed and available;
manufacturer applications;
manufacturer user interfaces;
proprietary AI systems;
device-specific services;
additional security mechanisms.

Consequently, a Samsung, Xiaomi, vivo, OPPO or OnePlus device can all be Android-based while presenting very different software experiences.

2. Android as a Layered Platform

AOSP’s architecture documentation provides the authoritative conceptual foundation for understanding Android.

The major layers include:

Applications
Android Framework
System Services
Android Runtime
Native Daemons and Libraries
Hardware Abstraction Layer
Kernel

Each layer has a different responsibility.

The kernel manages fundamental operating-system resources.

The HAL creates hardware interfaces.

Native libraries and daemons provide low-level functionality.

ART executes managed application code.

System services provide privileged operating-system functionality.

The Framework exposes APIs and abstractions.

Applications consume those APIs.

3. Physical Hardware: The Layer Beneath Android

Although hardware is technically outside the Android software stack, it is where the entire architecture ultimately terminates.

A modern smartphone can contain:

CPU cores;
GPU;
NPU;
ISP;
modem;
RAM;
flash storage;
display controller;
camera sensors;
microphones;
speakers;
Wi-Fi;
Bluetooth;
GNSS;
NFC;
fingerprint hardware;
accelerometers;
gyroscopes;
proximity sensors;
power-management components.

Different Android devices can use dramatically different implementations.

A Qualcomm-powered phone may have different graphics, modem and AI hardware from a MediaTek-powered phone.

Yet Android applications are expected to function through common software interfaces.

That is one of the central architectural problems Android solves.

4. The Linux Kernel

The Linux kernel forms the foundation of Android’s kernel layer.

The kernel provides fundamental operating-system capabilities including:

process management;
CPU scheduling;
memory management;
device-driver interfaces;
networking;
power management;
security mechanisms;
hardware access.

Android is therefore built on Linux, but Android should not be confused with a conventional desktop Linux distribution.

Android adds a large platform above the Linux kernel, including:

Android Runtime;
Framework APIs;
system services;
Android-specific security architecture;
HAL interfaces;
application sandboxing;
Android package and lifecycle systems;
mobile-oriented power and resource management.

The distinction is therefore:

Linux kernel = foundational kernel technology

Android = complete operating-system platform built around that foundation

5. Android Common Kernels

Modern Android kernel development uses Android Common Kernels (ACKs).

AOSP documentation describes ACKs as Android kernels that are downstream of upstream Linux LTS kernels and contain Android-specific changes.

This approach is important because Android devices need both:

compatibility with the Linux kernel ecosystem;
Android-specific kernel functionality.

The result is an architecture that combines upstream Linux development with Android-specific requirements.

6. Generic Kernel Image

One of the most important developments in modern Android kernel architecture is Generic Kernel Image, or GKI.

The GKI approach is designed to separate generic kernel functionality from hardware-specific vendor modules.

Conceptually:

GENERIC ANDROID KERNEL
        │
        ├── Generic Kernel Image
        │
        └── Generic Kernel Modules
                 │
                 ▼
        Vendor-Specific Modules
                 │
                 ▼
             Hardware

The significance is architectural.

Android can maintain a more standardized generic kernel while allowing device manufacturers and silicon vendors to provide hardware-specific components separately.

This separation is intended to reduce kernel fragmentation and make long-term kernel maintenance more manageable.

7. Hardware Abstraction Layer

Above the kernel is the Hardware Abstraction Layer, or HAL.

A HAL provides a standardized interface that allows hardware vendors to implement device-specific functionality without requiring higher layers to understand the details of the underlying hardware.

Consider a camera.

An application should not need to know:

which sensor manufacturer produced the sensor;
which ISP is used;
which vendor driver controls the hardware;
which electrical interface connects the components.

Instead, the higher Android layers interact with standardized camera interfaces.

Conceptually:

Camera App
    │
    ▼
Android Camera Framework
    │
    ▼
Camera HAL
    │
    ▼
Vendor Implementation
    │
    ▼
Kernel Driver
    │
    ▼
Camera Hardware

This abstraction is fundamental to Android’s hardware diversity.

8. AIDL and Modern HAL Architecture

The HAL architecture has evolved significantly.

AOSP documentation states that HIDL was deprecated as of Android 13 for HAL development, and recommends AIDL for new HALs. Existing HIDL HALs continue to be supported.

AIDL — Android Interface Definition Language — provides a mechanism for defining interfaces used for inter-process communication.

AIDL can generate bindings for different programming environments and is used extensively in Android’s modern platform architecture.

For new HAL development, this means the modern conceptual model should emphasize:

AIDL-defined interface → HAL service → vendor implementation → hardware

rather than presenting HIDL as the current primary architecture.

9. Native Daemons and Libraries

Android also depends heavily on native components.

AOSP’s architecture documentation identifies native daemons and libraries as an important layer of the platform.

Examples include components responsible for:

system initialization;
logging;
storage;
IPC;
security;
native system utilities;
graphics;
media;
networking.

Native libraries are particularly important for functionality where performance, hardware access or low-level system integration matters.

Android’s native layer therefore provides much of the machinery connecting the higher platform to the underlying operating environment.

10. The `init` Process

One particularly important native component is init.

The Android boot process requires a process responsible for early userspace initialization and launching essential system components.

init participates in:

mounting required filesystems;
setting up system properties;
starting services;
establishing permissions;
initializing the Android userspace environment.

It is therefore one of the first major userspace components involved after the kernel begins execution.

The exact boot sequence varies by Android generation and device implementation, but init remains a central part of Android’s userspace architecture.

11. Binder IPC

Android is a multi-process operating system.

Applications and system components frequently need to communicate across process boundaries.

Android uses Binder IPC as a principal mechanism for this communication.

AOSP’s current Binder documentation recommends AIDL for defining interfaces that use Binder for IPC, and notes that HIDL is deprecated for new implementations.

Conceptually:

Process A
    │
    │ Binder IPC
    ▼
Process B

This allows Android to separate components into different processes while still permitting controlled communication.

Binder therefore contributes to both:

system architecture;
security boundaries.

15. Why the Lower Layers Matter

Most smartphone specifications focus on:

CPU;
GPU;
RAM;
cameras;
display;
battery.

But none of those components operates independently.

The operating system must coordinate them.

When a user opens the camera, the operating system must connect application requests to framework services, HALs, drivers and hardware.

When a game renders graphics, Android must coordinate application code, graphics APIs, native components, GPU drivers and the GPU.

When an AI model executes on an NPU, system software must coordinate the framework, runtime, accelerator interfaces, vendor components and hardware.

This is why the architecture matters more than any individual specification.

16. A Complete Hardware Request

Consider a simplified camera request:

USER
 ↓
CAMERA APPLICATION
 ↓
ANDROID FRAMEWORK API
 ↓
SYSTEM SERVICE
 ↓
BINDER IPC
 ↓
CAMERA HAL
 ↓
VENDOR IMPLEMENTATION
 ↓
KERNEL DRIVER
 ↓
CAMERA HARDWARE

The user experiences one tap.

The operating system executes a coordinated chain across multiple architectural layers.

This abstraction is the reason Android can support enormous hardware diversity.

17. Architecture and Device Diversity

Android’s global reach depends heavily on this layered approach.

Manufacturers can differentiate devices through:

processors;
cameras;
displays;
sensors;
storage;
modems;
power systems.

Yet they can still use the Android platform.

The HAL and vendor boundaries prevent every hardware change from requiring a complete redesign of the Android application environment.

This is one of the platform’s most significant engineering advantages.

Digital Plaza Analysis

The deepest architectural lesson is that Android’s flexibility is created by interfaces.

The Linux kernel establishes the foundational operating environment.

ACK and GKI provide an increasingly structured kernel architecture.

HALs separate hardware implementation from higher-level Android software.

AIDL provides standardized IPC interfaces for modern platform components and HALs.

Native libraries and daemons provide low-level functionality.

ART provides the managed application runtime.

None of these layers is Android by itself.

Together, however, they form the technical foundation on which the Android Framework and application ecosystem operate.

The modern architecture should therefore not be described simply as:

Linux → Android → Apps

That is far too simplistic.

A more accurate model is:

Applications
     ↓
Android Framework
     ↓
System Services
     ↓
ART / Native Platform
     ↓
AIDL / HAL Interfaces
     ↓
Vendor Implementations
     ↓
Android Common Kernel / GKI
     ↓
Hardware

This is the foundation Digital Plaza should use for future Android architecture coverage.