Welcome to Zygote

You press an app icon. A few hundred milliseconds later a screen appears. Between those two moments, code written in Kotlin, C++, Java and C touches the kernel, a driver, the compositor, the input system, and half a dozen system services — all without one of them trusting the others.

Most explanations of Android stop at one layer. A tutorial for app developers starts at Activity and never mentions the zygote. A kernel patch notes that it changed a driver and never mentions the app that will behave differently. Zygote connects the layers. That is the whole idea.

TL;DR#

Android is a layered stack: a Linux kernel, hardware abstraction layers, native libraries and the Android Runtime, the Java/Kotlin framework with its system services, system apps, and your app. Each layer has its own language, process model and update story.
Every app is a sandboxed Linux process with its own user ID. Apps talk to each other and to the system through Binder, not through shared memory or files.
Every app process is forked from Zygote, a warm process that has already loaded the framework classes. That is why Android apps start fast despite having no main() of their own.
The system is designed to be updated in pieces: Treble splits vendor from system, Mainline ships individual modules through Play, and GKI shares one kernel across devices.
Android changes behaviour by API level. The same code can behave differently depending on targetSdk, which is why the version history is part of understanding how it works, not a separate topic.

Mental model#

Think of a large hotel.

The foundation and utilities are the kernel: plumbing, electricity, the building's structure. Nobody in a room thinks about the plumbing until it fails.

The concierge desk is system_server, which runs most of the building's services — booking rooms, dispatching messages, controlling the lifts.

The staff corridors are Binder. They are how a room can request something without walking into another guest's room.

Each guest's room is an app: locked, private, with its own key. The hotel can enter in an emergency, and the guest can call the desk, but neither can wander into another room.

And the template room that every new room is copied from — furniture already assembled, ready to be personalised — is Zygote.

Where the analogy breaks#

A hotel's rooms are all identical, but Android processes are not: they are copies of the same mould that immediately diverge. More importantly, the hotel manager (system_server) is not special in the way a human manager is. It has no magic authority. It is a process with privileges the kernel grants it, and those privileges are written down in SELinux policy and checked on every access. The building's "management" is a document, not a person.

The big picture#

This is the stack you will learn to draw from memory. Every block is part of the site; click one to see what it does, what language it is written in, and which module explains it.

Loading diagram…

Text description of this diagram

Android's architecture as seven layers. From the bottom: the Linux kernel with its drivers; the hardware abstraction layers (HALs) that separate vendor code from the platform; native daemons and libraries such as Bionic, SurfaceFlinger and the media stack; the Android Runtime (ART) plus the framework's Java/Kotlin core; the framework system services that live in system_server; the system apps such as SystemUI, Settings and the launcher; and finally user apps. Data flows down through well-defined interfaces: apps call framework APIs that cross Binder into system services, which call native libraries, which call HALs, which reach the kernel and hardware. Each higher layer depends only on the interface of the layer below, which is what allows parts of the system to be updated independently.

Three numbers are worth carrying with you from the start:

Android 1.0 shipped in September 2008 with API level 1.
The current release is Android 17, API level 37, released 16 June 2026.¹
There are 37 API levels, and several Android versions share a level: both Android 12 and 12L report API 31 and 32 respectively, and Android 4.4 and 4.4W are API 19 and 20.

The four layers of every topic#

Every page on this site is built to move you through four stages, in order:

Visualise — an interactive diagram you can step through, not a static picture.
Understand — the mechanism, in prose, with real code and real file paths.
Get curious — the odd facts and the "wait, why is it like that?" questions.
Build — something you can run on a device or read in the source.

The order matters. A diagram without an explanation is decoration; an explanation without a diagram is homework. The loop between them is where understanding actually happens.

Deep dive#

What "Android" actually means#

There are four different things people call Android, and confusing them causes most of the confusion about the platform.

Thing	What it is	Open source?	Who controls it
AOSP	The Android Open Source Project: the platform source tree	Yes	Google leads, contributions via Gerrit
GMS	Google Mobile Services: Play Store, Play services, Google apps	No	Google
The vendor stack	Drivers, HALs, firmware and customisations	Sometimes	The SoC vendor and the OEM
A shipping phone	All of the above, assembled and certified	No	The OEM

