1.1 本书创作初衷

Android 开源项目（AOSP）是人类历史上规模最大、复杂度最高、影响最为深远的开源项目之一。它支撑超过三十亿台活跃设备，涵盖手机、平板、电视、车载设备、可穿戴设备以及各类嵌入式系统。其代码库分布于数千个 Git 仓库，总代码行数达数亿行。整套架构底层是用 C 语言编写的 Linux 内核，上层对接 Java/Kotlin 应用框架，二者之间依靠原生 C++ 服务、自研 Binder 进程间通信机制以及专为安卓打造的 ART 运行时进行串联。

但即便安卓设备随处可见，即便是经验丰富的应用开发工程师，也大多对 AOSP 一知半解。普通安卓开发者仅能通过开发者官网记载的 SDK 应用程序接口这一狭窄窗口接触 AOSP。这些接口之下的系统服务、原生守护进程、硬件抽象层、内核驱动，以及将全部代码整合编译的构建系统，极少有开发者深入钻研，能够熟练梳理整套体系的人更是寥寥无几。

本书的诞生，就是为了改变这一现状。

无论你是设备厂商的系统工程师、芯片厂商的片上系统集成工程师、自定义固件开发者、平台安全研究员，或是仅仅好奇调用startActivity()时底层发生了什么的应用开发者，本书都能为你提供阅读、理解、修改、编译、调试 AOSP 所需的全部知识。

本书以Android 17为基准，对应应用程序接口等级 37，内部开发代号为肉桂卷。在源码文件frameworks/base/core/java/android/os/Build.java中定义常量版本代号.肉桂卷 = 37，上一代甜点代号巴克拉瓦对应接口等级 36。书中所有源码引用均锁定 AOSP 的 main 开发主干分支（同步发布为 android17-release 分支，资料截取时间为 2026 年年中）。对于 Android 17 新增或重构的子系统，书中会专门标注，并指引读者前往对应章节查看完整详解。

本章将为全书搭建基础。我们会精准界定 AOSP 的定义与边界，梳理从内核到应用的整套架构，逐目录讲解源码仓库结构，明确各模块维护主体，梳理平台版本迭代历程，并给出全书学习路线。

1.2 AOSP 与 Android 的区别

人们时常混用 “AOSP” 和 “Android” 两个词汇，但二者指代的事物并不相同。分清二者的区别，是源码层面开发的基础前提。

1.2.1 AOSP：开源底层基座

AOSP 全称 Android 开源项目，是谷歌发布的一套完整、可编译的开源操作系统，主体遵循 Apache 2.0 许可证，部分组件采用 GPL、LGPL、BSD 许可证，包含以下全部内容：

• 搭载安卓专属补丁的 Linux 内核
• Bionic 安卓自研 C 标准库
• 原生运行环境与原生服务，包含界面合成服务、音频合成服务、输入事件服务等数十个核心进程
• Android 运行时（ART），负责执行应用字节码
• Java/Kotlin 应用框架，即开发者使用的 android.* 全套应用程序接口
• 构建系统，采用 Soong / 蓝图编译体系，同时兼容传统 Make 编译逻辑
• 系统预装应用：设置、桌面启动器 3、系统界面、联系人、拨号器、相机、日历等
• 兼容性测试套件，定义判定一款设备符合安卓标准的规范
• 硬件抽象层以及配套参考实现
• 开发调试工具：安卓调试桥、快速启动工具、模拟器配置文件

你可以自行下载、编译 AOSP，并将镜像刷入谷歌官方参考设备或安卓模拟器，全程仅需访问谷歌源码仓库，无需谷歌额外授权。编译产物是一套功能完整的操作系统，但这并不是消费者日常使用的安卓系统。

1.2.2 谷歌移动服务：闭源分层

市面上绝大多数消费设备搭载的安卓系统，都会额外集成谷歌闭源组件谷歌移动服务，各组件说明如下：

谷歌移动服务完全闭源，设备厂商需要签署名为移动应用分发协议的商业合同才能预装。该协议历史上要求厂商必须捆绑指定最低数量的谷歌应用，并放置在固定位置，例如桌面首页放置谷歌搜索。兼容性定义文档与兼容性测试套件规定技术准入标准，移动应用分发协议规定商业准入标准。

二者的区分会带来三点关键影响：

1. 仅编译 AOSP 不集成谷歌移动服务的系统，完全不含谷歌相关能力。无法登录谷歌账号、没有应用商店、不支持谷歌云消息推送，绝大多数应用商店内的程序会出现功能异常，因为它们依赖谷歌应用服务接口。
2. LineageOS、石墨烯操作系统、卡利克斯操作系统、/e/OS 等自定义固件均基于该差异开发，要么完全剔除谷歌移动服务，要么通过开放谷歌套件、心智谷歌套件等工具可选安装，或是使用微型谷歌等开源组件替代其功能。
3. 华为、荣耀是大规模搭载纯 AOSP、无谷歌移动服务设备的典型案例。受美国贸易管制限制，谷歌无法向华为授权谷歌移动服务，华为设备搭载自研华为移动服务与自有应用市场，底层系统基于 AOSP 构建。

