Android Boot Sequence - End-to-End

The Android boot sequence is a complex, multi-stage pipeline that transitions the device from silicon power-on to a fully interactive user interface. Each stage has strict responsibilities regarding hardware initialization, security verification, and handoff to the next layer.

Boot Sequence Flow

1. Boot ROM (PBL - Primary Bootloader): Hardcoded in the SoC silicon. It initializes minimal RAM and loads the Secondary Bootloader. It performs the first cryptographic check.
2. Secondary Bootloader (SBL) / TrustZone: Initializes main DDR memory, brings up TrustZone (TEE), and loads the primary bootloader application.
3. Little Kernel (LK) / Android Bootloader (ABL): Implements fastboot, manages A/B slot selection, verifies the kernel image using Android Verified Boot (AVB), and passes device tree information (DTB) to the kernel.
4. Linux Kernel: Probes hardware drivers, mounts the root filesystem (ramdisk), and starts the very first user-space process: init.
5. Init Process: Parses .rc scripts (e.g., init.rc), mounts essential filesystems (/system, /vendor), and starts native daemons (SurfaceFlinger, logd, vold).
6. Zygote: Preloads Android framework classes and resources to speed up app launches. It listens on a socket for requests to fork new Dalvik/ART virtual machines.
7. SystemServer: Forked from Zygote, this process hosts all core Android services (ActivityManagerService, WindowManagerService, PackageManagerService).
8. Launcher: AMS signals that the system is ready and launches the home screen app.

Timing Each Stage

Boot time optimization requires profiling where time is spent. AOSP provides tools like bootstat to analyze boot timings.

# Dump boot timing metrics
adb shell bootstat -p
# Example output:
# boot_complete: 24500
# boot_decryption_complete: 12000
# zygote_init: 8500

Typical targets for optimization include optimizing kernel driver probe times, trimming init.rc services, and reducing the number of preloaded classes in Zygote.

Common Boot Failures and Root Causes

• Bootloop at OEM Logo: Often caused by Kernel panics (e.g., driver crashes) or AVB verification failures (modified kernel/boot image without unlocking the bootloader).
• Bootloop at Android Animation: Usually indicates a crash in SystemServer or Zygote. This is often due to fatal exceptions in core system services (e.g., a bad framework overlay, corrupted /data partition, or missing permissions).
• Stuck at "Starting Android": Indicates PackageManagerService is taking too long to scan installed APKs, or an issue with DEX optimization (dex2oat).

You can debug late-stage bootloops by pulling logcat during the boot animation:

adb shell logcat -b all | grep -E "Zygote|SystemServer|AndroidRuntime"

AVB Verification at Each Stage

Android Verified Boot (AVB) establishes a Chain of Trust to guarantee system integrity.

1. Silicon to Bootloader: The Boot ROM verifies the SBL signature against a public key fused into the hardware.
2. Bootloader to Kernel: The ABL reads the vbmeta partition, retrieves the public keys, and verifies the hash of the boot partition (kernel).
3. Kernel to Filesystem: The kernel uses dm-verity to mount /system and /vendor. Block-level hashes are verified on-the-fly as data is read. If a single block is corrupted or modified, an I/O error is triggered.

If AVB fails, the bootloader will either halt the boot process (locked device) or show a prominent warning screen (unlocked bootloader).