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 需要抓住四条主线:
- 构建主线:源码获取 → 工具链准备 → Bazel/Kleaf 构建 → 生成 boot.img、vendor_boot.img、system_dlkm 等镜像;
- 接口主线:KMI 符号列表(symbol list)→ ABI 监控 → 模块签名与校验;
- 适配主线:设备树(DTS)→ defconfig → vendor 模块 → 分区与启动链;
- 验证主线:VTS/CTS → KMI 检查 → 启动日志 → 稳定性与性能测试。
一句话概括:GKI 把“内核”变成可独立更新的通用件,把“硬件适配”收敛到模块与设备树,从而让设备既能长期获得安全补丁,又能保留厂商差异化能力。
下图展示了 GKI 的整体知识框架与实战路线,从概念到构建、适配、验证形成闭环:
三、方法流程:从源码到可启动设备
GKI 构建与适配的典型流程如下:
- 环境准备:安装 repo、Bazel、Kleaf 依赖,配置 Android 内核源码树;
- 选择分支:根据 Android 版本与内核版本选择
android14-6.1等 GKI 分支; - 构建 GKI:使用
tools/bazel或 Kleaf 目标构建//common:kernel_aarch64; - 构建 vendor 模块:在
vendor/或设备目录下编译.ko; - 生成镜像:打包
boot.img、vendor_boot.img、system_dlkm.img; - 刷机验证:通过 fastboot 刷入,检查启动日志与 KMI 兼容性;
- 问题复盘:记录符号缺失、签名失败、设备树冲突等问题并回归。
# 典型 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 适配涉及启动链,任何一次错误刷写都可能导致设备无法启动,回退能力是实战的前提。