1.2.3 设备厂商定制层：厂商自定义修改

在 AOSP 开源底层与面向消费者的设备之间，还存在一层厂商定制层。各大设备厂商会进行大规模深度修改：

厂商修改覆盖整套系统所有分层：内核自定义驱动、调度器调优；硬件抽象层自研相机、音频、显示实现；框架新增系统服务；系统界面重构状态栏、快捷设置、锁屏；预装应用重写桌面、图库、设置等。

1.2.4 完整分层全景

消费设备上完整的安卓系统可理解为三层同心圆结构：

1. 内层：AOSP 开源底层（本书核心讲解对象）
2. 中层：设备厂商定制层
3. 外层：谷歌移动服务闭源层

本书核心观点：本书内容几乎全部聚焦内层 AOSP。操作系统的核心逻辑全部存在于这一层，谷歌移动服务与厂商定制均搭建在 AOSP 之上，吃透 AOSP 是理解另外两层内容的必要前提。

1.2.5 AOSP 开源协议说明

AOSP 整体并不采用单一许可证，不同组件依据开发来源使用不同协议：

谷歌当初为 Bionic 选择 BSD 协议而非 glibc 的 LGPL 协议，是具备奠基意义的决策。这一选择在法律层面保障闭源应用、闭源硬件驱动可以链接安卓 C 标准库，不会触发开源传染条款，也是各大移动厂商愿意采用安卓、同时保留自有闭源驱动与闭源应用生态的核心原因。

1.3 AOSP 分层架构：分层模型

安卓采用分层栈式架构，每一层为上层提供服务，同时依赖下层提供能力。理清整套分层、各层包含内容、跨层通信方式，是学习 AOSP 最重要的基础认知。

1.3.1 完整架构总览

我们将自底向上，逐层完整讲解整套架构。

1.3.2 第一层：Linux 内核

安卓系统运行在 Linux 内核之上。截至 Android 17，内核基于 Linux 6.x 长期支持分支，android17-6.18 通用内核镜像目标对应 Linux 6.18，Android 16 使用 android16-6.12。所有安卓专属补丁通过安卓通用内核与通用内核镜像机制统一管理。受支持的内核分支与维护周期记录在kernel/configs/kernel-lifetimes.xml，各分支通用内核镜像配置片段存放于kernel/configs/。

安卓专属内核功能

安卓内核并非原版 Linux，内置多个安卓专属子系统与驱动：

通用内核镜像机制（GKI）

谷歌自 Android 12 推出通用内核镜像架构，解决内核碎片化问题。 通用内核镜像推出前，每款设备都有独立内核：上游 Linux 长期支持版本 → 谷歌安卓通用内核分支 → 芯片厂商二次分支 → 设备厂商三次分支，碎片化问题极其严重。设备搭载的内核版本常年落后上游，安全补丁推送周期长达数月。

通用内核镜像设计思路：同一安卓版本、同一内核主线共用一套谷歌编译的通用内核镜像。厂商专属功能以可加载内核模块形式存放于独立厂商动态加载内核模块分区。谷歌可独立更新内核主体，无需依赖厂商适配。

AOSP 源码树中与内核相关目录：

• kernel/configs/：通用内核镜像配置片段
• kernel/prebuilts/：开发用预编译内核镜像
• kernel/tests/：内核测试套件

完整内核源码通常通过独立内核仓库拉取，拉取命令为 repo init -u https://android.googlesource.com/kernel/manifest，因其体积巨大，绝大多数平台开发者无需修改内核源码。

1.3.3 第二层：硬件抽象层（HAL）

硬件抽象层是用户态代码与硬件驱动之间的接口，一套框架可通过硬件抽象层适配不同硬件，无需修改上层框架代码。

硬件抽象层架构演进

1. 传统硬件抽象（特雷布尔之前） 安卓 8.0 之前的旧硬件抽象以动态库形式存在，通过 dlopen 加载至调用进程。例如相机硬件抽象会被相机服务直接加载。缺点是框架与硬件抽象强耦合，更新框架必须同步更新厂商硬件抽象，无法单独升级系统分区。

2. 项目特雷布尔（安卓 8.0）引入硬件接口定义语言 将硬件抽象拆分至独立进程，通过硬件 Binder 通信，提供版本化稳定接口，实现三大能力：

