2. Android系统架构基础
Android 设备从按下电源键到进入桌面，并不是“系统直接启动”，而是一条由多个分区、多个阶段接力完成的链路。理解 Bootloader、Kernel、Ramdisk、System、Vendor、Recovery 等分区的作用，是后续烧录、启动失败定位和故障调试的基础。本节先建立整体架构认知，再梳理启动流程，最后给出常见误区与排查思路。
一、核心原理：分区是启动链的“接力棒”
Android 采用分区化设计，每个分区承担明确职责。启动时，芯片先执行固化在 ROM 中的引导代码，再逐级加载各分区镜像。可以把启动过程理解为一场接力赛：Bootloader 负责“起跑与交接”，Kernel 负责“驱动硬件”，Ramdisk 负责“搭建临时根文件系统”，System 与 Vendor 负责“提供系统与硬件抽象”，Recovery 则是“独立维护通道”。
关键分区及其作用如下：
| 分区 | 典型镜像 | 核心作用 | 启动阶段 |
|---|---|---|---|
| Bootloader | bootloader.img / xbl / abl | 初始化最基础硬件，校验并加载 Kernel 与 Ramdisk | 最早执行 |
| Kernel | kernel / Image / zImage | 驱动 CPU、内存、存储、显示等，挂载根文件系统 | Bootloader 之后 |
| Ramdisk | ramdisk.img / initramfs | 提供临时根目录与 init 程序，完成早期挂载与切换 | 与 Kernel 同阶段 |
| System | system.img | 存放 Android 框架、系统应用与核心库 | 挂载 /system 后 |
| Vendor | vendor.img | 存放厂商 HAL、驱动与专有配置，实现硬件抽象 | 挂载 /vendor 后 |
| Recovery | recovery.img | 独立恢复模式，用于 OTA、双清、刷机与修复 | 特殊启动路径 |
其中，Bootloader 通常还分为一级引导（如 PBL、XBL）和二级引导（如 ABL、LK）。一级引导固化在芯片内部，负责加载二级引导；二级引导才真正读取 boot 分区，并决定进入正常系统还是 Recovery。因此，Bootloader 一旦损坏，设备往往表现为“黑屏无反应”或“只能进入 EDL/Download 模式”。
二、启动流程：从通电到桌面的完整链路
正常启动流程可以概括为以下阶段：
- 上电与 ROM Code：CPU 从固定地址取指，执行芯片内部固化代码，初始化时钟与基本存储接口。
- Bootloader 阶段：加载并校验 boot 分区，解析 Kernel、Ramdisk 与 dtb，设置启动参数（cmdline）。
- Kernel 阶段：解压内核，初始化内存管理、进程调度、驱动框架，挂载 Ramdisk 作为临时根文件系统。
- init 阶段：执行 /init，解析 init.rc，挂载 system、vendor、data 等分区，启动关键服务。
- Zygote 与 SystemServer：启动 Java 运行时，孵化应用进程，拉起系统服务。
- Launcher 启动：系统服务就绪后，启动桌面，用户可见。
如果启动参数中带有 androidboot.mode=recovery 或用户按键组合触发，Bootloader 会改为加载 recovery 分区，进入 Recovery 模式。Recovery 拥有独立的内核与 Ramdisk，不依赖 System 分区，因此即使系统损坏，仍可执行恢复操作。
启动链关键点：Bootloader 决定“启动谁”，Kernel 决定“能否驱动硬件”，Ramdisk 决定“早期根文件系统是否可用”，System/Vendor 决定“系统服务能否完整拉起”。任何一环失败，都会表现为不同阶段的卡死或重启。
三、案例场景：一次典型的启动失败定位
假设设备烧录后卡在开机 Logo，无法进入桌面。可按以下思路排查：
- 卡在 Logo 且无 USB 枚举：优先怀疑 Bootloader 或 Kernel 未加载成功，检查 boot 分区是否烧录完整、镜像是否匹配。
- 能进入 Recovery 但无法进系统：说明 Bootloader 与 Recovery 正常，问题多集中在 System 或 Vendor 分区，可检查 system.img 是否损坏、vendor 与 system 版本是否匹配。
- 反复重启且伴随内核日志：通过串口或
adb logcat查看 init 阶段报错，常见于 fstab 挂载失败、dm-verity 校验失败或 SELinux 拒绝。 - 进入系统后立即崩溃：多为 Vendor HAL 与 System 框架不兼容，需核对 vendor 与 system 的构建版本。
调试时可借助以下命令获取关键信息：
# 查看当前启动模式与分区信息
adb shell getprop ro.boot.mode
adb shell ls -l /dev/block/by-name/
# 查看内核与 init 日志
adb shell dmesg | grep -i "init\|mount\|avc"
adb logcat -b all -d | grep -i "fatal\|avc"
# 进入 Recovery 后查看分区挂载情况
adb shell mount | grep -E "system|vendor|data"四、误区与复盘：避免“只盯一个分区”
初学者常见误区是“系统起不来就是 System 分区坏了”。实际上，Android 启动是强依赖链，Bootloader、Kernel、Ramdisk、Vendor 任一环节异常都会导致启动失败。另一个误区是忽略版本匹配：System 与 Vendor 通常需要同版本构建，混用不同版本的镜像极易导致 HAL 接口不匹配，表现为开机后服务崩溃或无限重启。
注意：烧录前务必确认镜像与设备型号、分区表、构建版本一致。Bootloader 分区通常有签名校验，随意替换可能导致设备变砖，只能通过 EDL/Download 模式救砖。
复盘时建议按“启动阶段—分区—日志—结论”四步记录：先判断卡在哪个阶段，再定位对应分区，然后抓取该阶段日志，最后形成可复用的排查结论。这样既能快速定位当前问题，也能为后续章节的烧录与调试打下基础。