Mateusz Pachulski

Android from the foundation · Puzzle 4 of 6

system_server is the town hall

One long-running process holds Android's system services. It keeps the register of every app's screens and decides their lifecycle, not your app.

The problem

In puzzle 3, Zygote also started system_server. Why does Android need it? If every app is locked in its own house, someone has to decide which app is on screen, which app opens a link, and which screens exist. It has to be one trusted place that sees all the houses.

See it

Your app sends "start B" to system_server; system_server checks it and adds B to its register; then it sends "create B" back and your app creates the screen your app A system_server registeryour app: A your app: A, B✓ checked start B create B B

  1. Your app shows screen A. The town hall, system_server, keeps the official register of every app's screens. Right now it says: your app, A.

    Step 1 of 4

  2. Your app calls startActivity() to open its own screen B. Even so, the request leaves your house and goes to the town hall (by Binder, the post office from puzzle 5).

    Step 2 of 4

  3. The town hall checks it: does B exist, may you open it? Then it writes B in the register. Predict: has screen B been created yet?

    Step 3 of 4

  4. Not until now: the town hall sends back "create B", and only then does your app build the screen. Your screens' lives are decided outside your app.

    Step 4 of 4

Save this diagram as a GIF

The building block

system_server starts at boot and runs as long as the phone is on. Inside it live the system services. The one that manages screens is ActivityTaskManagerService: it keeps a record of every Activity of every app, and tells each app when to create, pause, stop or destroy one. Other services handle installed apps, windows, notifications and more.

It starts in SystemServer.main()system_server's entry point: it starts the bootstrap services (activities, packages, power…). 684 public static void main(String[] args) { 685 new SystemServer().run(); … 976 startBootstrapServices(t);SystemServer.java, line 684 · AOSP frameworks/base ↗. When your app calls startActivity(), the request arrives in ActivityTaskManagerService.startActivity()Where your startActivity() lands inside system_server, after crossing Binder. 1226 public final int startActivity(IApplicationThread caller, String callingPackage, … 1230 return startActivityAsUser(caller, callingPackage, callingFeatureId, intent, resolvedType,ActivityTaskManagerService.java, line 1226 · AOSP frameworks/base ↗.

The analogy

The town hall keeps the official register of every house and every room. You don't add a room on your own; you send a request, and they send you the decision.

Check yourself

Your app opens its own next screen with startActivity(). Does that call stay inside your process?

Not quite. Even your own screens go through the town hall. Watch where the "start B" letter goes.

Right. Every screen change goes through the town hall: it checks, records, and then tells your process what to create.

Right after your app asks for screen B, has B been created yet?

Not quite. startActivity() only sends the request. The screen is created later, when the "create B" letter arrives.

Right. Screens are created only when the town hall says so.

Where is the official list of your app's screens kept?

Right. system_server keeps the register of every screen of every app; your app holds the objects.

Not quite. Your Activity objects live in your memory, but the official record that decides their lives is in the town hall.

Sources

What you now know

startActivity(), even for your own screen, is a letter to the town hall. It checks, writes the screen in its register, and only then tells your app to create it.