2. Android内核演进与GKI背景
Android 内核并不是一块“随系统一起打包的黑盒”，它同时承担硬件抽象、驱动承载、电源管理、安全隔离与调度等职责。早期 Android 设备厂商通常基于某个 Linux LTS 版本，自行合入 SoC 厂商补丁、外设驱动和产品定制，再与自家 Android 版本绑定发布。这种模式在设备数量少、迭代慢时可行，但当 Android 生态扩展到数百家 OEM、数千款机型后，内核碎片化迅速成为系统升级的最大阻力之一。
一、内核碎片化的根因与代价
碎片化并非单一问题，而是多层分叉叠加的结果。最上层是 Linux 主线版本分叉：不同设备停留在 4.4、4.9、4.14、4.19、5.4、5.10 等不同 LTS 分支；中间层是 SoC 厂商 BSP 分叉，高通、联发科、三星、紫光展锐等会加入大量平台补丁；最下层是 OEM/ODM 定制分叉，包括摄像头、指纹、充电、显示、音频等驱动与调试代码。三层分叉叠加后，同一 Android 版本在不同设备上的内核接口、配置项、驱动行为和补丁集几乎无法复用。
其代价非常直接：Android 安全公告中的内核 CVE 修复需要逐机型回移；Google 发布新 Android 版本时，OEM 必须把新框架“移植”到旧内核上；SoC 厂商停止维护后，设备即使硬件仍可用，也难以获得新内核。结果是大量设备长期停留在旧内核，既增加安全风险，也拖慢生态整体升级节奏。
核心矛盾：Android 框架层希望快速迭代，而内核与驱动层被绑定在具体 SoC 和具体设备上，二者更新节奏严重不匹配。
二、Project Treble：先分离框架与厂商实现
Project Treble 是 Google 在 Android 8.0 引入的架构级改造，目标是把 Android 框架与厂商实现解耦。它在系统分区与厂商分区之间定义了稳定的 Vendor Interface（VINTF），并通过 HIDL/AIDL 等稳定接口进行通信。这样，系统分区可以独立升级，而厂商分区中的 HAL 与内核相关实现可以保持相对稳定。
Treble 解决的是“框架与厂商 HAL 之间”的接口稳定问题，但并没有完全解决内核本身的碎片化。因为内核仍然由 OEM 自行选择版本、自行合入补丁，框架升级时仍可能要求内核具备某些新特性。于是 Google 继续向下推进，把稳定边界从 HAL 延伸到内核，这就是 GKI 的出发点。
三、GKI 的定义与 KMI 稳定接口
GKI（Generic Kernel Image，通用内核镜像）是 Google 提出的内核架构方案：由 Google 提供统一编译的通用内核镜像，OEM 与 SoC 厂商不再直接修改核心内核，而是通过可加载内核模块（.ko）的方式提供设备与平台相关驱动。GKI 的关键在于 KMI（Kernel Module Interface，内核模块接口），即内核与模块之间保持稳定的符号、结构体布局与函数签名集合。
KMI 的稳定性由 ABI 监控保障。Google 会为每个 GKI 内核版本维护一份符号列表（如 abi_gki_aarch64），模块只能使用列表中允许的符号。若厂商需要新增符号，必须走 ABI 申请流程，而不是直接改内核源码。这样，同一个 GKI 内核可以跨设备、跨 SoC 复用，模块则按设备差异单独编译和加载。
四、模块化设计动机与工程收益
GKI 的模块化设计并非为了“好看”，而是为了解决真实工程问题。第一，安全更新可独立进行：Google 修复 GKI 内核中的 CVE 后，OEM 只需更新内核镜像，不必重新编译和验证所有驱动。第二，减少重复维护：同一 SoC 平台的多款设备可以共享同一 GKI 内核，模块差异被隔离在 .ko 中。第三，提升兼容性验证效率：KMI 稳定后，模块与内核的接口契约明确，CTS/VTS 与 GKI 兼容性测试可以自动化执行。
第四，支持更长的设备生命周期：即使 SoC 厂商停止 BSP 维护，只要 GKI 内核仍在更新，OEM 仍可通过模块继续适配。第五，降低升级门槛：Android 版本升级时，框架与 GKI 内核可分别推进，减少“牵一发动全身”的移植工作。
五、关键概念对照与常见误区
| 概念 | 作用范围 | 稳定对象 | 典型产物 |
|---|---|---|---|
| Project Treble | 框架与厂商 HAL 之间 | VINTF / HIDL / AIDL 接口 | system 分区与 vendor 分区解耦 |
| GKI | 内核与设备驱动之间 | KMI 符号与 ABI | 统一内核镜像 + 可加载模块 |
| KMI | 内核与模块的契约 | 符号列表、结构体布局、函数签名 | abi_gki_aarch64 白名单 |
| Vendor Module | 设备/平台差异实现 | 模块自身接口 | *.ko 文件与模块配置 |
常见误区一：认为 GKI 就是“所有设备用同一个内核”。实际上 GKI 是同一内核基线，不同设备仍可通过模块和配置实现差异，只是不再分叉内核源码。
常见误区二：认为 KMI 稳定意味着内核完全不能改。KMI 稳定的是对外符号与 ABI，内核内部实现仍可优化，只要不破坏模块可见接口。
常见误区三：把 Treble 与 GKI 混为一谈。Treble 解决 HAL 接口稳定，GKI 解决内核与模块接口稳定，二者是分层递进关系。
六、从碎片化到 GKI 的演进路径
回顾演进路径可以更清晰地理解 GKI 的定位：阶段一，各厂商自由分叉内核，碎片化严重；阶段二，Project Treble 分离框架与厂商实现，但内核仍各自为政；阶段三，GKI 引入统一内核镜像与 KMI 稳定接口，模块化承载设备差异；阶段四，Android 12 之后 GKI 成为强制要求，Android 13/14/15 持续强化 ABI 监控与模块化规范。
对开发者而言，这意味着构建 Android 内核时，不能再简单地把所有驱动编进内核镜像，而要理解 GKI 的模块划分、KMI 符号约束和 ABI 检查流程。后续章节将围绕 GKI 内核源码获取、配置、编译与模块签名展开具体操作。
# 查看当前内核是否为 GKI 及 KMI 版本
adb shell uname -r
# 示例输出：5.10.198-android13-4-00003-g1234567890ab
# 查看已加载的 vendor 模块
adb shell lsmod | head -20
# 查看 GKI 内核符号白名单（源码树中）
cat android/abi_gki_aarch64
理解 GKI 的背景与动机，是后续所有构建与适配工作的前提。只有明确“哪些属于通用内核、哪些属于模块、哪些接口必须稳定”，才能在编译配置、模块开发和兼容性测试中做出正确决策。