When someone says "Android 17 is out", they usually mean AOSP plus the Google apps. When a phone gets it, that means the OEM also shipped vendor code that matches. That gap — between the open platform and the shipping device — is the engine of the platform's history, and a whole module is devoted to it.

The process model in one paragraph#

Every app runs in its own Linux process with its own UID. Your app's files are readable only by that UID. To do anything useful — show a window, read a contact, play a sound — the app must call a system service, and the call crosses a process boundary through Binder. The service checks your app's identity and permissions, does the work, and returns. There is no path from your code to another app's memory except through a service that explicitly allows it. That design is unusual among operating systems, and it is the reason Android can safely run apps from anywhere.

Why there is an API level at all#

Android needed a way to change behaviour without breaking the installed base. The solution is targetSdkVersion: an app declares which platform behaviour it was designed against, and the platform applies only the changes the app has opted into. New restrictions that would break existing apps are gated; new capabilities are not. Play's minimum-target policy is how the ecosystem is pushed forward.

Loading diagram…

Text description of this diagram

A treemap of the software on a typical Android phone, grouped by who owns it. AOSP's open-source platform components — the kernel interface, the framework, system apps, and the runtime — make up the largest area. Google's proprietary layer, including Play services and the Play Store, forms a second significant block. The vendor and OEM code, which includes the SoC drivers, HAL implementations, firmware and the OEM skin, is the third. A small area represents the apps the user installs. The diagram makes clear that a shipping phone is a composite of at least three independently maintained bodies of software, each with its own update path.

How it evolved#

The stack you learn on this site is not the stack Android started with. Each era added a layer or a boundary, usually in response to a problem.

2008–2014Dalvik eraOne runtime, one device class, updates controlled entirely by the carrier.API 1

2014–2017ART eraAhead-of-time compilation, 64-bit support, and the first serious attempts at update speed.API 21

2017–2019Treble eraThe vendor interface splits the phone in two, making system updates possible independently.API 26

2019–2024Mainline eraIndividual modules ship through Play; the kernel itself becomes generic.API 29

2024–nowAdaptive eraOne platform for phones, foldables, tablets and cars, with Compose as the default UI layer.API 35

Under the hood#

If you want to read the source immediately, these are the three files that define the world this site describes. Each one is worth a look even before you understand it completely.

ActivityThread.javathe real main() of every Android app
SystemServer.javawhere the hundred system services are born
SystemServiceRegistry.javathe map from Context constants to manager objects

Curiosity corner#

Android has no main() in your app. The entry point is ActivityThread.main(), which is part of the framework and already running before your first line of code executes.
The zygote is older than most Android apps. It starts before system_server and outlives every app launch on the device, forking children from the same warm template.
A "reboot" is not always a reboot. When system_server crashes, init restarts it and the framework comes back up without touching the kernel — a soft reboot that looks like a full one.

What stops a manufacturer from calling anything Android?The Compatibility Definition Document and the Compatibility Test Suite. A device must implement the documented behaviours and pass…Open card →

Try it#

You do not need a rooted phone to see the stack. Any Android device with developer options and adb will do. These three commands show you the layers from the outside.

See the process model

$ adb shell ps -A | head -20

Example output

USER           PID  PPID     VSZ    RSS WCHAN            ADDR S NAME
root             1     0  ...    ...  ...             0:0 S init
root           347     1  ...    ...  ...             0:0 S servicemanager
system         487     1  ...    ...  ...             0:0 S surfaceflinger
root           610     1  ...    ...  ...             0:0 S zygote64
system         863   610  ...    ...  ...             0:0 S system_server
u0_a123       4821   610  ...    ...  ...             0:0 S com.example.app

Look at the PPID column: system_server and your app both have the same parent, and that parent is zygote64. That single line is the whole zygote design.

Ask the framework what it can do

$ adb shell service list | head -40

Every line is a Binder service registered with servicemanager. Those names are the same strings you will see in getSystemService calls.

Build it#

There is no build step for this page. If you want to start building immediately, the B01 — Hello lifecycle project logs every lifecycle callback to the screen, which makes the process model visible on a real device.