The Boot Bottleneck
The Linux kernel boots in seconds. Yet a device sits on the boot animation for much longer. Users wait while the system server initializes massive Java services required for a functioning OS. These core framework services must start before the interface becomes usable. Android's system server brings up ActivityManagerService (AMS), PackageManagerService (PMS), WindowManagerService (WMS), and InputManagerService (IMS) in a specific order.
The ultimate goal of this sequence is displaying the home screen. AMS drives this process by calling a systemReady() method when it finishes early initialization. But AMS cannot just launch the home screen immediately. It first needs to know where the launcher application actually lives on the disk.
Mapping the Storage
An operating system cannot launch what it cannot find. When the system boots, memory is empty and AMS has zero knowledge of installed applications. PackageManagerService (PMS) exists to solve this problem by building a directory of all available applications.
PMS executes a massive disk scanning operation during startup. The service reads through system directories and user directories on the disk. For every application package, PMS parses the XML manifest to extract permissions and components. It cross-references this data against a local state file to maintain stable user IDs across reboots.
You are about to see the disk locations PMS reads during startup. This flowchart visualizes exactly where the boot time goes. Notice how PMS builds an in-memory database from multiple XML sources.
Heavy disk input and XML parsing dominate this phase of the boot sequence. This in-memory database allows instant app lookups later without hitting the disk. Once PMS completes its database, the system knows exactly which app serves as the default launcher.
Orchestrating the System
Now that the system knows which app is the launcher, something has to actually start and track it. ActivityManagerService acts as the brain of process management. AMS waits for the system to settle and cleans up prematurely started rogue processes. It asks PMS for the default home application intent.
AMS then instructs Zygote to fork a new Dalvik process specifically for the launcher. The launcher process exists in memory and begins executing its code. But the launcher cannot draw anything on the screen yet.
Defining the Screen Space
Knowing the launcher package is not enough to show it to the user. An application needs a defined geometric space on the physical display to draw its pixels. WindowManagerService (WMS) handles this geometric organization and window z-ordering. WMS retrieves logical display dimensions from the display manager and calculates the initial window hierarchy. It does not actually composite pixels.
Instead, WMS assigns a surface to the launcher application via a Binder interface to the native SurfaceFlinger process. A newly assigned surface allows the launcher to draw its icons. SurfaceFlinger then composites those pixels to the screen. Users can see the app, but they still cannot interact with it.
Connecting Hardware to Software
A physical tap on the glass is just a hardware electrical interrupt. The system needs a way to route that analog signal to the correct Java application. InputManagerService (IMS) bridges the Linux kernel device nodes and the application framework. IMS relies primarily on C++ and runs two native threads. The reader thread constantly polls hardware nodes for new events. A dispatcher thread takes those raw events and figures out where to send them.
This sequence diagram shows how a physical screen touch reaches an application. It clarifies the boundary between the hardware driver and the framework. Watch how the dispatcher relies on window focus state to route the event.
The dispatcher talks to WMS to find out which window currently has focus. It then sends the event directly to that application process through a fast Unix domain socket called an input channel. IMS and WMS remain tightly coupled forever. Every time window focus changes, WMS updates IMS to ensure touches hit the right target.
The Idle System
Booting these four services transforms a cold kernel into a functioning Android device. PMS maps the storage. AMS orchestrates the processes. WMS defines the screen geometry. IMS brings the device to life with touch interactions.
With the system fully running, the device sits idle waiting for user input. The next challenge is understanding exactly what happens when the user taps an app icon to start a new activity.