4. Android分区与镜像基础
在 Android 量产升级与版本管理中，理解分区与镜像的对应关系是排障与制定升级策略的前提。Android 采用 A/B 或非 A/B 分区布局，每个分区承载不同层级的软件组件，升级时是否可独立替换、是否触发校验、是否影响开机，都取决于分区职责与验证链。本节从分区作用、镜像构成、升级影响三个维度展开，并结合实际场景说明常见误区。
一、核心原理：分区是软件层级的物理映射
Android 的分区设计遵循“分层解耦”原则：底层引导与验证、中间系统框架、上层厂商定制与产品差异分别落在不同分区。这样做的目的是让 OTA 升级可以按需替换，同时通过验证链保证完整性。常见分区及其职责如下：
- boot：包含 Linux 内核与 ramdisk（或 GKI 的 boot.img），负责挂载 system、vendor 等分区并启动 init。升级 boot 通常意味着内核或启动参数变更，风险较高。
- system：AOSP 框架、系统应用、系统库与运行时。升级 system 会改变 Android 版本行为，是 OTA 的主体之一。
- vendor：SoC 厂商提供的 HAL、固件、内核模块与专有库。vendor 与 system 之间存在接口版本约束，跨版本升级需检查 VINTF 兼容性。
- product：产品差异化配置、预装应用、产品级 overlay。它位于 system 与 vendor 之间，常用于区分同一平台的不同机型。
- odm：ODM 厂商定制内容，如特定硬件适配、区域配置。odm 通常与 vendor 配合，升级时需保持与 vendor 的匹配。
- dtbo：设备树叠加（Device Tree Overlay），描述硬件差异，如屏幕、传感器、引脚配置。dtbo 与内核和硬件强相关，错误替换会导致外设失效。
- vbmeta：验证启动元数据，保存各分区哈希与签名信息。修改任何受验证分区后，必须同步更新 vbmeta，否则启动校验失败。
此外还有 super 动态分区、userdata、metadata、misc 等。量产升级中最常打交道的正是上述七类分区，它们共同构成“引导—系统—厂商—产品—验证”的完整链条。
二、方法流程：从镜像到分区的升级路径
量产升级通常以镜像文件为单位，通过 fastboot 或 OTA 包写入对应分区。理解镜像与分区的映射，才能正确选择升级方式。常见镜像与分区对应关系如下表：
| 镜像文件 | 目标分区 | 主要内容 | 升级风险 |
|---|---|---|---|
| boot.img | boot | 内核 + ramdisk | 高，影响启动 |
| dtbo.img | dtbo | 设备树叠加 | 高，影响硬件识别 |
| vbmeta.img | vbmeta | 验证元数据 | 高，校验失败无法开机 |
| system.img | system | AOSP 框架与应用 | 中，需兼容 vendor |
| vendor.img | vendor | HAL 与固件 | 中，需匹配 system |
| product.img | product | 产品配置 | 低，产品级差异 |
| odm.img | odm | ODM 定制 | 低，区域适配 |
典型 fastboot 升级命令如下，注意 --disable-verity 与 --disable-verification 仅用于调试，量产必须保持验证开启：
fastboot flash boot boot.img
fastboot flash dtbo dtbo.img
fastboot flash vbmeta vbmeta.img
fastboot flash system system.img
fastboot flash vendor vendor.img
fastboot flash product product.img
fastboot flash odm odm.img
fastboot reboot若使用 OTA 包，则通过 update_engine 按 payload 中的分区操作指令写入。A/B 设备会写入非当前槽位，重启后切换；非 A/B 设备则直接覆盖，失败后需依赖 recovery 或 fastboot 恢复。
三、案例场景：一次 vendor 升级导致的开机失败
某量产项目在 OTA 中仅替换了 vendor.img，未同步更新 vbmeta.img。设备重启后卡在 bootloader 阶段，日志显示：
AVB: hash mismatch for vendor
AVB: verification failed for vbmeta
ERROR: boot verification failed原因是 vendor 分区受 AVB 验证保护，其哈希记录在 vbmeta 中。替换 vendor 后哈希变化，而 vbmeta 仍为旧值，校验必然失败。正确做法是：重新生成 vbmeta.img 并一并刷入，或使用 avbtool 更新哈希描述符。该案例说明：任何受验证分区的修改，都必须同步更新 vbmeta。
量产红线：不要为了绕过校验而关闭 AVB 或 dm-verity。关闭验证会降低安全性，且可能导致 Google 认证失败、OTA 无法通过。调试阶段可临时关闭，量产必须恢复。
四、误区与复盘：分区升级中的常见问题
- 误区一：只升级 system 就能获得新功能。实际上 system 与 vendor 存在接口约束，跨版本升级需检查 VINTF manifest，否则 HAL 调用失败。
- 误区二：dtbo 可以随意替换。dtbo 描述硬件差异，不同屏幕、传感器配置不同，错误替换会导致外设不工作甚至无法开机。
- 误区三：product 和 odm 不重要。它们承载产品差异与区域配置，升级时若签名或版本不匹配，可能导致预装应用崩溃或配置丢失。
- 误区四：忽略 super 动态分区。在动态分区方案中，system、vendor、product、odm 可能位于 super 内，升级需通过
fastboot flash super或 OTA 逻辑分区操作，不能单独刷写。
复盘建议：建立分区升级检查清单——确认目标分区、确认是否受 AVB 保护、确认是否需要同步 vbmeta、确认 system/vendor 接口兼容、确认 A/B 槽位状态。每次升级前逐项核对，可显著降低量产变砖风险。
掌握分区与镜像的对应关系，是制定 OTA 策略、定位启动故障、评估升级影响的基础。在后续版本管理中，还需结合分区版本号、签名密钥、回滚策略进行统一管理，确保量产升级可控、可追溯、可恢复。