1. AOSP系统分区布局概述
做Android系统定制，第一件事就是要搞懂分区布局。这就像你要装修房子，总得先知道哪堵墙能拆、哪根梁不能动吧？
我刚开始接触AOSP时，面对那一堆分区名也是一头雾水。boot、system、vendor、userdata...每个分区干什么用？为什么Google要这么分？今天我就带你把这事彻底理清楚。
1.1 Android系统分区架构演进
Android的分区架构，说白了就是一部「分分合合」的历史。早期版本简单粗暴，后来为了OTA升级、安全启动、模块化，才慢慢演变成今天的样子。
| Android版本 | 分区架构特点 | 关键变化 |
|---|---|---|
| Android 1.0 - 4.4 | 单系统分区 | system、boot、recovery、userdata，简单明了 |
| Android 5.0 - 7.1 | 引入A/B分区 | 支持无缝升级，但存储占用翻倍 |
| Android 8.0 - 9.0 | Treble架构 | system分区拆分出vendor，厂商和系统解耦 |
| Android 10+ | 动态分区 | super分区出现，逻辑分区取代物理分区 |
| Android 12+ | 虚拟A/B | 结合动态分区和A/B，节省空间又支持无缝升级 |
为什么会这样演进？我个人的理解是：Google一直在平衡「升级体验」和「存储成本」。早期手机存储小，能省则省；现在存储大了，用户对升级体验的要求也高了。
核心观点：分区架构的演进，本质上是Android从「单设备单系统」走向「多设备统一平台」的过程。Treble架构是分水岭，它让厂商和Google可以各自独立更新。
1.2 各分区功能与作用
好，咱们来看看每个分区具体干什么活。我按启动顺序来讲，这样你更容易理解。
boot分区
这是手机启动的第一站。里面装着Linux内核和ramdisk。没有它，手机就是一块砖头。
我记得有一次做定制，不小心把boot分区刷错了，结果手机卡在开机logo死活进不去。嗯，从那以后我刷boot分区前都会先备份一份。
system分区
这是Android系统的核心。所有系统应用、框架、库文件都在这里。在Treble之前，system分区几乎包含了整个系统。
但有个问题——厂商的硬件驱动也塞在system里。这就导致Google更新系统时，厂商必须跟着更新驱动，效率极低。
vendor分区
Treble架构引入后，vendor分区专门放厂商的硬件相关代码。说白了，就是「Google管系统，厂商管硬件」，各管各的，互不干扰。
我建议你在做定制时，尽量把硬件相关的改动放在vendor分区，这样后续升级系统会省很多事。
product分区
Android 9之后新增的。用来放厂商预装的应用和产品定制内容。比如运营商定制、地区定制等。
userdata分区
用户数据分区。你装的应用、拍的照片、下载的文件，全在这里。恢复出厂设置时，清的就是这个分区。
cache分区
缓存分区。OTA升级时用来存放临时文件。现在动态分区普及后，这个分区用得越来越少了。
recovery分区
恢复模式分区。里面有个迷你系统，用来执行系统更新、恢复出厂设置等操作。
misc分区
杂项分区。很小，用来存一些启动相关的标志位。比如「是否进入recovery模式」这种。
避坑指南：我曾经在定制时不小心改动了misc分区的内容，结果手机每次重启都自动进recovery。排查了半天才发现是misc分区里的bootloader消息被写坏了。所以，misc分区能不动就别动。
1.3 分区布局对系统定制的影响
搞清楚了分区是干什么的，咱们再来聊聊它对定制的影响。这其实是个「牵一发而动全身」的事。
影响一：OTA升级策略
你想想看，如果你的定制改了system分区的内容，那OTA升级时就得考虑这些改动会不会被覆盖。我一般建议：
- 系统级改动放system分区，但要做好升级时的合并策略
- 硬件相关改动放vendor分区，这样升级系统时不受影响
- 预装应用放product分区，方便单独更新
影响二：存储空间分配
每个分区的大小是固定的（动态分区除外）。你给system分区多分一点，userdata分区就少一点。这是个零和博弈。
我遇到过不少项目，前期没规划好分区大小，后期发现system分区不够用，只能重新刷机调整。所以，我建议你在项目初期就估算好各分区的大小需求。
影响三：安全启动链
Android的安全启动是链式验证的：bootloader验证boot分区，boot分区验证system分区...一环扣一环。如果你改了某个分区的内容，但没有更新对应的校验值，手机就会启动失败。
重要提醒：做系统定制时，一定要考虑安全启动链。我曾经见过有人改了vendor分区的内容，结果手机一直报「dm-verity verification failed」。最后只能关掉dm-verity验证，但这样安全性就大打折扣了。
影响四：多系统支持
有些定制方案需要支持多系统启动（比如双系统）。这时候分区布局就更复杂了。你需要为每个系统准备独立的boot、system、vendor分区，还要有个共享的userdata分区。
1.4 动态分区与虚拟A/B
最后聊聊最新的动态分区和虚拟A/B。这是Android 10之后的大趋势。
动态分区的核心思想是：不再使用固定大小的物理分区，而是用一个super分区来动态管理。system、vendor、product这些分区都变成了super分区里的「逻辑分区」。
这样做的好处很明显：
- 分区大小可以灵活调整，不用再担心「system分区不够用」
- OTA升级时，可以只更新有变化的部分，节省空间
- 支持虚拟A/B，既有无缝升级的体验，又不用双倍存储空间
虚拟A/B就更巧妙了。它不像传统A/B那样准备两套完整的分区，而是只保留一份数据，升级时用「写时复制」的方式记录变化。升级失败就回滚，升级成功就合并。
我个人觉得，动态分区+虚拟A/B是Android分区架构的终极形态。它解决了之前所有方案的痛点：空间浪费、升级体验差、分区大小固定。
总结一下：搞懂分区布局，是做Android系统定制的基础。你不需要记住每个分区的细节，但一定要理解它们之间的关系和影响。特别是当你需要修改某个分区时，先想想会不会影响到其他分区，会不会破坏安全启动链。
下一章，我会带你深入每个分区的具体内容，看看里面到底装了些什么，以及如何安全地修改它们。