企业官网建设流程全解析

KernelSU Root 安装完整指南：GKI 与 LKM 模式选择、KMI 核对到卡砖自救

【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU

刷内核最贵的代价从来不是时间，而是刷错镜像之后被迫清掉的数据。KernelSU 是一款运行在内核层的 Android root 方案，它在系统最底层接管权限判断。这篇文章按"新机首次 root、OTA 升级之后、要装改分区的模块、出事怎么救"四个真实场景展开，把 LKM 与 GKI 两种运行模式的区别、刷入前必须核对的 KMI 与安全补丁级别、装完容易被忽略的元模块底座，以及两类卡砖症状的排查与恢复路径一次讲完。

新机首次 root：按设备类型确定 LKM 或 GKI 模式

在纠结"刷哪个文件"之前，有个更底层的问题要先回答：KernelSU 以什么方式进内核？自 0.9.0 起它提供了两条路线，好比处理一把"门锁"的两种做法：

• LKM 模式相当于找配锁师傅加了一把新钥匙——锁体（原内核）一点没动，只是往里加载了一个可加载内核模块；修改对象是 ramdisk，Android 13 及以上的设备则是init_boot分区；
• GKI 模式相当于把整个锁体换掉——用 KernelSU 提供的通用内核镜像整体替换原内核；修改对象是boot分区。

两条路线最影响日常体验的两个差异：

• 升级与卸载：如果你的使用习惯是频繁更新，LKM 支持免重启卸载、临时 root，且不触发 AVB 校验；GKI 则常驻内核，卸载必须重新刷镜像回去；
• 适配设备：如果是一台真机手机，优先选 LKM；如果是模拟器、WSA、Waydroid 这类环境，优先选 GKI；如果设备存在 KNOX 之类的锁机制导致模块加载不进去，那就只能走 GKI。

刷入前做完三项版本核对（含 KMI 判定）

配钥匙之前要先报锁具型号，刷内核同理。以下三项是 官方安装文档 里列明的必做动作，缺一项都可能把机器留在启动界面之外。

KMI 构成：只有 w.x-zzz-k 三段才算数

GKI 设备的内核版本号遵循固定格式：Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration，其中真正构成 KMI 的只有w.x-zzz-k三段。以5.10.101-android12-9-g30979850fc20为例，它的 KMI 是5.10-android12-9。

由此可以推出两个判断：

• SubLevel（101、137、168 这类数字）不计入 KMI，所以从5.10.168-android13-12换到5.10.198-android13-12是一次完全安全的无缝切换；
• 跨 KMI 刷入基本不可行：轻则无法开机，重则卡在启动动画出不来。

安全补丁级别：只升不降

新设备普遍带防回滚机制。假设你当前系统的安全补丁级别是2023-11，此时刷入一个2023-06级别的镜像，哪怕 KMI 完全对得上，也可能直接卡砖。所以规则只有一条：同一个 KMI 下，挑安全补丁级别最新的那个镜像。

内核版本 ≠ Android 版本："以内核为准"

"系统明明是 Android 13，内核怎么显示 android12-5.10？"这是正常现象。内核版本号锁定在设备出厂时的 Android 版本上，之后的系统升级通常不会动它。选镜像时永远以内核版本为准，别盯着设置页里的 Android 版本号看。

还有一处细节常被漏掉：同一个 KMI 和补丁级别通常会同时提供lz4、gz、未压缩三种格式的 boot 镜像，格式必须与你手里的原始boot.img完全一致，否则刷完开不了机。小米设备常见gz或未压缩，Pixel 设备常用lz4_legacy（这类机型往往要手动修补，具体见下文 GKI 路线）。

三项核对速查表：

首次安装操作：LKM 与 GKI 分步执行（含 ksud 命令行）

LKM 路线：先备份，再在三种安装方式里选一种

1. 把原厂boot（或init_boot）镜像备份下来——这是后续一切回滚动作的底气，刷之前必须完成。
2. 拿到官方固件包并解出 boot 镜像；如果你的设备支持fastboot boot，更省事的办法是先用 KernelSU 的 GKI 内核临时启动一次，装好管理器后直接在应用里操作，全程不用手动下载固件。
3. 管理器里的安装按钮，对应三种做法：
   • 选择文件：把官方 boot 镜像交给管理器自动修补，产出的文件再自行刷入；
   • 直接安装：已 root 场景下最快捷，管理器自动完成修补与刷入，也是日后升级 KernelSU 的主要入口；
   • 安装到非活跃槽：A/B 分区设备 OTA 之后，直接装进另一个槽，重启即生效。
4. 刷入后重启，root 生效。值得一提的是，执行"直接安装"时管理器会自动存档当前的原厂镜像，之后想用"卸载 → 恢复原厂镜像"回滚即可。

不想碰图形界面就走上命令行：KernelSU 发布包自带的跨平台ksud工具可以完成修补，核心命令是ksud boot-patch -b <boot.img> --kmi <你的KMI>，修补完成后自己用 fastboot 刷入。

GKI 路线：刷 boot 分区，特殊机型需手动修补

