2. Android内核演进与GKI背景

Android 的内核问题并不是“Linux 内核本身不好”，而是 Android 生态把内核变成了一个被大量下游修改、长期冻结、又必须跨代兼容的“私有分支集合”。理解 GKI（Generic Kernel Image，通用内核镜像）的提出动机，必须回到 Android 内核碎片化的历史现场，看清 Project Treble 如何先解决框架与厂商接口的边界问题，再进一步把内核也抽象成可独立升级的通用层。

一、碎片化的根源：SoC、ODM 与内核分支的三重分叉

在早期 Android 中，Google 发布 AOSP 与 Linux 主线内核，SoC 厂商（高通、联发科、三星、紫光展锐等）基于某个 Linux LTS 版本拉出 BSP 分支，加入大量芯片驱动、电源管理、时钟、GPU、ISP、Modem 等私有补丁；ODM/OEM 再在此基础上加入屏幕、摄像头、指纹、充电等板级修改。结果是：同一 Android 版本，不同设备的内核源码树、配置、补丁集完全不同。

这种分叉带来三个直接后果：其一，内核安全补丁无法统一合入，厂商需要逐设备回移；其二，Android 版本升级往往被内核接口变化卡住，形成“升级即重做 BSP”的循环；其三，Google 无法对内核做统一的长期维护与测试。碎片化不是单点问题，而是供应链结构问题。

二、Project Treble：先把框架与厂商实现解耦

Android 8.0 引入 Project Treble，核心动作是定义稳定的 Vendor Interface（VINTF），把 Android 框架与厂商实现通过 HIDL/AIDL 等稳定接口隔开。系统分区（system）与厂商分区（vendor）可以独立升级，框架不再直接依赖厂商私有库的具体实现。

Treble 解决的是“用户空间”的解耦，但内核仍然是一个整体：框架通过系统调用、sysfs、procfs、ioctl、设备节点等与内核交互，这些接口并没有被稳定化。于是出现了一个尴尬局面：system 可以升级，但内核一动，vendor 驱动就可能崩溃。Treble 为 GKI 提供了方法论——先定义稳定边界，再让两侧独立演进。

三、GKI 的提出动机与版本演进

GKI 的目标是让 Google 能够像维护 AOSP 一样维护一个通用内核镜像：内核核心（core kernel）由 Google 统一构建、统一打安全补丁、统一测试；厂商的差异化驱动以内核模块（KMI）形式加载，并通过稳定的 Kernel Module Interface 与核心内核交互。这样，内核升级不再需要重编整个 BSP，而是替换 GKI 镜像并保持模块 ABI 兼容。

版本演进上，Android 11 首次在部分设备上引入 GKI 1.0，基于 Linux 5.4；Android 12 推进 GKI 2.0，引入 KMI 稳定化与 ABI 监控；Android 13 起要求新设备使用 GKI，并逐步将更多驱动模块化；Android 14/15 继续扩大模块化范围，强化 KMI 稳定性与启动验证。GKI 不是一次性的版本，而是一条持续收紧的工程路线。

四、案例与场景：一次内核安全补丁的升级路径对比

假设某 SoC 平台发现一个内核提权漏洞，需要合入上游补丁。在传统碎片化模式下，流程是：Google 发布补丁 → SoC 厂商回移到 BSP 分支 → ODM 再合入设备树 → 逐设备编译内核 → 逐设备 OTA 验证。周期以月计，且容易漏设备。

在 GKI 模式下，流程变为：Google 在 GKI 核心内核中合入补丁 → 重新构建 GKI 镜像 → 厂商模块无需重编（只要 KMI 未破坏）→ 设备通过 OTA 替换 boot 镜像中的 GKI。周期可压缩到周级，且覆盖所有符合 GKI 要求的设备。

# 传统模式：每个设备独立编译
make ARCH=arm64 vendor_defconfig
make ARCH=arm64 -j$(nproc) Image.gz dtbs

# GKI 模式：核心镜像统一，模块按 KMI 编译
# 厂商侧只需编译模块
make ARCH=arm64 M=drivers/vendor modules
# 加载时校验 KMI 符号版本
modprobe vendor_driver.ko

五、常见误区与复盘

• 误区一：GKI 等于所有驱动都进主线。GKI 并不要求厂商驱动全部上游化，而是要求它们以模块形式存在，并遵守 KMI 稳定约束。
• 误区二：Treble 已经解决了内核升级。Treble 解决的是用户空间接口，内核接口的稳定化是 GKI 才真正推进的。
• 误区三：KMI 稳定意味着内核不能改。KMI 稳定的是模块可见的符号与 ABI 子集，核心内核内部仍可演进，只是不能随意破坏模块依赖。
• 误区四：GKI 只影响新设备。老设备可通过升级到 GKI 内核获得更长安全维护周期，但需要厂商配合模块化改造。