2. Android系统架构总览
Android 并不是一个“单层操作系统”，而是一套自下而上逐层抽象、逐层向上暴露能力的软件栈。理解这套分层关系，是进行 Framework 系统定制的前提：只有先判断需求落在哪一层，才能决定改 AOSP 源码、改 HAL 接口、改 Native 服务，还是只做应用层适配。本节从下到上梳理 Linux 内核、HAL、Native 库、Android Runtime、Framework 层与应用层，并给出每一层典型的定制切入点。
一、分层结构总览
Android 官方架构图通常把系统划分为五段：Linux 内核、硬件抽象层（HAL）、Native C/C++ 库与 Android Runtime、Java API Framework、系统应用。它们之间不是简单的“上下级调用”，而是通过 Binder、HIDL/AIDL、JNI、系统调用等机制形成多条纵向通道。下图给出本节的核心分层关系与定制入口。
二、各层职责与关键机制
Linux 内核位于最底层，负责进程调度、内存管理、网络、驱动与电源管理。Android 在内核中额外引入了 Binder 驱动、ashmem、低内存杀手（LMK）等特性。内核向上通过系统调用暴露能力，是 HAL 与 Native 库运行的物理基础。
HAL 是 Android 为“屏蔽硬件差异”设计的抽象层。它把 Camera、Audio、Sensors 等硬件能力封装成标准接口，Framework 只依赖接口而不依赖具体芯片。Android 8 之前 HAL 以 .so 形式被直接加载，8 之后改为 HIDL，Android 11 起逐步迁移到 AIDL。HAL 是芯片厂商与整机厂定制最集中的区域。
Native 库与 ART 并列位于 HAL 之上。Native 库提供 libc、libbinder、libui、OpenGL ES、Media 等 C/C++ 能力；ART 负责执行 DEX 字节码，通过 AOT+JIT 混合编译、并发 GC 与 JNI 与 Native 世界互通。二者共同构成“运行时底座”。
Java API Framework 是应用开发者最熟悉的层，由 SystemServer 启动并托管 ActivityManagerService、WindowManagerService、PackageManagerService 等核心服务。它通过 Binder 向应用暴露 API，同时向下调用 Native 服务与 HAL。
应用层包括系统应用与第三方应用，运行在各自沙箱中，通过 Framework API 与系统交互。系统应用往往拥有更高权限，是定制默认行为的重要落点。
三、定制切入点对照表
| 层级 | 典型定制需求 | 常用手段 | 风险与注意点 |
|---|---|---|---|
| Linux 内核 | 驱动移植、内核裁剪、SELinux 策略 | 修改 defconfig、设备树、sepolicy | 影响启动与稳定性，需重新编译 boot.img |
| HAL | 适配自研硬件、新增传感器/外设 | 实现 HIDL/AIDL 接口、注册 hwservicemanager | 接口版本需与 Framework 匹配，否则服务启动失败 |
| Native 库 | 替换编解码、图形栈、Native 服务 | 修改 AOSP external/ 或 frameworks/native | ABI 兼容性与依赖库版本需同步 |
| ART | 启动速度、内存占用、编译策略调优 | 调整 dalvik.vm 参数、dex2oat 策略 | 过度 AOT 会增大存储占用，需权衡 |
| Framework | 系统服务行为、权限策略、开机流程 | 修改 frameworks/base、SystemServer 启动顺序 | 改动面广，需回归 CTS 与 GMS 兼容性 |
| 应用层 | 预置应用、默认桌面、默认配置 | device.mk 预置 APK、overlay 资源 | 注意签名与权限白名单 |
四、案例：定制一个“开机自动启动自研服务”
假设需求是：设备开机后自动启动一个自研后台服务，并向上层应用提供接口。可按以下路径判断落点：
- 若服务只涉及纯软件逻辑，优先做成 Framework 系统服务，注册到 SystemServer。
- 若服务需要访问自研硬件，则先在 HAL 层定义接口，再在 Framework 层封装 Manager。
- 若服务需要常驻 Native 进程，可写成 init.rc 中启动的 native service，并通过 Binder 暴露。
# 示例：在 init.rc 中注册自研 Native 服务
service myservice /system/bin/myservice
class main
user system
group system
seclabel u:r:myservice:s0
# 在 device.mk 中预置可执行文件
PRODUCT_PACKAGES += myservice五、常见误区与复盘
- 误区一：所有需求都改 Framework。 若硬件差异未在 HAL 层隔离，Framework 改动会被芯片差异反复污染，难以维护。
- 误区二：忽略 HAL 接口版本。 HIDL/AIDL 接口有版本号，Framework 与 HAL 版本不匹配会导致服务无法注册，表现为开机后功能静默失效。
- 误区三：只改应用层就以为完成定制。 默认权限、开机自启、系统签名等往往需要 Framework 或系统应用配合。
- 误区四：不做分层回归。 改动越靠下，影响面越大。内核与 HAL 改动必须回归启动、功耗、CTS；Framework 改动需回归 GMS 与兼容性测试。
掌握这套分层关系后，面对任何定制需求，都可以先画出“数据流经哪些层、接口在哪一层定义、权限在哪一层校验”，再决定修改范围。这是 Android Framework 系统定制工程中最基础也最关键的一步。