• 系统分区快速升级：厂商无需重新适配硬件抽象，即可升级上层安卓框架
• 通用系统镜像：一套系统镜像可适配多款设备
• 厂商测试套件：自动化校验硬件抽象实现合规性

1. 稳定安卓接口定义语言（安卓 11 起） 稳定安卓接口定义语言为当前首选硬件抽象接口语言，复用应用层安卓接口定义语言语法，配套稳定原生开发套件后端供厂商实现。所有新增硬件抽象必须使用安卓接口定义语言，硬件接口定义语言停止新增接口，仅维护存量旧接口。

硬件抽象层接口目录

硬件抽象层标准接口统一存放于 hardware/interfaces/：

hardware/interfaces/
    audio/              -- Audio HAL (capture, playback, effects)
    automotive/         -- Automotive-specific HALs (vehicle, EVS)
    biometrics/         -- Fingerprint, face authentication
    bluetooth/          -- Bluetooth HAL
    boot/               -- Boot control HAL (A/B updates)
    broadcastradio/     -- FM/AM radio
    camera/             -- Camera HAL (camera2 API backend)
    cas/                -- Conditional Access System (DRM for broadcast)
    confirmationui/     -- Trusted UI confirmation
    contexthub/         -- Context Hub (always-on sensor processor)
    drm/                -- DRM plugin HAL (Widevine, etc.)
    dumpstate/          -- Bug report generation
    fastboot/           -- Fastboot HAL
    gatekeeper/         -- Password/PIN verification
    gnss/               -- GPS/GNSS location
    graphics/           -- Graphics HALs:
        allocator/      --   Gralloc (buffer allocation)
        composer/       --   HWC (hardware composer for display)
        mapper/         --   Buffer mapping
    health/             -- Battery/charging health
    identity/           -- Identity credential
    input/              -- Input classifier
    ir/                 -- Infrared (IR blaster)
    keymaster/          -- Cryptographic key management
    light/              -- LED/backlight control
    media/              -- Media codec (OMX/Codec2)
    memtrack/           -- Memory tracking
    neuralnetworks/     -- NNAPI (ML acceleration)
    nfc/                -- NFC
    power/              -- Power management, power hints
    radio/              -- Telephony radio (RIL replacement)
    secure_element/     -- Secure element access
    sensors/            -- Sensor HAL (accelerometer, gyro, etc.)
    soundtrigger/       -- Hotword detection
    thermal/            -- Thermal management
    tv/                 -- TV input framework
    usb/                -- USB HAL
    vibrator/           -- Haptic feedback
    wifi/               -- Wi-Fi HAL
    ... and more (60+ HAL interfaces total)

每个硬件抽象目录包含安卓接口定义语言或硬件接口定义语言文件、默认实现、厂商测试套件用例。

The Treble Boundary：厂商原生开发套件与厂商分区

项目特雷布尔在系统分区与厂商分区之间设立硬性隔离边界： 系统分区存放谷歌、厂商维护的框架代码，可独立升级；厂商分区存放芯片厂商开发的硬件抽象与驱动。

厂商原生开发套件是厂商代码允许链接的系统库白名单。厂商代码禁止链接任意系统内部库，仅能使用白名单内组件。该限制在编译期与运行期通过链接器命名空间强制管控，配置文件存放于 system/linkerconfig/。

1.3.4 第三层：原生服务与原生库

内核、硬件抽象层之上，是整套 C/C++ 原生服务与原生库，是系统底层执行核心，负责画面合成、音频混音、输入分发、媒体编解码等核心功能。

核心原生服务

1. 界面合成服务SurfaceFlinger（路径 frameworks/native/services/surfaceflinger/） 界面合成服务是系统显示合成器。屏幕上所有画面图层都由它合成。它接收各应用通过缓冲队列传递的图形缓冲区，通过图形处理器软件合成或硬件合成器硬件合成画面，最终输出至显示屏。界面合成服务管理多显示器、垂直同步时序，与窗口管理服务协同处理窗口布局与可见性。

2. 音频合成服务AudioFlinger（路径 frameworks/av/services/audioflinger/） 音频混音与路由服务。接收各类应用音频流，按照音乐、通知、闹钟、通话等类型混音，叠加音效后通过音频硬件抽象分发至对应输出设备，同时处理采样率转换、声道映射、音频延迟管控。

3. 输入事件服务InputFlinger（路径 frameworks/native/services/inputflinger/） 读取内核 /dev/input 下触摸、键盘、鼠标原始事件，完成事件分类后分发给对应窗口。输入分发器维护窗口与输入通道映射，保证触摸精准下发，系统返回、主页、多任务手势会优先拦截。

4. 相机服务CameraService（frameworks/av/services/camera/） 应用相机 2 接口与厂商相机硬件抽象的中间层，管理相机设备生命周期、预览拍照数据流。

