Why Cold Boots Take So Long
When you turn on an Android device, the startup sequence takes significantly longer than a quick interface restart. The system cannot safely launch any user-facing applications until it knows exactly what software exists on the storage partitions. It needs a complete map of every app, activity, and background service loaded directly into memory. Building this map from scratch is the primary reason cold boots consume time.
The Package Manager Service (PMS) exists to build and manage this massive directory. PMS acts as the central database engine of the System Server. It tracks every application installed on the device and understands their capabilities.
During the startup phase, PMS performs a massive file system traversal. It scans the system, vendor, and user data partitions for installed packages. For every package it finds, PMS unzips the APK to extract the manifest file. Parsing XML from thousands of zipped files demands heavy CPU cycles. To avoid this penalty on every boot, PMS caches the parsed results in a local XML file. On subsequent boots, PMS reads this cache file directly instead of unzipping the original packages.
The flowchart below illustrates the boot scan caching mechanism. It helps visualize why subsequent boots complete much faster. Notice how PMS completely skips the heavy APK extraction step if it finds a valid cache file.
By the time the boot animation finishes, PMS holds a complete registry of the device. This in-memory database becomes the foundation for everything else the system does. The system relies entirely on this registry to route requests and enforce security.
Component Resolution
Applications frequently need to share data without knowing exactly which app will receive it. Hardcoding a specific target app creates fragile integrations that break easily. Developers solve this by broadcasting an implicit intent instead of naming a direct target. The system then faces a critical routing problem. It must quickly figure out which apps on the device can handle the request without stalling the user experience.
This routing problem is exactly why PMS keeps its database in memory. When the Activity Manager (AMS) intercepts an implicit intent, it halts the request and queries PMS. AMS acts as the lifecycle manager, but PMS acts as the resolution engine.
PMS searches its massive database for any intent filter that matches the incoming request. It filters the database by action, data type, and category to compile a list of eligible candidates. If multiple applications match the criteria, the system presents a chooser dialog to the user. This rapid lookup is only possible because PMS completed all the heavy XML parsing during the boot scan.
The following command shows how to query this resolution engine directly. It helps debug why an intent fails to route correctly in a production environment. Pay attention to how the command explicitly asks for the activity that resolves a specific web URL.
adb shell pm resolve-activity -a android.intent.action.VIEW -d "https://aosp.com"
Common Mistake: Developers often assume AMS handles intent resolution. AMS manages the state machine, but it relies entirely on PMS to determine the routing destination.
This strict separation of duties keeps the Android system fast. AMS focuses entirely on managing process lifecycles and transitions. Meanwhile, PMS maintains the routing directory and resolves targets instantly.
The Ultimate Authority
Hardware components and sensitive APIs on an Android device require strict access controls. A hardware module like the camera does not inherently know if a specific app holds authorization to take photos. The system needs a single, incorruptible source of truth to verify access rights. Individual services cannot make these security decisions themselves.
PMS serves as this ultimate security enforcer. It holds the definitive record of all granted permissions for every application on the device.
When you install an application, PMS reads the requested permissions from the extracted manifest. If a permission falls under the normal category, PMS automatically grants it and records the decision. For dangerous permissions, PMS tracks the request but explicitly denies it until the user grants approval. Whenever any system service needs to verify authorization, it queries the PMS database via a permission check.
The sequence diagram below shows how hardware services rely on PMS for security checks. It clarifies the flow of authorization across process boundaries. Pay attention to how the camera service completely halts its operation until PMS provides a definitive verdict.
Centralized authorization prevents malicious apps from bypassing security checks. By forcing all services to query the central directory, Android ensures its security model remains completely airtight. Knowing an app has permission to run solves the security problem. The system now faces a new challenge of actually managing the physical screen space without letting multiple running apps draw over each other.