1. 课程导入

Android GKI(Generic Kernel Image,通用内核镜像)是 Google 从 Android 11 开始推行的内核架构方案,其核心目标是把内核拆分为“通用内核”与“厂商模块”两部分,让 Android 设备能够长期、稳定地获得内核安全更新。对于设备适配工程师而言,掌握 GKI 内核构建与设备适配,意味着能够在保持 GKI 兼容性的前提下,把厂商驱动、硬件差异和产品配置正确接入系统。本课程围绕这一目标展开,从概念、构建、适配到调试,形成一条完整的实战路线。

一、学习目标

完成本课程后,你应当具备以下能力:

  • 理解 GKI、KMI、ABI、GSI、VTS 等核心概念及其相互关系;
  • 能够搭建 Android 内核源码环境,使用 Bazel/Kleaf 构建 GKI 内核与厂商模块;
  • 掌握 KMI 符号列表、模块签名、AVB 校验等关键机制;
  • 能够为具体设备编写和调试 vendor 模块、设备树与 defconfig;
  • 能够通过日志、VTS、KMI 检查等手段定位适配问题;
  • 形成可复用的设备适配流程与问题复盘方法。

二、核心概念与整体知识框架

GKI 的本质是“内核接口稳定化”。Google 将内核中与硬件无关的部分编译为 vmlinux 与 Image,并对外暴露一组稳定的 KMI(Kernel Module Interface)符号;厂商驱动则以可加载模块(.ko)形式存在,通过 KMI 与通用内核交互。这样,通用内核可以独立升级,而厂商模块只需保证与 KMI 兼容。

理解 GKI 需要抓住四条主线:

  1. 构建主线:源码获取 → 工具链准备 → Bazel/Kleaf 构建 → 生成 boot.img、vendor_boot.img、system_dlkm 等镜像;
  2. 接口主线:KMI 符号列表(symbol list)→ ABI 监控 → 模块签名与校验;
  3. 适配主线:设备树(DTS)→ defconfig → vendor 模块 → 分区与启动链;
  4. 验证主线:VTS/CTS → KMI 检查 → 启动日志 → 稳定性与性能测试。

一句话概括:GKI 把“内核”变成可独立更新的通用件,把“硬件适配”收敛到模块与设备树,从而让设备既能长期获得安全补丁,又能保留厂商差异化能力。

下图展示了 GKI 的整体知识框架与实战路线,从概念到构建、适配、验证形成闭环:

Android GKI 内核构建与设备适配 · 知识框架 GKI 通用内核镜像 vmlinux / Image / KMI 符号 构建主线 源码 / 工具链 / Bazel boot.img · vendor_boot 适配主线 DTS / defconfig vendor 模块 · 分区 验证主线 VTS / CTS / KMI 检查 启动日志 · 稳定性 Kleaf / Bazel 构建 GKI + 模块编译 KMI 符号与 ABI 符号列表 · 模块签名 设备启动链 bootloader → kernel → init 实战闭环:构建 → 适配 → 刷机 → 验证 → 复盘 以 KMI 兼容性为约束,以设备可启动、可过测、可长期升级为目标

三、方法流程:从源码到可启动设备

GKI 构建与适配的典型流程如下:

  1. 环境准备:安装 repo、Bazel、Kleaf 依赖,配置 Android 内核源码树;
  2. 选择分支:根据 Android 版本与内核版本选择 android14-6.1 等 GKI 分支;
  3. 构建 GKI:使用 tools/bazel 或 Kleaf 目标构建 //common:kernel_aarch64;
  4. 构建 vendor 模块:在 vendor/ 或设备目录下编译 .ko;
  5. 生成镜像:打包 boot.img、vendor_boot.img、system_dlkm.img;
  6. 刷机验证:通过 fastboot 刷入,检查启动日志与 KMI 兼容性;
  7. 问题复盘:记录符号缺失、签名失败、设备树冲突等问题并回归。
# 典型 GKI 构建命令示例
repo init -u https://android.googlesource.com/kernel/manifest -b common-android14-6.1
repo sync -j8

# 使用 Kleaf 构建 GKI 内核
tools/bazel build //common:kernel_aarch64

# 构建 vendor 模块(示例)
tools/bazel build //vendor/xxx:xxx_modules

# 输出镜像位置
out/kernel_aarch64/dist/boot.img
out/kernel_aarch64/dist/vendor_boot.img

四、案例与场景:一个真实适配片段

假设某设备从 Android 13 升级到 Android 14,内核从 5.15 切换到 6.1 GKI。适配时常见的问题是:厂商触摸屏驱动依赖一个未出现在 KMI 符号列表中的内核函数,导致模块加载失败。此时不能直接修改通用内核,而应:

  • 检查 abi_gki_aarch64 符号列表,确认该符号是否被允许;
  • 若不允许,改用 KMI 中已有的替代接口,或把逻辑上移到用户空间;
  • 若确需新增符号,走 Google 的 KMI 符号申请流程,而不是私自导出;
  • 重新编译模块并用 modprobe 验证,观察 dmesg 中的符号解析错误。

常见误区:把 GKI 当成“普通内核”直接改 vmlinux 或随意导出符号。这样做会破坏 KMI 稳定性,导致后续 GKI 升级失败,甚至无法通过 VTS。正确做法是把硬件差异收敛到 vendor 模块、设备树和分区配置中。

五、核心概念速查表

概念 含义 在适配中的作用
GKI 通用内核镜像,硬件无关的内核部分 提供可独立升级的内核基础
KMI 内核模块接口,稳定的符号与结构集合 约束 vendor 模块与内核的交互边界
ABI 二进制接口,包括符号、结构布局等 用于监控兼容性变化
GSI 通用系统镜像,用于验证 Treble 兼容性 辅助判断设备是否满足 GKI 要求
VTS 供应商测试套件 验证内核与 vendor 接口是否符合规范
vendor_boot 存放 vendor 模块与设备树的分区 承载设备差异化内容

六、实战路线图与复盘要点

本课程的实战路线可以概括为“四步走”:第一步,理解 GKI 架构与 KMI 约束;第二步,完成一次完整的 GKI 内核构建;第三步,为具体设备接入 vendor 模块与设备树;第四步,通过刷机、日志和 VTS 完成验证与复盘。每一步都要保留构建日志、符号列表和刷机记录,便于出现问题时快速定位。

建议在学习过程中准备一台可刷机的开发设备或模拟环境,并始终保留一份“可回退”的原始镜像。GKI 适配涉及启动链,任何一次错误刷写都可能导致设备无法启动,回退能力是实战的前提。