AMS, PMS, WMS, IMS Startup - AOSP Framework & Internals

The initialization of the "Big Four" services (ActivityManager, PackageManager, WindowManager, and InputManager) represents the heaviest and most critical phase of the Android boot process.

AMS Initialization and systemReady()

ActivityManagerService (AMS) is initialized during the Bootstrap phase. Its constructor sets up core data structures: process LRU lists, Broadcast queues, and the internal Handler thread.

However, AMS doesn't actually start launching apps until much later. The pivotal moment is when SystemServer calls AMS.systemReady(). Inside this method, AMS performs its final setup:

It kills any rogue processes that might have started prematurely.
It asks PackageManager to retrieve the Intent.CATEGORY_HOME application (the Launcher).
It spawns the System UI process.
It finally instructs Zygote to fork the Launcher process, transitioning the device from the boot animation to the usable home screen.

PMS Scanning Packages on Startup

PackageManagerService (PMS) is arguably the slowest service to start. During boot, PMS must build an in-memory database of every application installed on the device.

It achieves this by scanning specific directories:

/system/framework/: For framework resources.
/system/app/ and /system/priv-app/: For system applications.
/data/app/: For user-installed applications.

For every APK found, PMS parses the AndroidManifest.xml to extract permissions, activities, services, and content providers. It cross-references this against /data/system/packages.xml to maintain UID assignments. This heavy disk I/O and XML parsing is the primary reason Android takes time to boot.

WMS Startup and Display Initialization

WindowManagerService (WMS) is initialized in startOtherServices(). WMS relies entirely on SurfaceFlinger (running in a separate native process) for actual compositing.

During startup, WMS connects to SurfaceFlinger via the ISurfaceComposer Binder interface. It retrieves the logical display dimensions from DisplayManagerService and calculates the initial window hierarchy (PhoneWindowManager). It also determines if the device is booting in safe mode or if the screen needs to be rotated based on hardware sensors.

InputManagerService (IMS) Startup

InputManagerService (IMS) bridges the gap between the Linux kernel's evdev driver and Java UI elements.

IMS is mostly implemented in C++ (via JNI). During startup, it spawns two critical native threads:

InputReader: Opens /dev/input/ nodes and constantly polls for hardware interrupts (touches, key presses, mouse movements).
InputDispatcher: Takes the raw events from InputReader, figures out which window is currently focused by asking WMS, and sends the event to that window's app process via a fast InputChannel (backed by a Unix domain socket).

IMS and WMS are tightly coupled. WMS must constantly update IMS whenever the window focus changes, ensuring touches are always routed to the correct application.