5. 媒体播放器服务 / 媒体编解码服务MediaPlayerService / MediaCodecService（frameworks/av/） 媒体播放与编解码核心，Codec2 为新一代编解码框架，替代旧有 OMX 架构，统一软硬件解码器管理。

6. 服务管理器ServiceManager（frameworks/native/cmds/servicemanager/） 原生 Binder 服务注册中心。所有跨进程服务必须向服务管理器注册，客户端通过名称查询服务。系统存在三类独立服务管理器：框架 Binder 管理器、硬件 Binder 管理器、厂商 Binder 管理器。

Bionic：安卓自研 C 标准库

Bionic 存放于 bionic/，并非 glibc，基于 BSD 代码从零开发，设计目标四点：

1. 体积小巧：适配移动端有限内存；
2. 启动速度快：动态库加载、线程创建等高频操作深度优化；
3. BSD 许可证：规避 LGPL 约束；
4. 安卓专属扩展：系统属性、日志打印、Binder 原生支持。

Bionic 子目录：

bionic/libc/ C 标准库主体

bionic/libm/ 数学库

bionic/libdl/ 动态加载库

bionic/linker/ 64 位动态链接器，实现特雷布尔所需链接命名空间隔离，管控不同进程可见库范围。

位于bionic/linker/中的动态链接器尤为重要，它实现链接器命名空间隔离，强制保障 Treble 边界。各类命名空间（default、sphal、vndk、rs）控制进程可见的库，阻止厂商代码访问不稳定的系统库。

1.3.5 第四层：Android 运行时（ART）

Android 运行时代码存放于 art/，负责执行应用字节码，安卓 5.0 起彻底替代Dalvik虚拟机。

Android 运行时多级编译流程

Android 运行时采用四层混合编译策略：

1. 解释器：逐行执行字节码，速度最慢，用于调试、低频代码；
2. 即时编译器JIT (Just-In-Time)：运行时将高频方法编译为本地机器码，同时采集运行剖面存入磁盘；
3. 预先编译器AOT (Ahead-Of-Time) dex2oat：利用即时编译器采集的剖面，在设备闲置或应用安装时预编译高频方法，即剖面引导优化；
4. 云端剖面Cloud Profiles（安卓 9+）：谷歌应用商店下发全网聚合剖面，应用安装时直接预编译高频代码，无需用户运行采集。

art/目录下的 ART 源码树包含：

• art/runtime/— 运行时本身（垃圾回收、类加载、JNI、线程管理）
• art/compiler/— JIT 和 AOT 编译器
• art/dex2oat/— AOT 编译工具
• art/libartbase/— 基础工具库
• art/libdexfile/— DEX 文件解析
• art/libnativebridge/— 在 x86 上运行 ARM 应用的原生桥接（Berberis/Houdini 转换所使用）
• art/libnativeloader/— 具备命名空间隔离能力的库加载器
• art/odrefresh/— ART 模块产物的设备端刷新工具
• art/openjdkjvm/— JVM 接口实现
• art/openjdkjvmti/— JVMTI（调试 / 性能分析）接口
• art/profman/— PGO 剖面管理器
• art/imgdiag/— 启动镜像诊断工具

孵化进程

孵化进程入口 frameworks/base/cmds/app_process/、system/zygote/，是安卓核心架构创新，所有应用进程、系统服务进程均由孵化进程派生。

安卓开机流程：

1. init 进程启动 Zygote（严格来讲，启动的是app_process64二进制程序）
2. Zygote 初始化 ART 运行时
3. Zygote 预加载所有应用共用的数千个 Java 类与资源
4. Zygote 进入循环，通过 Unix 域套接字等待指令

需要新建应用进程时：

1. 活动管理服务向 Zygote 的套接字发送指令
2. Zygote 调用 fork () 生成子进程
3. 子进程通过写时复制内存共享，继承全部预加载类与资源
4. 子进程进行差异化初始化：设置 UID、GID、SELinux 上下文，加载应用 APK 并启动运行

这种基于 fork 的架构实现了安卓应用快速启动。若无 Zygote，每个应用都要独立新建 ART 实例，加载校验大量类、解析框架资源，耗时可达数秒。使用 Zygote 后，fork () 仅消耗毫秒级时间，共享内存页也减少物理内存开销。

1.3.6 第五层：框架系统服务（system_server）

system_server 是孵化进程创建的首个进程，内部承载超过一百个系统服务，管控整机全部用户交互逻辑。

system_server 服务清单

所有系统服务 Java 代码存放于 frameworks/base/services/core/java/com/android/server/：

以下列出frameworks/base/services/core/java/com/android/server/下更为完整的服务子目录清单：

表格