The SystemServer initializes over 100 system services. Attempting to start them simultaneously would cause chaos, as many services depend on others being fully initialized. To manage this, SystemServer.run() explicitly divides startup into three distinct phases: Bootstrap, Core, and Other.
Bootstrap Services
These are the absolute most critical services. Without them, the system cannot function or even display a loading screen. SystemServer starts these first by calling startBootstrapServices().
Key Bootstrap Services include:
- ActivityManagerService (AMS): Required to manage processes and memory.
- PowerManagerService (PMS): Started immediately to manage CPU wakelocks and ensure the device doesn't sleep during boot.
- PackageManagerService (PMS): Required to resolve intents and locate application binaries.
- DisplayManagerService: Needed to turn on the screen.
Core Services
Once the bootstrap foundation is laid, SystemServer calls startCoreServices(). These services are essential but depend on the bootstrap layer.
Key Core Services include:
- BatteryService: Monitors battery hardware and temperature.
- UsageStatsService: Tracks app usage (depends on AMS and PMS).
- WebViewUpdateService: Ensures the WebView package is ready.
Other Services
Finally, SystemServer calls startOtherServices(). This is a massive method (often over a thousand lines long) that starts the remaining ~80 services.
These include user-facing and hardware-specific services:
- WindowManagerService (WMS): Starts drawing windows.
- InputManagerService (IMS): Starts listening for touch and button presses.
- NetworkManagementService: Configures routing tables.
- AudioService, LocationManagerService, NotificationManagerService, etc.
Why Order Matters
Order is strictly hardcoded. For example, WindowManagerService cannot start before DisplayManagerService because WMS needs to know the physical dimensions of the screen. Similarly, NotificationManagerService cannot start before AudioManager, as it needs to know how to route notification sounds.
Circular dependencies are avoided by using a two-phased initialization. A service might be instantiated in the Core phase, but it won't attempt to communicate with a later service until a callback fires indicating the system is fully ready.
SystemReadyCallback
To handle complex inter-dependencies, SystemServer uses the systemReady() callback.
After all services are instantiated in startOtherServices(), SystemServer calls ActivityManagerService.systemReady(). AMS then invokes the systemReady() method on every other service (passed in as Runnables).
This callback acts as a starting pistol. When a service receives systemReady(), it knows that every other service on the device has been created and registered with ServiceManager. It is now safe to make Binder calls to WindowManager, PackageManager, or any other component without risking a NullPointerException or DeadObjectException.