330 – Deep Dive into Android Boot Process: From Power-On to the First App

Series Navigation: 331-Bootloader | 332-init Process | 333-Zygote

Have you ever thought about this: From the moment you press the power button until the desktop wallpaper appears on screen, what does the Android system go through?

This is a complete chain spanning several seconds, crossing hardware and software boundaries. If any link fails, the system cannot boot.

This article is the first in the Android boot series, providing an overview, outlining the contours of the entire boot chain. The following three articles will dive into each stage.

Android Boot Overview

Android is essentially an operating system based on the Linux kernel. Therefore, its boot chain shares many similarities with standard Linux boot, but adds several unique stages due to the mobile platform’s specifics.

The entire chain can be summarized as:

Power button pressed
    │
    ▼
┌─────────────┐
│  Boot ROM   │ ← Hard-coded in the CPU chip, unmodifiable
└──────┬──────┘
       ▼
┌─────────────┐
│  Bootloader │ ← Upgradable boot program (BL1/BL2/LK/ABOOT)
└──────┬──────┘
       ▼
┌─────────────┐
│  Linux Kernel│ ← Kernel decompression, initialization
└──────┬──────┘
       ▼
┌─────────────┐
│   init      │ ← PID 1, first userspace process
└──────┬──────┘
       ▼
┌─────────────┐
│   Zygote    │ ← Incubator for all apps
└──────┬──────┘
       ▼
┌─────────────┐
│ SystemServer│ ← Core system services (AMS, WMS, PMS...)
└──────┬──────┘
       ▼
┌─────────────┐
│  Launcher   │ ← Desktop app (first user-visible process)
└─────────────┘

Note: The Launcher here refers to the point after SystemServer starts and AMS calls finishBooting(). The Launcher doesn’t immediately show the desktop upon boot_completed. The desktop is only displayed after the Launcher process actually starts.

Comparison with Standard Linux Boot

Standard PC Linux boot chain:

BIOS/UEFI → GRUB → Linux Kernel → systemd (PID 1) → multi-user.target

What changes did Android make?

Core difference: Android does not use systemd. Instead, it uses Zygote as the incubator for application processes — this is a unique Android design. All app processes are forked from Zygote.

Cold Boot vs. Warm Boot

Android boot has two scenarios:

Cold Boot

Starting from a completely powered-off state. Everything must be reinitialized from scratch.

Power off → Chip Boot ROM → Bootloader → Kernel → init → Zygote → SystemServer → Launcher

Warm Boot (Restart)

The system is already running, but certain components are restarted. For example, adb reboot or a restart after system update.

Warm boot skips Boot ROM (the CPU is already running), but the kernel is still re-initialized. However, some hardware states may be preserved (e.g., DRAM contents might be retained in a soft reboot).

Boot Time Optimization

Android boot time optimization techniques:

1. Bootloader stage:
   - Skip unnecessary hardware initialization (skip if state preserved)
   - Reduce bootloader output log (like fastboot verbose)

2. Kernel stage:
   - Use kernel same-page merging (KSM)
   - Reduce driver initialization time (probe deferral)
   - Use initramfs (faster than disk-based rootfs)

3. init stage:
   - Parallelize service startup
   - Reduce init.rc complexity
   - Use on-demand service startup

4. Zygote stage:
   - Preload commonly used classes (already done)
   - Optimize class loading order

5. SystemServer stage:
   - Start critical services first (AMS, WMS)
   - Defer non-critical services
   - Use binder async calls