3. GKI版本与分支体系
在GKI量产交付中，最容易引发争议的问题往往不是“怎么编译”，而是“到底该选哪个内核版本”。Android生态里同时存在ACK、AOSP内核、GKI版本号、LTS、EOL以及Android平台版本等多套命名体系，它们彼此关联但语义不同。如果团队把“Android 14”直接等同于“kernel 6.1”，或者把“GKI 2.0”误认为某个具体内核版本，后续的驱动适配、安全补丁合并和OTA升级都会出现系统性偏差。本节把这几套体系拆开，并给出可落地的对应关系与选型方法。
一、四套命名体系的核心语义
ACK（Android Common Kernel）是Google维护的Android通用内核分支，位于AOSP内核仓库中，按“android<平台版本>-<内核版本>”命名，例如android14-6.1、android13-5.15。ACK在对应LTS基础上叠加Android特有补丁（如binder、ashmem、lowmemorykiller、vendor hook、KABI相关改动），是GKI设备实际使用的内核源码基线。
AOSP内核是更宽泛的概念，指AOSP中发布的内核源码，包含ACK分支以及部分非GKI的legacy分支。量产中真正需要锁定的是ACK分支，而不是笼统的“AOSP内核”。
GKI版本号指GKI发布物自身的版本标识，例如android14-6.1-2024-06，它由“ACK分支 + 发布年月”构成，代表一次具体的GKI二进制发布。GKI 1.0/2.0则是GKI架构的代际：GKI 1.0对应Android 11–12的初步解耦，GKI 2.0从Android 13起要求vendor模块通过KMI稳定接口与内核交互，并强制使用ABL与boot签名校验。
LTS与EOL来自上游Linux社区。LTS（Long Term Support）内核如5.10、5.15、6.1、6.6会获得长期稳定补丁；EOL（End of Life）表示该LTS分支停止维护。ACK的维护周期受上游LTS约束，一旦上游EOL，ACK通常只再维持一段过渡期，之后不再接收安全补丁。
二、Android平台版本与内核版本的对应关系
Android平台版本与内核版本不是一一对应，而是“一个平台版本可对应多个内核版本”。Google通过android<平台>-<内核>分支把两者绑定，但同一平台版本在不同设备上可能使用不同内核。下表给出量产中常见的对应关系（以GKI 2.0为主）：
| Android平台版本 | 推荐ACK分支 | 内核版本 | GKI代际 | 上游LTS状态 |
|---|---|---|---|---|
| Android 12 | android12-5.10 | 5.10 | GKI 1.0 | LTS维护中 |
| Android 13 | android13-5.15 | 5.15 | GKI 2.0 | LTS维护中 |
| Android 14 | android14-6.1 | 6.1 | GKI 2.0 | LTS维护中 |
| Android 15 | android15-6.6 | 6.6 | GKI 2.0 | LTS维护中 |
| Android 11 | android11-5.4 | 5.4 | GKI 1.0 | 已EOL |
需要强调：Android 14设备并非只能跑6.1，部分设备仍可沿用5.15的ACK分支，但必须满足该平台对KMI、vendor hook和GKI发布物的要求。选型时应以“平台版本 + ACK分支 + GKI发布物”三元组锁定，而不是只看内核主版本号。
三、版本选型与升级流程
量产项目确定内核基线的标准流程如下：
- 确认目标Android平台版本与GKI代际（1.0或2.0）。
- 在AOSP内核仓库中筛选该平台支持的ACK分支，优先选择仍处于LTS维护期的分支。
- 核对上游LTS的EOL时间，确保量产周期内不会因EOL导致安全补丁断供。
- 锁定具体GKI发布物版本号，例如
android14-6.1-2024-06，并记录其对应的KMI版本。 - 验证vendor模块与KMI的兼容性，确认ABL、boot签名和vendor boot配置。
- 建立补丁合并通道，定期从ACK分支同步安全补丁并重新发布GKI。
在代码层面，可通过以下命令查看当前内核基线与ACK分支：
# 查看内核版本与ACK分支标识
cat /proc/version
# 输出示例：Linux version 6.1.75-android14-6.1-2024-06 ...
# 在AOSP内核仓库中查看可用分支
git ls-remote --heads https://android.googlesource.com/kernel/common \
| grep -E "android14-6.1|android15-6.6"
# 查看GKI发布物版本
adb shell getprop ro.boot.gki.version
# 输出示例：android14-6.1-2024-06四、典型场景与误区复盘
场景：某项目基于Android 14，最初选用android14-6.1，但因供应商驱动仅支持5.15，团队试图直接回退到android13-5.15。结果GKI 2.0的KMI校验失败，boot签名不匹配，设备无法启动。正确做法是：要么推动供应商适配6.1的KMI，要么在Android 14上使用官方支持的5.15 ACK分支（若存在），而不是跨平台版本混用分支。
误区一：把“Android 14”等同于“kernel 6.1”。实际上Android 14可支持6.1和5.15两个ACK分支，具体取决于设备与GKI发布物。
误区二：认为LTS EOL后ACK立即停止维护。ACK通常会在上游EOL后继续维护一段时间，但不再接收上游稳定补丁，安全风险显著上升。
误区三：只看内核主版本号，忽略GKI发布物版本。同一6.1分支下不同发布物可能包含不同的KMI和vendor hook，混用会导致兼容性问题。
为便于理解各体系之间的层级与依赖关系，下图给出从上游LTS到Android平台版本的完整映射结构：
掌握这套体系后，团队在量产交付中就能把“内核版本”从模糊的平台代称，转化为可审计、可追溯、可升级的工程基线。无论是安全补丁合并、KMI兼容性验证，还是跨平台升级，都能基于ACK分支与GKI发布物做出明确判断，避免因命名混淆导致的返工与延期。