3. GKI架构与核心组件

要真正理解 GKI（Generic Kernel Image）设备适配，不能只记住“内核和驱动分开了”这句话，而必须把镜像、模块、设备树和分区布局放在同一张图上理解。GKI 的核心思想是：Google 提供统一编译、统一 ABI 的通用内核镜像与 GKI 模块，芯片厂商和 OEM 只维护与硬件强相关的 vendor 模块、设备树和启动参数。这样内核可以独立升级，而 vendor 部分保持稳定。

一、核心组件与职责边界

GKI 体系中的组件可以按“谁提供、放哪里、何时加载”三个维度划分。GKI 内核镜像通常以 Image 或 Image.lz4 形式存在，由 Google 基于 ACK（Android Common Kernel）编译，提供调度、内存管理、文件系统、网络协议栈等通用能力。GKI 模块是随内核一起编译、但以 .ko 形式存在的模块，例如 system_dlkm 中的部分驱动，它们与内核 ABI 严格匹配。

vendor 模块则由芯片厂商或 OEM 编译，放在 vendor_dlkm 分区中，例如显示、摄像头、音频、触控、电源管理等硬件驱动。它们通过 KMI（Kernel Module Interface）与 GKI 内核通信，不能随意调用未导出的内核符号。设备树 dtb 描述板级硬件拓扑，dtbo 则是叠加在基础 dtb 上的覆盖层，用于同一平台不同机型的外设差异。

二、镜像与分区布局关系

启动时，bootloader 按分区表依次加载 boot.img、vendor_boot.img、dtbo 等分区。boot.img 中包含 GKI 内核镜像和通用 ramdisk；vendor_boot.img 中包含 vendor ramdisk、vendor 模块和部分设备树；dtb 可能内嵌在 boot 镜像中，也可能独立存放；dtbo 通常位于独立分区，由 bootloader 在启动早期叠加。

三、方法流程：从源码到启动的适配链路

实际适配时，工程师通常按以下顺序推进。第一步，确认目标平台的 GKI 内核版本和 KMI 版本，例如 Android 14 对应 kernel 6.1，KMI 为 android14-6.1。第二步，在 vendor 源码中编译 vendor 模块，确保只使用 KMI 允许的符号。第三步，配置设备树，基础 dtb 描述 SoC 级硬件，dtbo 描述机型差异。第四步，打包 boot.img 和 vendor_boot.img，写入对应分区。第五步，刷机启动，通过 dmesg 和 lsmod 验证模块加载情况。

# 查看当前内核与 KMI 版本
adb shell uname -r
adb shell cat /proc/version

# 查看已加载模块
adb shell lsmod | grep -E "vendor|gki"

# 查看设备树节点
adb shell ls /proc/device-tree/

# 查看分区布局
adb shell ls -l /dev/block/by-name/

四、案例场景：同一 SoC 多机型适配

假设某芯片平台有 A、B 两款手机，SoC 相同但屏幕、摄像头和充电 IC 不同。GKI 方案下，A 和 B 共用同一份 GKI 内核镜像和 system_dlkm 模块；差异部分通过 vendor_dlkm 中的不同驱动模块，以及 dtbo 中的不同设备树覆盖层实现。boot.img 完全一致，vendor_boot.img 和 dtbo 分区按机型分别打包。这样 Google 推送内核安全补丁时，A、B 都能直接升级，无需芯片厂商重新编译内核。

五、常见误区与复盘

理解这些组件的边界和分区归属，是后续进行 GKI 内核编译、模块签名、设备树调试和 OTA 升级的基础。只有把“谁提供、放哪里、何时加载、如何升级”四个问题回答清楚，才能在设备适配中避免启动失败和内核升级不兼容的问题。