2. Android系统镜像基础
Android 设备启动并不是“加载一个操作系统文件”这么简单，而是由 BootROM、引导加载程序（Bootloader）、内核、ramdisk、系统分区、厂商分区、用户数据分区等多个阶段、多个镜像协同完成。理解每个分区镜像的职责与格式，是后续做镜像签名、OTA 打包与发布工程的前提。本节从整体分区布局出发，逐一说明 boot.img、system.img、vendor.img、recovery.img 等核心镜像的作用、内部结构与常见格式。
一、核心原理：Android 分区镜像的整体布局
一台典型 Android 设备的 eMMC/UFS 存储会被划分为若干逻辑分区，每个分区对应一个可独立刷写、独立签名的镜像文件。按启动顺序与职责，可以粗略分为四类：
- 引导类分区：boot、init_boot、recovery、vbmeta，负责把内核与 ramdisk 装载起来，并承载启动校验信息。
- 系统类分区：system、vendor、product、system_ext、odm，承载 Android 框架、系统应用、HAL 与厂商定制内容。
- 数据类分区：userdata、metadata、cache，运行时读写，通常不参与出厂镜像签名。
- 固件类分区：modem、bluetooth、xbl、tz 等，由芯片厂商提供，签名体系往往独立。
其中 boot、system、vendor、recovery 是与发布工程关系最紧密的四个镜像。它们分别对应“怎么启动”“系统是什么”“厂商差异在哪”“如何进入恢复模式”四个问题。
二、四大核心镜像的作用与格式
boot.img 是启动链中最关键的一环。它由 boot header、kernel、ramdisk、second stage、dtb 等段组成，header 中记录了魔数、版本、各段偏移与大小、页大小等元信息。Android 10 之后引入 GKI（通用内核镜像）与 init_boot 分区，把通用内核与厂商 ramdisk 分离，boot.img 的组成也随之变化。其格式本质是“带头的多段容器”，签名时通常对整段做 AVB 哈希。
system.img 承载 Android 框架、系统应用、运行时与系统库，挂载到 /system。早期使用 ext4，Android 10 起逐步转向只读的 EROFS，以节省空间并提升读取性能。system.img 通常以稀疏镜像（sparse image）形式发布，刷写时由 fastboot 展开为实际块设备内容。
vendor.img 存放芯片与整机厂商提供的 HAL 实现、固件、配置文件，挂载到 /vendor。它是 Treble 架构下“系统与厂商解耦”的关键：system 通过 VINTF 与 vendor 的 HAL 交互，二者可独立升级。vendor.img 同样使用 ext4 或 EROFS，并参与 AVB 校验链。
recovery.img 是恢复模式镜像，结构与 boot.img 类似，包含 recovery 内核与 ramdisk。它用于 OTA 升级、恢复出厂、清除数据等场景。Android 10 之后引入 recovery-as-boot，部分设备不再单独提供 recovery 分区，而是复用 boot 分区中的恢复 ramdisk。
三、镜像格式与签名关系对照
| 镜像 | 挂载点 | 常见格式 | 是否参与 AVB | 发布关注点 |
|---|---|---|---|---|
| boot.img | — | boot header + kernel + ramdisk | 是 | 内核版本、GKI、dtb |
| system.img | /system | ext4 / EROFS / sparse | 是 | 框架版本、系统应用 |
| vendor.img | /vendor | ext4 / EROFS | 是 | HAL、VINTF、固件 |
| recovery.img | — | boot header + recovery ramdisk | 是 | OTA、恢复策略 |
| vbmeta.img | — | AVB 元数据 | 是（根） | 哈希、签名、回滚索引 |
四、实操场景：查看镜像信息
在发布工程中，第一步往往是确认镜像的真实格式与内部结构。可以使用以下命令快速检查：
# 查看 boot.img 头部信息
unpackbootimg -i boot.img -o boot_out/
# 查看镜像文件系统类型
file system.img
# 输出示例: system.img: Linux rev 1.0 ext4 filesystem data
# 查看稀疏镜像
simg2img system.img system_raw.img
# 查看 AVB 元数据
avbtool info_image --image vbmeta.img
五、常见误区与复盘
- 误区一：把 boot.img 当成单一内核文件。 实际上它是多段容器，ramdisk 与 dtb 同样影响启动，签名时任何一段变化都会改变整体哈希。
- 误区二：认为 system 与 vendor 可以随意混用。 Treble 下二者通过 VINTF 约束，版本不匹配会导致 HAL 无法加载，设备卡在开机动画。
- 误区三：忽略 recovery 与 boot 的复用关系。 在 recovery-as-boot 设备上单独刷 recovery.img 可能无效，必须更新 boot 分区中的恢复 ramdisk。
- 误区四：只签名 system.img 而漏签 vbmeta。 AVB 校验链以 vbmeta 为根，漏签会导致整机校验失败，设备无法正常启动。