The layered stack

Every diagram of Android looks like a layer cake, and every one of them is slightly different. The reason is that "a layer" is not a visual convention: it marks a boundary where one part of the system can be replaced without the other side noticing. Learn the boundaries, not the boxes, and the whole platform becomes easier to reason about.

TL;DR#

• Android has seven practical layers: kernel, HAL, native libraries and daemons, the Android Runtime, the framework and its system services, system apps, and your apps.
• Each layer is written in different languages and lives in different processes. The kernel is C; the HAL is C++; the runtime is C++; the framework is Java and Kotlin; system apps are APKs.
• The interfaces between layers are the important part: Binder between processes, the vendor interface between framework and hardware, and the SDK API between the platform and your code.
• Android is not a single product. AOSP is the open platform, GMS adds Google's apps and services, and the vendor stack makes it work on a specific phone.
• The layer boundaries are also the update boundaries. Treble split vendor from system, Mainline ships individual modules through Play, and GKI shares one kernel across devices.

Mental model#

Picture a restaurant.

The kitchen equipment is the kernel: burners, refrigeration, plumbing. Nobody dining thinks about it, but nothing works without it, and the equipment determines what dishes are possible.

The suppliers and delivery systems are the HAL. The restaurant does not raise chickens; it receives ingredients through a standard interface — crates with labels. If a supplier changes brands, the kitchen does not need to change its recipes.

The kitchen staff and their routines are the native libraries and daemons: the line cooks, dishwashers and stock systems that turn ingredients into plates.

The head chef is the Android Runtime: the person who decides how a recipe is actually carried out, adapting it to the equipment available.

The front of house and the menu is the framework. It is the interface the customer actually sees, and it is the only part they negotiate with.

The dining room is the apps.

Where the analogy breaks#

Restaurants have one chef; Android has a runtime in every app process. The Android Runtime is not a central authority that runs your code — it is a library the platform links into each process, the same way the kernel is not "called", it is there. That is the biggest mental correction to make: the lower layers are not services you request, they are environments you run inside.

The big picture#

The slider on that diagram steps through five moments in the platform's life. Watch what changes: the core stack is remarkably stable, and the changes are all about boundaries — the vendor interface appears in 2017, Mainline in 2019, GKI in 2020.

Deep dive#

Layer 1 — the Linux kernel#

The kernel does four jobs for Android: it schedules threads on cores, manages memory (including the out-of-memory killer's co-conspirator, lmkd), provides device drivers, and enforces security through UIDs and SELinux. It is written in C, with Rust being added for new code.

Android adds a handful of kernel features, and their fate is a useful story in itself. Binder, the IPC driver, was upstreamed. Ashmem became memfd. The in-kernel low-memory killer became a userspace daemon. Learn that pattern and you understand how Android matures: the Android-specific hacks either get upstreamed or get replaced by standard mechanisms.¹

The kernel is also where the "one kernel for all devices" problem lives, which is why GKI exists.

Layer 2 — the HAL#

A hardware abstraction layer is a contract between the framework and a piece of hardware. The camera HAL says "here is how you request a capture and receive a result"; it does not say how the sensor works. The HAL for a given device is written by the SoC vendor or the OEM, so it is the most device-specific code on the phone.²

This is the boundary that Project Treble formalised. Before Android 8.0, "the HAL" was often a shared library loaded into the framework process, meaning vendor code and platform code ran together. After Treble, HALs became separate processes behind a versioned interface, with a manifest declaring what each side provides.

Layer 3 — native libraries and daemons#

This layer is C and C++: the C library (Bionic), the graphics compositor (SurfaceFlinger), the init process, the media and audio servers, and a long list of smaller daemons. Each of the daemons is usually its own process, started by init, with its own SELinux domain.

The important idea here is that most of them are not part of your app's process. When your app plays audio, the mixing happens in audioserver; when it draws a frame, composition happens in surfaceflinger. Your app talks to them through Binder and shared memory.

Layer 4 — the Android Runtime#

ART executes your Kotlin and Java. It is not a central daemon: it is a library loaded into each app process, along with a copy-on-write view of the classes Zygote preloaded. It compiles DEX bytecode, runs the garbage collector, and provides JNI for native calls.³

The runtime layer is also where Zygote lives, which is arguably the single most important design decision in the platform's performance story.

Layer 5 — the framework and its system services#

This is Java and Kotlin. It is split in two: the classes your app compiles against (the SDK surface) and the services that implement them, most of which run inside one process called system_server. A call like getSystemService(ACTIVITY_SERVICE) gives you a client object that forwards over Binder to a service in that process.

There are about a hundred of these services.⁴ They are the bulk of what people mean by "the Android framework".

Layer 6 — system apps#

SystemUI, the launcher, Settings, the phone app, the camera app. These are ordinary APKs that ship on the system image and hold privileged permissions. SystemUI draws the status bar and notification shade; the launcher is just an app with a home category. They can be replaced or updated, and their crashing is survivable in a way that system_server crashing is not.

Layer 7 — your apps#

Kotlin or Java, running in a sandboxed process, using the SDK. This is the layer everybody starts from, and the reason the rest of the stack exists.

The identities: AOSP, GMS, and the vendor stack#

Three bodies of software coexist on a shipping phone, and they are maintained by different people on different schedules.

	What it contains	Who maintains it	How it updates
AOSP	Kernel interface, framework, runtime, system apps, native stack	Google + the open-source community	OS updates, Mainline modules
GMS	Play Store, Play services, Google apps	Google	Play Store, Play services updates
Vendor/OEM	Drivers, firmware, HALs, OEM skin	SoC vendor and OEM	OEM OTA, sometimes never

That table is the reason "Android 17 is out" does not mean your phone has it. See AOSP vs GMS vs OEM for the full story.

How it evolved#

The stack has changed shape four times, always for the same reason: something needed to be updatable without updating everything.

The pattern across all of it is modularisation under pressure. Each era took a monolith and found a seam:

• 2008–2017: one stack, one update path, controlled by the OEM.
• 2017: Treble creates the vendor seam.
• 2019: Mainline creates seams inside the system itself.
• 2020: GKI creates the kernel seam.
• 2024 onward: the adaptive era, where the same stack serves phones, tablets, foldables and cars.

Under the hood#

The three files that best represent the layer boundaries:

• ‹›SystemServer.java↗where the framework's services are born, in phases
• ‹›SystemServiceRegistry.java↗the map from Context constants to manager objects — the client side of the framework boundary
• ‹›README.md↗the init language that starts the native layer

Curiosity corner#

• The stack diagram is older than most of the blocks in it. The five-layer picture has been redrawn for every release; the bottom three layers have been roughly the same for fifteen years.
• Android's kernel is "Linux but not GNU/Linux". No GNU coreutils, a different C library, a different init. The kernel is Linux; the userland is Android.

Try it#

Check yourself#

Check yourself

1 / 12

You run `adb shell ps -A` and see that `system_server` and your app share the same parent process. What is the parent?

initzygote64servicemanagersurfaceflinger

Sources#