第1章 AOSP源码结构总览：系统分区、镜像类型、模块组织方式、关键路径
AOSP（Android Open Source Project）的源码规模庞大，超过60GB的文件和数千个独立模块。要有效拆解和学习其架构，首先需要在宏观上理解系统分区/镜像布局、模块组织方式以及关键源码路径。本章从组件边界、系统分层、模块职责和数据流/控制流的角度，建立AOSP源码结构的全景视图，并分析选型权衡与落地风险。
1.1 系统分层与组件边界
AOSP采用严格的分层架构，每一层有明确的组件边界，并通过固定的接口（如HIDL、AIDL、Binder）进行通信。分层决定了信任链路：上层依赖下层，下层向上层提供安全隔离。
| 层级 | 组件边界 | 典型模块 |
|---|---|---|
| 应用层 | APK进程，沙箱隔离 | 系统UI、Launcher、第三方App |
| Framework层 | Java系统服务，运行在system_server | ActivityManagerService、PackageManagerService |
| 系统服务层 | 本地Native服务，通过Binder暴露 | SurfaceFlinger、media、audioserver |
| HAL层 | 硬件抽象，通过HIDL与上层解耦 | Camera HAL、Audio HAL、Sensor HAL |
| 内核层 | Linux内核，驱动与文件系统 | Kernel、Device Drivers、SELinux |
以上分层对应到源码组织：frameworks/ 包含Framework和部分系统服务，hardware/ 包含HAL接口和实现，kernel/ 为独立仓库。各层之间通过数据流/控制流连接：App通过Binder调用系统服务，系统服务通过HIDL调用HAL，HAL通过ioctl访问内核驱动。
1.2 系统分区与镜像类型
AOSP运行设备上的物理分区直接对应编译产物中的镜像文件。分区设计决定了组件隔离与OTA更新策略。以下为主要分区及其职责：
| 分区名称 | 挂载点 | 镜像文件 | 内容与职责 |
|---|---|---|---|
system | /system | system.img | Android Framework、系统应用、核心库 |
vendor | /vendor | vendor.img | 设备厂商专有HAL、驱动、配置 |
product | /product | product.img | 产品定制层（如Google服务、OEM定制） |
odm | /odm | odm.img | 原始设备制造商定制（可选） |
boot | — | boot.img | 内核+ramdisk（启动阶段） |
userdata | /data | userdata.img | 用户数据与应用安装目录 |
cache | /cache | cache.img | OTA缓存、日志 |
现代AOSP设备普遍使用动态分区（super分区），将system、vendor、product等逻辑分区打包到一个super.img中，编译时通过lpmake工具生成。启动时由first stage init在用户空间创建逻辑块设备。这种设计降低了分区固定大小的风险，但增加了引导复杂度和信任链检查点。
1.3 模块组织方式与关键路径
AOSP源码根目录下每个顶级目录对应一个模块域，由Android.bp或Android.mk定义构建规则。以下列出关键路径及其模块职责：
| 关键路径 | 模块职责 |
|---|---|
frameworks/ | Java Framework层（base, native, av, rs） |
hardware/ | HAL接口定义、参考实现（interfaces, libhardware） |
system/ | 核心系统库（libc, libutils, logd, init） |
external/ | 第三方开源库（openssl, libpng, sqlite） |
packages/ | 系统应用（Settings, Launcher, Dialer） |
device/ | 设备板级配置、内核补丁、专有库声明 |
vendor/ | 厂商私有实现（驱动、HAL service） |
bootable/ | bootloader、recovery、fastboot |
build/ | 构建系统核心（Soong, Makefile, config） |
控制流关键路径：从设备上电到Launcher启动，涉及init进程（system/init）解析.rc文件、启动zygote（frameworks/base/cmds/app_process）、zygote孵化system_server、system_server注册系统服务并启动ActivityManagerService、Launcher开始显示。这条路径中每一步都跨越多个分区：boot.img（内核+ramdisk）→ system分区（zygote）→ vendor分区（HAL服务）→ data分区（用户数据）。
1.4 选型权衡与风险点
- 分区策略：传统固定分区 vs 动态分区。动态分区灵活性高但增加构建复杂度和引导时间；固定分区可预测性强但不易调整。
- 模块解耦：将HAL放入vendor分区实现OEM独立升级，但需要维护HIDL接口版本兼容性，否则导致系统服务崩溃。
- 构建系统选择：Soong（Blueprint）逐渐替代Makefile，但大量旧模块仍保留
Android.mk，需要混用构建规则，增加了维护成本。 - 镜像大小：super分区有总容量上限（由闪存决定），如果同时启用system、vendor、product、odm四个分区，可能导致空间不足。选型时建议合并不需要的odm分区或使用动态分区弹性调整。
1.5 落地步骤与验收标准
- 环境准备：安装Repo工具、配置Git、下载目标分支源码（如android-14.0.0_r1）。
- 设备选择：使用官方支持的参考设备（如Pixel系列）或创建一个模拟器目标（如aosp_x86_64）。
- 第一次编译：执行
source build/envsetup.sh && lunch sdk_phone_x86_64 && make -j16，确保能生成完整镜像。 - 镜像验证：检查
out/target/product/generic_x86_64/下是否存在super.img、boot.img、system.img等。 - 启动验证：使用模拟器运行
emulator命令，观察系统启动过程，验证分区挂载和SELinux策略。
- 编译无错误退出，生成所有分区镜像。
- 模拟器或真机能正常启动到Launcher，无selinux denial或分区挂载失败。
- 关键日志（dmesg、logcat）中未出现分区空间不足或签名不匹配的警告。
1.6 本章小结
- 系统分层：五层结构（应用→Framework→系统服务→HAL→内核）定义了明确的组件边界，每层通过Binder/HIDL/ioctl进行进程间通信。
- 分区与镜像：system、vendor、product、boot等分区分别承载不同层的代码，动态分区（super）是现代设备的首选选型。
- 模块组织：AOSP源码通过顶级目录划分模块域，关键路径如
frameworks/、hardware/、system/直接对应架构分层。 - 风险与权衡：分区空间、构建兼容性、SELinux策略配置是架构落地的常见陷阱，需要在设计阶段提前规划。