Skip to content

AOSP Architecture Explained: Apps, Binder, HAL, and Kernel

AOSP is easiest to debug when you follow a request across boundaries instead of treating “Android” as one layer. A typical path starts in an app, enters a framework API, crosses Binder to a service, reaches a HAL, and finally uses a kernel driver.

Quick answer

Apps use framework APIs; many framework services run in System Server; Binder and AIDL carry calls between processes; ART executes app bytecode; HAL interfaces isolate hardware-specific code; and the Linux kernel owns drivers and low-level resource management. AAOS extends this stack with automotive services and the Vehicle HAL.

The stack at a glance

flowchart TB App[Apps and privileged apps] --> Framework[Application Framework APIs] Framework --> SS[System Server and native services] SS <-->|Binder / AIDL| HAL[HAL services] App --> ART[ART runtime] HAL --> Vendor[vendor / device implementation] Vendor --> Kernel[Linux kernel and drivers] AAOS[AAOS: Car API and Car Service] --> SS AAOS --> VHAL[Vehicle HAL] VHAL --> HAL

Apps, framework, and System Server

Apps normally call Android framework APIs rather than device drivers. Many platform services—such as activity, package, window, and power management—are coordinated by System Server. The service boundary matters: a permission check, process crash, or Binder timeout can change the symptom even when the app code did not change.

When investigating a framework feature, record all of the following:

  • calling package and UID;
  • framework API and permission involved;
  • receiving service and process;
  • Binder or logcat error;
  • device/product build fingerprint.

Binder and AIDL

Binder is Android's inter-process communication mechanism. A client calls a proxy; the Binder kernel driver transports the transaction to the service process, which returns a reply. AIDL describes an interface that both sides use to make that IPC contract explicit.

For modern HAL work, prefer AIDL interfaces. HIDL remains supported for older interfaces but is deprecated in favor of AIDL.

1
App → framework manager → Binder proxy → Binder driver → service node → reply

This is why a feature can fail with an apparently local API exception even though the root cause is a service permission, a missing HAL registration, or a crashed vendor process.

ART and native services

ART runs Android application code and participates in installation, compilation, profiling, and runtime execution. Native daemons and system libraries cover areas where platform services need C/C++ code, low-level media, graphics, storage, or other facilities outside an app process.

Keep the runtime layer distinct from the hardware layer: moving code to native C++ does not grant a process access to a hardware device or bypass the HAL, SELinux, Binder, or permission model.

HAL, vendor, and Treble partitions

A hardware abstraction layer defines a stable interface between higher Android layers and hardware-specific implementation. A binderized HAL runs in a separate process and is discoverable through a service manager. This lets framework code target an interface while board and SoC code handle device details.

Android partitions make that separation visible:

Area Typical responsibility
system Common Android platform image and framework
system_ext System extensions associated with a product
product Product-specific configuration and resources
vendor SoC and board vendor implementation, including HAL-related code
odm Optional device-manufacturer customization
boot / init_boot Kernel and generic ramdisk arrangement, depending on Android version/device design

Do not edit a framework API merely to work around a board-specific driver or HAL failure. First establish which side of the interface owns the behavior and test the contract at that boundary.

AAOS: Car Service and Vehicle HAL

AAOS adds automotive-specific APIs and services while remaining Android. Car Service and Car APIs sit on the Android side; VHAL provides the defined boundary for vehicle properties in a vehicle integration. Android Auto is different: it is phone-based projection, not an OS image on the Raspberry Pi.

For a Raspberry Pi AAOS demo, keep the scope to UI, service behavior, interfaces, and logs. Treat real vehicle networks and actuators as out of scope.

Use the interactive map

The Android Architecture Map is designed for component discovery. Select a node to view its explanation, related components, interface diagram, APIs, and source links. The right-side panel contains a compact, labeled ad placement so that the map remains usable on desktop and mobile.

Use the map to form a hypothesis, then verify it against the source revision and runtime evidence. It is a navigation aid, not an authoritative replacement for the exact AOSP branch you build.

Debugging example: a hardware-backed feature

  1. Identify the app or privileged service that initiates the request.
  2. Identify its framework manager and required permission.
  3. Trace the Binder/AIDL interface to the receiving service.
  4. Verify the target HAL service is registered and alive.
  5. Inspect vendor implementation and kernel logs for the corresponding device.
  6. Change one boundary at a time and retain the before/after logs.

Primary references