你的内核真的支持 KernelSU 吗？GKI、KMI 与 LKM 兼容性体检

本教程的任务不是下载一个“5.10 通用 boot”，而是判断你的自有备用机能否安全进入 KernelSU 安装流程。你会先完成只读证据表；只有版本、KMI、压缩格式、分区与回滚通道全部匹配，才考虑设备明确支持的临时启动。

你会完成什么#

• 区分 KernelSU Manager、内核实现、LKM、GKI 和模块生态。
• 记录内核版本、KMI、架构、补丁级别、槽位与原厂镜像，逐项核对发布资产。
• 把 Manager 的结果归类为“可评估安装”“需要自行编译”或“停止”。
• 在支持 fastboot boot 的设备上做一次可撤销验证，不同时叠加模块或 fork。

先看结论#

心智模型#

Android App → KernelSU Manager → 内核授权钩子 → UID 0
                         ├─ LKM：保留内核，加载匹配模块
                         └─ GKI：替换/使用匹配的 GKI 内核
设备 KMI + ABI + SPL + compression + boot layout → 必须逐项匹配

GKI 是 Android 内核架构和兼容接口，不是“所有 GKI 手机共享同一个镜像”。KMI（Kernel Module Interface）决定模块与内核能否合作；相同的大版本号也可能有不同 KMI、厂商改动和压缩格式。

工具清单#

项目全景：KernelSU 生态的 46 个项目，一个不漏#

以 KernelSU 的内核授权链为主线，把上游/分支、GKI 与设备内核、SUSFS 隐藏、模块用途和生态索引分开讲。大量同名 fork 必须逐项出现，但不能被写成 46 种独立 Root 原理。

1. SUSFS、挂载隐藏与隐蔽层 · 8#

放在基础 KernelSU 成功后的可选层，比较 SUSFS、mountless 重定向和隐藏服务。先建立无隐藏基线，再一次只加入一个组件；内核漏洞项目只作风险说明。

本组共 8 项：7 个源项目、1 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

2. GKI/LKM、设备内核与构建路线 · 7#

用于兼容性体检：把 KMI、GKI、LKM、内核源码、设备专用构建和在线构建器放在一起核对。营销机型相同不等于 KMI 匹配，不能下载相似版本的 boot 试刷。

本组共 7 项：3 个源项目、4 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

3. 模块、代理与授权体验扩展 · 3#

覆盖 KernelSU 模块、透明代理、配置和授权提示等用户态扩展。它们不改变内核是否支持 KernelSU 的结论，安装前先核对模块格式和版本。

本组共 3 项：1 个源项目、2 个 Fork，其中 1 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

4. 生态索引、桌面套件与诊断工具 · 2#

把 awesome 清单、桌面套件与诊断入口作为发现资源，而不是安装权威。文章应教新手回到上游 release、提交记录和设备维护者页面二次核验。

本组共 2 项：2 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

5. 主线实现、分支与管理器 · 25#

集中介绍 tiann/KernelSU、KernelSU-Next、ReSukiSU、SukiSU/KittiSU/ApexSU 等血缘。逐项列出 fork，但要求 Manager、内核补丁和文档来自同一项目链，禁止交叉混用。

本组共 25 项：6 个源项目、19 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

6. 跨界、信息不足与低置信项目 · 1#

收纳只在 topics 提到 KernelSU、通用 AOSP 构建仓库或信息不足的项目。完整展示但不当作上游兼容资产，说明其真正用途和核验缺口。

本组共 1 项：1 个源项目、0 个 Fork，其中 0 项已归档。它们的平台、用途或分类存在边界，只作逐项核验，不当作默认安装候选。

开始前#

在 Android 中保存 adb shell uname -a、adb shell uname -r、adb shell getprop ro.product.device、完整构建指纹和安全补丁日期；在 bootloader 保存 product 与 current-slot。安装 Manager 只用于读状态，不授予任何 App root。下载当前构建原厂包，保留 stock boot 与设备布局要求时的 init_boot，记录哈希。

截至 2026-08-09，KernelSU 官方文档仍区分 LKM 与 GKI 路线；新 Android 设备的 LKM patch 可能涉及 init_boot，而 GKI 路线仍关系 boot。分区选择必须以当时的 KernelSU 文档和具体设备资料共同确认。

操作步骤#

1. 建立设备与内核证据卡#

把内核 release 完整字符串拆成主版本、Android common kernel 代际与厂商后缀，不删除任何字符。记录 CPU ABI、系统 SPL、启动镜像 header/压缩格式和 bootloader 状态。若 Manager 只给一个概括标签，仍需用官方安装说明核对其含义；截图同时抄成文本，方便和发布资产逐字段比较。

2. 选择 LKM、GKI 或停止#

LKM 旨在保留原内核并加载模块，通常减少替换整个内核的变量；GKI mode 涉及匹配的内核镜像。建立一行对一行匹配表，只有 KMI、架构、Android/kernel 代际、压缩格式、SPL/发布说明和目标分区都明确通过才进入下一步。若需要自行编译，这已经是内核构建任务，应停在结论并另行准备源码、toolchain 和可复现构建。

3. 在设备支持时做临时启动#

先再次运行 fastboot devices、fastboot getvar product 与 current-slot 检查。只有官方设备资料确认允许临时 boot，才用已核验资产执行 fastboot boot <verified-image>；这个动作把镜像放入内存试启动，不应写分区，但错误内核仍可能卡住，需要强制重启。启动后先看 Manager 状态、触控/无线和 adb，不装模块。

4. 做决定并保留回退#

临时启动稳定才评估官方 LKM patch 或永久写入步骤；命令必须来自当前 KernelSU 文档与设备页。永久安装后只让一个终端运行 su -c id，保存授权日志。若临时启动失败、硬件异常或 Manager 状态不一致，正常重启回 stock，记录“不兼容”而不是改用另一个 fork 继续试。

验证#

成功标准是证据链完整，不是“别人同 SoC 刷成了”。如果设备不能临时启动，验证门槛应更高：必须有精确设备维护者说明、可工作的 recovery 与完整回刷材料。

排错#

完成清单#

• □已保存完整内核 release、KMI、ABI、SPL、build、product 和槽位。
• □已把每项设备值与同一上游资产逐项匹配。
• □已明确选择主线或一个 fork，没有交叉混用组件。
• □只有设备明确支持时才做临时启动，并验证基础硬件。
• □首次实验没有加入 SUSFS、Zygisk、metamodule 或隐藏组件。
• □已得出“可继续 / 需自行编译 / 停止”之一并保存 stock 回滚材料。

一手资料#

• KernelSU 是什么
• KernelSU 官方安装说明
• KernelSU 模块说明
• AOSP Generic Kernel Image
• Android SDK Platform-Tools
• KernelSU 官方仓库
• KernelSU-Next 仓库