Package Installation Flow

The installation of a new package (APK) involves rigorous security checks, file system manipulation, and framework-level registration. This process ensures that malicious apps are blocked and that valid apps are correctly integrated into the system.

PackageInstaller to Component Registration

The installation sequence is primarily handled by the PackageManagerService (PMS).

1. Session Creation: The installing app (e.g., Play Store, ADB) uses the PackageInstaller API to create a session and stream the APK bytes to a temporary staging directory (/data/app/vmdl*).
2. APK Parsing: PMS parses the AndroidManifest.xml within the APK to extract the package name, components (Activities, Services), permissions, and signatures.
3. Signature Verification: The APK's cryptographic signature scheme (v1, v2, v3, or v4) is verified. If updating an existing app, PMS ensures the new signature perfectly matches the old one.
4. DEX Compilation (dex2oat): Ahead-of-Time (AOT) compilation is triggered. The system invokes dex2oat to compile the Dalvik bytecode (classes.dex) into optimized native code (.oat / .art files), caching them in the dalvik-cache or adjacent to the APK.
5. Data Directory Creation: PMS instructs installd (a native daemon) to create the application's data directories (/data/user/0/<package_name>) and sets the correct SELinux labels and UID/GID ownership.
6. Permission Grant: Install-time permissions (e.g., INTERNET) are automatically granted. Runtime permissions are registered but remain revoked until requested by the app.
7. Component Registration: PMS updates its internal, memory-resident data structures with the new components. It writes the updated package state to /data/system/packages.xml.
8. Broadcast: Finally, AMS broadcasts ACTION_PACKAGE_ADDED so other apps (like Launchers) can update their UI.

# Debugging installation failures via logcat
adb shell logcat -b all | grep -i PackageManager

Silent Install via DevicePolicy

In enterprise environments, a Device Owner or Profile Owner can install apps silently without user interaction.

The Device Policy Client (DPC) uses the PackageInstaller API, but because it holds elevated administrative privileges, the framework bypasses the standard user confirmation prompts.

// Simplified snippet for silent session commit
PackageInstaller.SessionParams params = new PackageInstaller.SessionParams(
    PackageInstaller.SessionParams.MODE_FULL_INSTALL);
int sessionId = packageInstaller.createSession(params);
// ... write APK bytes ...
// Commit the session without user UI
session.commit(PendingIntent.getBroadcast(...).getIntentSender());

APEX Installation Flow

The Android Pony EXpress (APEX) format is used for updating lower-level system components (native libraries, core services) outside of full OTA updates. APEX installation differs significantly from APK installation.

1. Staging: The APEX file is downloaded and staged.
2. Pre-reboot Verification: apexd (the APEX daemon) verifies the cryptographic signature of the APEX. It also ensures the APEX is targeting the correct device architecture and OS version.
3. Reboot Required: Unlike APKs, APEX modules require a system reboot to take effect, as they often contain native libraries already mapped into memory by init or Zygote.
4. Activation: During the next boot, init starts apexd very early. apexd uses dm-verity to mount the verified APEX file securely over the existing system paths (e.g., /apex/com.android.tzdata/).
5. Fallback: If the device fails to boot after an APEX update, apexd detects the boot loop, reverts to the factory-installed APEX version, and reboots the device to restore functionality.