1. 课程导入

Android GKI（Generic Kernel Image）是 Google 从 Android 12 起强推的内核交付范式：内核核心镜像由 Google 统一构建与维护，芯片厂商与 OEM 通过 KMI（Kernel Module Interface）与 GKI 解耦，把差异化的驱动、板级支持与厂商能力下沉为可加载模块。对量产项目而言，这意味着内核不再只是"编译出来能开机"的产物，而是一条贯穿芯片、系统、认证、OTA 与售后的工程链路。本课程的目标，是让你具备把 GKI 内核从源码稳定交付到量产设备、并支撑后续升级的完整能力。

学习目标：从"能编译"到"可量产、可升级"

本课程围绕四个可验证的能力目标展开。第一，理解 GKI 的架构边界与 ABI 稳定性约束，能判断哪些改动属于合法模块、哪些会破坏 KMI。第二，掌握 GKI 内核的构建、签名、打包与镜像产物结构，能独立产出可刷入的 boot、init_boot、vendor_boot、dtbo 等镜像。第三，掌握量产交付流程，包括 AVB 校验、vbmeta 链、认证测试与版本冻结。第四，掌握升级工程，包括 A/B 无缝升级、OTA 包制作、回滚策略与升级失败排障。

核心概念：GKI、KMI、ABI 与模块化

GKI 把内核拆成"通用核心 + 厂商模块"两层。通用核心由 Google 提供，包含调度、内存管理、文件系统、网络协议栈等；厂商模块以 .ko 形式存在，承载显示、摄像头、音频、电源、存储等差异化驱动。两层之间的契约就是 KMI，它由一组导出符号（symbol list）定义。ABI 则是这些符号在二进制层面的稳定性承诺，一旦冻结，模块与内核之间即可跨版本加载。

理解这一点，就能理解量产中的典型冲突：厂商想改核心代码，但核心属于 GKI，改动会破坏 ABI；正确做法是把改动做成模块，或通过 Kernel Module 与 vendor hook 机制实现。GKI 还引入了 boot.img 与 vendor_boot.img 的分离，前者放通用内核，后者放厂商 ramdisk 与 DTB，二者通过 bootconfig 传递参数。

方法流程：一条可复用的交付主线

把 GKI 交付拆成六个阶段，每个阶段都有明确的输入、输出与验收条件。环境搭建阶段准备 AOSP 源码、GKI 预编译内核、厂商模块源码与签名密钥；构建阶段产出内核镜像与模块；刷机验证阶段在真机上确认启动、驱动加载与功能正常；认证测试阶段跑通 CTS/GTS/VTS；OTA 升级阶段验证 A/B 切换与回滚；量产冻结阶段锁定版本并归档。

# 典型 GKI 构建与刷机命令序列
repo init -u https://android.googlesource.com/kernel/manifest -b common-android13-5.15
repo sync -j8
tools/bazel run //common:kernel_aarch64_dist
fastboot flash boot        boot.img
fastboot flash init_boot   init_boot.img
fastboot flash vendor_boot vendor_boot.img
fastboot flash vbmeta      vbmeta.img
fastboot reboot

案例场景：一次量产升级的典型链路

某项目在 Android 13 GKI 基线上新增一颗摄像头驱动。团队最初直接修改了核心内核的 sensor 框架代码，导致 KMI 符号表变化，模块无法加载。复盘后改为：把驱动做成独立 .ko，通过 vendor hook 接入框架，重新生成 symbol list 并校验 ABI 一致性。随后制作 OTA 包，在 A/B 设备上验证升级后摄像头可用、AVB 校验通过、回滚正常。这个案例说明：GKI 项目的核心不是"改内核"，而是"在契约内做扩展"。

常见误区与复盘清单