1. 课程导入
Android 系统定制工程是移动终端产品差异化的核心能力之一。无论是手机厂商、车机方案商、平板与 IoT 设备团队，还是需要深度集成行业应用的开发者，都绕不开对 Android Framework 的修改与扩展。本课程面向具备一定 Android 应用开发基础、希望进入系统层开发的工程师，系统讲解从源码结构、编译构建、核心服务到定制落地与问题排查的完整工程链路。
一、学习目标：从"会用"到"能改"
学习本课程后，你应当能够独立完成以下工作：
- 读懂 AOSP 源码目录结构，定位 Framework 层关键模块与文件；
- 搭建可编译、可刷机、可调试的 Android 源码开发环境；
- 理解 Zygote、SystemServer、Binder、AMS、PMS、WMS 等核心机制的协作关系；
- 对系统服务进行新增、裁剪、Hook 或行为改写，并保证系统稳定性；
- 定制系统 UI、开机流程、权限策略、默认配置与预置应用；
- 使用日志、Systrace、dumpsys、GDB 等工具定位系统级问题。
核心判断标准：不是"能编译通过"，而是"改动可解释、影响可评估、问题可回滚"。系统定制工程的第一原则是可控性。
二、核心概念：Framework 到底指什么
Android 系统自上而下通常划分为应用层、Framework 层、Native 层、HAL 层与内核层。Framework 层是承上启下的关键：向上为应用提供 API，向下通过 JNI 调用 Native 服务，并通过 Binder 完成跨进程通信。
需要重点建立三个认知：
- 进程视角：system_server 是绝大多数系统服务的宿主进程，Zygote 是所有应用进程的孵化器，Binder 是它们之间的"神经系统"。
- 接口视角：AIDL 定义接口，Binder 驱动完成传输，Manager 类为应用提供易用封装。
- 构建视角：Android.bp、Android.mk、product 配置、BoardConfig 共同决定"编译出什么、装进哪个分区"。
下面这张图展示了 Android Framework 定制工程的整体知识框架与各模块之间的依赖关系，可作为后续章节的学习地图。
三、方法流程：一次系统定制的标准动作
系统定制不是"改一行代码就完事"，而是一条有明确顺序的工程流水线。推荐按以下步骤推进：
- 需求拆解：明确要改的是行为、界面、权限还是默认配置，判断落在哪一层。
- 源码定位：通过 grep、cscope 或 Android Studio 索引找到目标类与调用链。
- 方案设计：优先选择配置化、可开关、可回滚的方案，避免硬编码。
- 编译验证：使用增量编译快速验证，必要时整包编译并刷机。
- 功能与稳定性测试：覆盖开机、应用启动、权限、异常恢复等场景。
- 补丁归档：形成可复用的 patch 与文档，便于后续版本升级。
# 典型编译与验证命令
source build/envsetup.sh
lunch aosp_arm64-userdebug
make -j8 framework
adb root && adb remount
adb push out/target/product/.../system/framework/framework.jar /system/framework/
adb shell stop && adb shell start四、案例场景：定制一个"开机默认关闭蓝牙"的需求
这是一个看似简单、实则能串起多个知识点的典型场景。需求是设备首次开机后蓝牙默认关闭，且用户手动开启后重启仍保持关闭状态。
- 定位默认值：蓝牙默认状态通常由系统配置与 SettingsProvider 默认值共同决定；
- 修改配置：在 overlay 或默认配置中调整对应开关，而不是直接改业务逻辑；
- 验证路径：刷机后检查
adb shell settings get global bluetooth_on； - 回归风险：确认不会影响蓝牙服务启动、配对流程与系统升级后的默认值继承。
优先使用资源 overlay 与产品配置实现默认值定制，能显著降低与后续 AOSP 版本合并时的冲突成本。
五、常见误区与复盘
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 直接修改 framework.jar 中的业务代码 | 升级困难、冲突频繁、难以回滚 | 优先配置化、overlay、可开关补丁 |
| 只验证功能，不验证开机与异常恢复 | 偶发开机失败、服务崩溃 | 覆盖开机、重启、低内存、权限异常场景 |
| 忽略 SELinux 与权限限制 | 服务无法访问资源或直接被拒绝 | 同步检查 avc denied 日志与权限白名单 |
| 不做补丁归档与文档 | 人员变动后无法维护 | 形成 patch、变更说明与验证清单 |
系统定制的高风险动作包括：修改 system_server 启动顺序、改动 Binder 接口签名、调整 SELinux 策略、修改分区与镜像布局。这些操作必须在小范围验证后再合入主线。
六、学习路径建议
建议按"环境 → 机制 → 定制 → 排障 → 工程化"的顺序推进：先能编译和刷机，再理解 Zygote、SystemServer 与 Binder 的协作，然后从默认值、系统 UI、权限策略等低风险定制入手，逐步过渡到系统服务改造，最后补齐日志分析、性能追踪与补丁管理能力。每学完一个模块，都应在真实源码上完成一次"定位—修改—编译—验证—归档"的闭环，这样才能把知识转化为可交付的工程能力。