1. 按前面核对出的 KMI 和安全补丁级别，下载对应的通用 boot 镜像，并确认压缩格式与原始 boot 一致。
2. 进入 fastboot 后执行fastboot flash boot boot.img，随后fastboot reboot。
3. 特殊机型（典型代表是 Pixel 的lz4_legacy格式）直接刷官方镜像可能失败，此时需要先用 magiskboot 解开原厂 boot，用 KernelSU 的Image文件替换其中的内核，重新打包后再刷入；安装文档 里给出了完整的命令序列，照抄即可。
4. 有 TWRP 的话还有一条 AnyKernel3 包路线：下载与设备 KMI 匹配的 ZIP，进 Recovery 安装，之后的升级同样适用这条路线。

OTA 升级之后：快速保住 root 状态

日常升级的节奏很简单，两种模式各有一套固定动作：

• 如果你是 LKM 用户：在管理器里点一下"直接安装"就完成升级；A/B 设备 OTA 之后走"安装到非活跃槽"更顺，装到另一个槽重启即好；
• 如果你是 GKI 用户：每次内核版本变动时，重新核对一遍 KMI 与安全补丁级别，再刷入对应镜像；有 TWRP 的话直接用 AnyKernel3 包更新。

换句话说，LKM 用户的升级节奏跟着管理器提示走，GKI 用户的升级节奏跟着内核版本号走。

要装改分区的模块：先铺好 meta-overlayfs 元模块底座

装完 KernelSU 之后有一个容易被忽略的坑：此时普通模块的挂载功能其实是不工作的。

KernelSU 采用 metamodule（元模块）架构，把"如何挂载模块"这类基础设施从核心里剥离出来，交给可插拔的元模块实现。用装修来打比方：root 相当于完成了水电交底，模块是定制的柜子——交底没做完就进场装柜子，柜子是立不住的。具体规则是：

• 只跑脚本、sepolicy、system.prop 的模块：不需要元模块，开箱即用；
• 需要修改/system等分区的模块：必须先安装一个元模块，官方参考实现是meta-overlayfs（基于 overlayfs 实现无感挂载），安装方式和普通模块完全相同。

两条硬性约束要记住：元模块同一时间只能装一个；卸载它会导致所有模块停止挂载。想深入看架构细节，可以读 元模块文档，内核侧的实现代码在 kernel/ 目录里。

顺带把与 Magisk 的关系说清楚：两者的模块目录都在/data/adb/modules，脚本和 sepolicy 的语义完全一致；但 KernelSU 不支持.replace文件（替代做法是用REMOVE/REPLACE变量或mknod占位），而且两者的模块系统不能同时启用——更多对照细节见 与 Magisk 的差异说明。

出事了：按卡砖症状分流做救援

救援方法能成立，前提是"只动过 boot 分区，且模块只是写坏了启动逻辑"。下面按症状分两条路径，完整的分场景排查在 卡砖救援文档 里。

症状一：刷入之后完全开不了机

把前面的核对项反过来逐项查一遍：

1. 镜像压缩格式与原始 boot 是否一致——gz设备刷了lz4是最常见的原因；
2. KMI 是否匹配、安全补丁级别是否发生了倒退；
3. 设备是否要求关闭 AVB 验证（这一步通常需要清除数据）。

定位到原因后，用 fastboot 把备份的原厂 boot 刷回去即可恢复。手边没有备份的话，从官方固件包或同机型用户处获取原始镜像。

症状二：装了某个模块之后开不了机

模块是卡砖的重灾区，KernelSU 内建了两级救援手段：

• 安全模式（急刹车）：在启动动画出现后、结束前这个窗口内，快速连按音量下键 3 次（是连按三次，不是长按），进入安全模式后所有模块被禁用，再进管理器把问题模块卸载掉。部分系统（如 MIUI/HyperOS）长按音量下进入系统自带安全模式时，KernelSU 也会同步进入安全模式。
• 手动清理：安全模式无效时，可以通过 ADB 执行ksud module disable <id>禁用问题模块；如果系统彻底进不去，进 TWRP 挂载 data 分区，删除/data/adb/ksud，模块将不再被加载，重启回系统内再做处理。

一条铁律：别装来路不明的模块

模块是以 root 权限运行的，一个来路不明的模块足以造成不可逆的破坏。前面所有救援手段都建立在"模块只是写坏了启动逻辑"这个前提上——恶意模块把系统本身损坏之后，剩下的路只有清数据、重装官方系统。

动手之前把这份安装核对清单过一遍

清单收藏起来，每次刷入前逐条勾选：

• 原厂boot（或init_boot）备份文件已保存且可读取
• 目标镜像 KMI（w.x-zzz-k三段）与设备内核版本完全一致
• 目标镜像安全补丁级别不低于当前系统
• 目标镜像压缩格式与原始boot.img相同
• 需要修改/system的模块，已装好meta-overlayfs（或等价元模块）

五条全部打勾之后，从模式选择、版本匹配到装完的模块挂载，这一路上基本没有悬念。

【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU