4. Android标准分区布局
Android 的存储体系并不是“一个根目录装所有东西”的简单结构，而是由多个具有明确职责、独立挂载、独立更新策略的分区共同组成。理解这些分区的分工与依赖关系，是分析系统启动、OTA 升级、分区校验、文件安全与故障排查的基础。本章围绕标准分区布局，逐一说明各分区的核心作用，并梳理它们之间的依赖链。
一、核心原理：分区是启动链与更新链的物理边界
Android 分区布局的设计目标可以概括为三点：可启动、可更新、可隔离。可启动意味着 bootloader 能按固定顺序找到引导镜像；可更新意味着 system、vendor、product 等分区可以独立升级而不互相破坏；可隔离意味着厂商定制、运营商定制与 AOSP 通用代码被拆分到不同分区，避免耦合。
从启动视角看，分区之间存在严格的先后依赖：boot 提供内核与 ramdisk，内核挂载 system 作为根文件系统，vendor 提供硬件抽象层实现，product 与 odm 提供上层定制内容，data 保存运行时可变数据，cache 与 metadata 承担升级与加密元数据职责，misc 则保存 bootloader 与 recovery 之间的通信标志。
二、各分区作用详解
boot 分区包含 Linux 内核与 ramdisk（或 init_boot 分离后的 ramdisk）。它是启动链中第一个被加载的可执行镜像，负责初始化硬件、挂载根文件系统并启动 init 进程。boot 损坏通常表现为无法开机或卡在 bootloader。
system 分区是 AOSP 的核心载体，包含 framework、系统服务、核心应用与系统库。在 Android 10 之后，system 与 system_ext 可能合并或拆分，但职责不变：提供与硬件无关的通用系统能力。
vendor 分区承载厂商硬件抽象层（HAL）、驱动与专有库。它使 system 可以保持通用，而硬件相关实现由厂商独立维护。vendor 与 system 之间存在接口版本约束，即 VINTF 兼容性矩阵。
product 分区用于存放产品级定制内容，如运营商预装应用、区域配置与产品专属资源。它位于 system 与 vendor 之上，属于“产品差异化”层。
odm 分区用于 ODM 厂商的定制内容，通常包含设备树覆盖、odm 专属配置与额外 HAL。它与 vendor 类似，但更偏向整机厂商的二次定制。
data 分区是用户数据分区，保存应用数据、用户配置、数据库与内部存储。它是唯一在恢复出厂设置时被清空的分区，也是加密与权限控制的核心对象。
cache 分区在传统 A/B 升级之前用于存放 OTA 下载包与临时文件。在 A/B 与虚拟 A/B 方案中，cache 的作用被弱化，但部分设备仍保留用于恢复模式临时存储。
metadata 分区用于保存加密元数据、密钥派生信息与部分系统状态。它通常以加密方式存储，是 data 分区可解密挂载的前提之一。
misc 分区是一个极小的分区，用于 bootloader 与 recovery 之间传递命令，例如“进入恢复模式”“执行 OTA 升级”“清除数据”等标志位。
三、依赖关系与升级流程
分区之间的依赖不是简单的并列关系，而是存在明确的层次。启动时，bootloader 读取 misc 判断启动目标，加载 boot；内核启动后挂载 system；system 通过 VINTF 检查 vendor 接口；product 与 odm 在 system 启动后期被挂载并合并到命名空间。data 与 metadata 在解密后挂载，cache 仅在需要时使用。
OTA 升级时，升级包通常包含 boot、system、vendor、product 等镜像。升级流程如下：
- 系统下载升级包到 data 或 cache，并校验签名与哈希。
- 向 misc 写入“升级中”标志，重启进入 recovery 或 A/B 切换槽位。
- recovery 读取升级包，逐分区写入新镜像。
- 更新 metadata 中的加密与版本信息，确保 data 兼容。
- 清除 misc 标志，重启进入新系统。
关键依赖：system 依赖 vendor 提供 HAL 实现；vendor 依赖 boot 提供内核与驱动；product 与 odm 依赖 system 提供框架接口；data 依赖 metadata 提供解密密钥；recovery 依赖 misc 与 cache 完成升级。
四、案例与排障场景
某设备 OTA 后无法开机，日志显示 VINTF compatibility check failed。排查发现升级包只更新了 system，未同步更新 vendor，导致 system 要求的 HAL 版本高于 vendor 实际提供版本。解决方法是使用完整 OTA 包，或确保 system 与 vendor 来自同一构建版本。
# 查看分区挂载与依赖
adb shell mount | grep -E "system|vendor|product|odm|data|metadata"
adb shell getprop ro.vendor.build.version
adb shell getprop ro.system.build.version
adb shell dumpsys package | grep -i "vendor"
# 检查 VINTF 兼容性
adb shell dumpsys vintf
另一类常见问题是 data 分区加密失败，表现为开机后反复重启。此时应检查 metadata 分区是否损坏，以及密钥派生参数是否与当前系统匹配。若 metadata 丢失，data 将无法解密，通常只能格式化 data。
误区提醒：不要认为“分区越多越安全”。分区拆分是为了更新与隔离，但过度拆分会导致镜像管理复杂、OTA 包增大、兼容性检查困难。标准分区布局是平衡后的结果，不应随意增删。
五、分区职责速查表
| 分区 | 核心作用 | 是否可写 | 升级方式 | 依赖对象 |
|---|---|---|---|---|
| boot | 内核与 ramdisk | 只读 | OTA 整包 | bootloader |
| system | AOSP 框架与核心应用 | 只读 | OTA / A/B | vendor、boot |
| vendor | HAL 与厂商驱动 | 只读 | OTA / A/B | boot、system |
| product | 产品定制与预装 | 只读 | OTA / A/B | system |
| odm | ODM 定制与配置 | 只读 | OTA / A/B | vendor、system |
| data | 用户数据与应用数据 | 可写 | 不升级，可清空 | metadata |
| cache | OTA 临时缓存 | 可写 | 可清空 | recovery |
| metadata | 加密与元数据 | 可写 | 随系统更新 | data |
| misc | 启动/恢复标志 | 可写 | bootloader 写入 | recovery |
掌握标准分区布局，等于掌握了 Android 系统启动、升级与安全隔离的骨架。后续分析分区校验、AVB、动态分区与文件级加密时，都可以回到这张分区依赖图上进行定位。