2. Android系统架构与启动流程
理解Android设备的启动过程，是进行产品配置与镜像构建的基础。一台Android设备从按下电源键到用户看到桌面，背后经历了一条严格分层的启动链路：从芯片内部固化的BootROM开始，逐级加载引导程序、内核、系统服务，最终由SystemUI呈现交互界面。每一层都对应着特定的存储分区和镜像文件，构建系统正是围绕这些分区与镜像的映射关系来组织产物的。本节将沿着这条链路，梳理分层结构、关键分区、启动阶段以及镜像映射关系。
一、分层结构：从硬件到应用的五层视角
Android系统在架构上通常划分为五层，自下而上依次是：Linux内核层、硬件抽象层（HAL）、系统运行库与Android运行时层、应用框架层、应用层。启动流程正是自下而上逐层"点亮"这些层次的过程。
- Linux内核层：负责进程调度、内存管理、驱动加载，是启动后第一个真正运行的软件核心。
- 硬件抽象层（HAL）：以模块形式向框架层提供摄像头、音频、传感器等硬件能力，屏蔽芯片差异。
- 系统运行库与运行时：包括libc、媒体库、图形库，以及ART虚拟机与核心库。
- 应用框架层：ActivityManager、WindowManager、PackageManager等系统服务，是启动阶段的关键角色。
- 应用层：SystemUI、Launcher等系统应用与用户应用。
需要强调的是，分层是逻辑视角，而启动是时间视角。启动过程中，各层并非同时就绪，而是按依赖顺序依次初始化，下层未就绪时上层无法启动。
二、关键分区与镜像映射关系
Android设备使用GPT分区表，启动相关的关键分区及其承载的镜像如下表所示。理解这张映射表，是配置产品分区和构建镜像的前提。
| 分区 | 典型镜像 | 作用 | 启动阶段 |
|---|---|---|---|
| bootloader / xbl / abl | bootloader.img | 二级引导，初始化DDR、加载内核 | BootROM之后 |
| boot | boot.img（kernel + ramdisk） | 内核与通用RAM磁盘 | 内核启动 |
| init_boot | init_boot.img | 存放通用RAM磁盘（Android 13+） | 内核启动 |
| vendor_boot | vendor_boot.img | 厂商RAM磁盘与内核模块 | 内核启动 |
| dtbo | dtbo.img | 设备树叠加层 | 内核启动 |
| super | super.img（动态分区） | 包含system、vendor、product等逻辑分区 | init挂载 |
| userdata | userdata.img | 用户数据，首次启动格式化 | init挂载 |
| vbmeta | vbmeta.img | 验证启动元数据 | 引导校验 |
| misc | — | 传递启动命令与恢复模式标志 | 引导阶段 |
其中，动态分区（super）是Android 10之后的重要变化：system、vendor、product、system_ext等不再各自独立分区，而是作为逻辑分区打包进super.img，由init在启动时按需映射，从而灵活调整各分区大小。
三、启动阶段：从BootROM到SystemUI
整个启动链路可以划分为若干阶段，每个阶段都有明确的职责和交接点。
- BootROM阶段：芯片上电后运行固化在ROM中的代码，初始化最基本硬件，从固定位置读取引导程序并校验签名。
- Bootloader阶段：分为一级与二级引导，初始化DDR、时钟、存储，校验并加载boot分区，最终跳转到内核。
- 内核启动阶段：解压内核、初始化驱动、挂载根文件系统，启动第一个用户空间进程init。
- init阶段：解析init.rc，挂载分区、启动native服务、设置属性，触发zygote。
- Zygote与SystemServer阶段：zygote孵化应用进程，SystemServer启动AMS、PMS、WMS等核心服务。
- SystemUI与Launcher阶段：系统服务就绪后启动SystemUI，显示状态栏、导航栏，Launcher呈现桌面。
四、镜像映射与构建视角
从构建角度看，每个镜像都对应一个构建目标。例如：
# 构建单个镜像
make bootimage
make vendor_bootimage
make superimage
make vbmetaimage
# 查看镜像与分区的映射
ls out/target/product/<device>/
# boot.img init_boot.img vendor_boot.img dtbo.img
# super.img vbmeta.img userdata.img
构建系统通过BoardConfig.mk中的分区大小、文件系统类型、AVB配置等参数，决定镜像的生成方式。例如BOARD_BOOTIMAGE_PARTITION_SIZE决定boot分区大小，BOARD_SUPER_PARTITION_SIZE决定super分区容量，BOARD_AVB_ENABLE控制是否启用验证启动。
五、常见误区与复盘
在实际项目中，启动问题往往集中在几个典型误区：
- 混淆boot与init_boot：Android 13起通用RAM磁盘从boot移到init_boot，若仍按旧方式打包，会导致启动失败。
- 忽略vbmeta校验：修改boot或super后未同步更新vbmeta，设备会因验证失败而无法启动。
- 动态分区大小配置不当：super分区容量不足时，构建阶段可能通过但刷机后挂载失败。
- misc分区命令残留：上次进入recovery的命令未清除，导致设备反复进入恢复模式。
掌握上述分层结构、分区映射与启动阶段后，后续进行产品配置时就能清楚地知道：修改哪个配置会影响哪个镜像，哪个镜像又对应哪个分区，以及该分区在启动链路的哪一环被加载。这种"配置—镜像—分区—启动阶段"的对应关系，是Android设备产品化过程中最核心的知识骨架。