30 秒选对路线KernelSU GKI 与 LKM 的 Android Root 安装与自救指南【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU打开 KernelSU 的发布页一排 boot.img 和 AnyKernel3 压缩包让人发懵真机手机上要刷的文件和模拟器、Waydroid 上要刷的完全不是同一批。作为 Android 内核层的 root 方案KernelSU 从 0.9.0 起提供 GKI 与 LKM 两条路线动手之前先选对路线后面才不会白忙。 30 秒定路线KernelSU GKI 与 LKM 怎么选三个问题问完基本就定了手上是主流真机手机选 LKM。跑的是模拟器、WSA 还是 Waydroid选 GKI。设备被 KNOX 之类机制锁住LKM 加载不进去只能走 GKI。这正是官方的选型口径手机优先 LKM模拟器 / WSA / Waydroid 优先 GKI。两条路线的本质差别在于 KernelSU 以什么身份进入内核LKM原内核不动KernelSU 的可加载内核模块被注入现有内核。落点不是 boot 分区而是 ramdisk——Android 13 及以上的设备对应的是 init_boot 分区。好处是升级省事管理器里点直接安装即可完成A/B 分区设备 OTA 之后直接装到非活跃槽再重启。它还支持临时 root以及免重启的临时卸载——不碰 boot 分区也就不会触发 AVB 校验。GKI用 KernelSU 提供的通用内核镜像Generic Kernel Image整个替换 boot 分区里的原内核。镜像通用、不依赖官方固件KMI 对得上就能用代价是常驻式运行升级时要重新刷镜像。 KernelSU 安装前准备刷之前先问内核三个问题我的 KMI 和目标镜像对得上吗GKI 设备的内核版本格式是Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-后缀即w.x.y-zzz-k-xxx。其中w.x-zzz-k三段才是 KMI例如5.10.101-android12-9-g30979850fc20的 KMI 是5.10-android12-9。两个推论值得记住中间的 SubLevel101、137 这类数字不属于 KMI5.10.101-android12-9与5.10.137-android12-9的 KMI 完全相同只差 SubLevel 的镜像之间可以安全过渡KMI 不同的内核互不兼容刷错往往直接 bootloop。安全补丁级别会不会倒退新机型普遍带防回滚机制。你的系统补丁级别是2023-11却刷入2023-06级别的镜像——哪怕 KMI 分毫不差——也可能开不了机。结论同 KMI 的候选镜像里挑安全补丁级别最新的那个。为什么系统是 Android 13内核却写着 android12正常现象。内核版本号跟的是设备出厂时的 Android 版本后续系统升级一般不改它。选镜像永远以设备上实际显示的内核版本为准别盯着设置页里的 Android 版本号。再补一个容易漏掉的细节同一 KMI、同一补丁级别通常提供lz4、gz、未压缩三种压缩格式的 boot 镜像格式必须和你原来的 boot.img 一致。小米机型常见gz或未压缩Pixel 则常用lz4_legacy这种机型要走手动修补路线见下一节。 照着四步走就装好KernelSU 安装步骤第一步备份原厂镜像先把原厂 bootAndroid 13 走 LKM 路线的话还有 init_boot完整备份下来这是回滚的唯一依据。另外管理器执行直接安装时会自动备份当前原厂镜像后续可用卸载 → 恢复原厂镜像一键还原。第二步拿到正确的目标镜像LKM 路线修补对象是官方固件里的 boot或 init_boot。设备支持fastboot boot时最省事的走法是先用 KernelSU 的 GKI 内核临时启动一次装好管理器后直接在应用里操作全程不用手动下载固件不支持的机型就从官方固件包里解出 boot 镜像。GKI 路线按上面核对出的 KMI 与安全补丁级别从发布页挑对应的通用镜像并确认压缩格式与原 boot 一致。第三步刷入LKM打开管理器点安装图标三选一——选择文件未 root 时把官方 boot 交给管理器自动修补产出文件再自行刷入、直接安装已 root 时最快修补与刷入全自动也是日常升级的主路径、安装到非活跃槽A/B 设备 OTA 之后直接装到另一个槽。不想用图形界面KernelSU 发布包里的ksud工具macOS / Linux / Windows 均支持一条命令完成修补ksud boot-patch -b boot.img --kmi 你的KMI修补完成后用 fastboot 刷入即可。GKI进 fastboot 模式执行fastboot flash boot刷入后重启支持fastboot boot的设备可以先试启动确认没问题再正式刷。Pixel 这类lz4_legacy机型直接刷官方镜像可能起不来需要用 magiskboot 解开原厂 boot、把 AnyKernel3 包里的Image换掉原内核、重新打包再刷完整命令序列见官方安装文档。已经刷了 TWRP 的机型可以直接走 AnyKernel3 ZIP下载与设备 KMI 匹配的包在 Recovery 界面选择安装或用 adb sideload 推送初装和后续升级都适用。第四步重启验证重启后打开管理器确认 root 状态已生效。LKM 用户可以顺手试一下临时 root 与免重启卸载确认行为符合预期整条链路就算走通了。 装好了模块为什么还不动直接说结论刚装好的 KernelSU 不会自动挂载普通模块。这是架构设计不是故障。KernelSU 把模块如何挂载这类基础设施从核心剥离出来交给可插拔的 metamodule元模块实现——好比先有物业入驻住户的门才能被打开。所以只跑脚本、sepolicy、system.prop 的模块不需要元模块装完即可用要修改/system等分区的模块必须先装一个元模块。官方参考实现是meta-overlayfs基于 overlayfs 做无感挂载安装流程与普通模块完全相同下载 zip → 管理器安装 → 重启。两条硬约束同一时间只能装一个元模块装第二个会被拒绝卸载当前元模块后所有模块的挂载会整体停摆直到装入新的。机制细节见元模块文档。顺带划清与 Magisk 的边界两边的模块目录同为/data/adb/modules脚本与 sepolicy 的执行语义完全一致存量模块大多可以无缝迁移。但 KernelSU 不支持.replace文件改用REMOVE/REPLACE变量或用 mknod 创建同名占位文件来删除目标而且两套模块系统不能同时启用——KernelSU 下启用任意一个模块Magisk 的 magic mount 就会整体失效。逐条对照见与 Magisk 的差异说明。 开不了机先从这里查起KernelSU 卡砖救援先分层卡在 boot 分区还是卡在模块回忆出问题前最后一步操作只刷过 boot 分区 → boot 层问题装了某个模块之后开不了机 → 模块层问题。两层的原因与救法完全不同先判断归属再动手。boot 分区层按顺序排除四个点压缩格式是否与原 boot 一致gz机型刷进lz4镜像是最高频的原因KMI 是否匹配安全补丁级别是否倒退该机型是否需要关闭 AVB 验证通常需要清除数据。对号后用 fastboot 把第一步备份的原厂 boot 刷回去就能恢复没备份就从官方固件包或同机型用户处获取。模块层两级内建救援安全模式开机动画出现后、结束前快速连按音量下键 3 次按下松开、按下松开、按下松开不是长按。进入后所有模块被禁用打开管理器卸载问题模块即可。注意操作要快监听窗口在启动动画前就已关闭开机很快的机型可能来不及触发部分系统MIUI/HyperOS 等长按音量下进入系统自带安全模式时KernelSU 也会同步进入安全模式。手动清理安全模式不顶用时能拿到 root shell 就执行ksud module disable id禁用问题模块彻底进不去系统时进 TWRP 挂载 data 分区并删除/data/adb/ksud重启后 KernelSU 不再加载任何模块等系统起来再进管理器处理。分场景的完整排查路径见卡砖救援文档。最后一条提醒别装来路不明的模块——它们手握 root 权限能造成不可逆的破坏。上面所有救援都建立在模块只是写坏了启动逻辑的前提上真被恶意模块动了系统只剩清数据、刷官方系统一条路。装好之后的日常维护日常升级的节奏很简单LKM 用户在管理器里点一下直接安装就算完成GKI 用户在每次内核版本变动时重新核对 KMI 与安全补丁级别再刷入对应的镜像。另外模块来源永远是第一位的风险点——安装前确认作者与渠道可靠远比事后救援划算。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
30 秒选对路线KernelSU GKI 与 LKM 的 Android Root 安装与自救指南【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU打开 KernelSU 的发布页一排 boot.img 和 AnyKernel3 压缩包让人发懵真机手机上要刷的文件和模拟器、Waydroid 上要刷的完全不是同一批。作为 Android 内核层的 root 方案KernelSU 从 0.9.0 起提供 GKI 与 LKM 两条路线动手之前先选对路线后面才不会白忙。 30 秒定路线KernelSU GKI 与 LKM 怎么选三个问题问完基本就定了手上是主流真机手机选 LKM。跑的是模拟器、WSA 还是 Waydroid选 GKI。设备被 KNOX 之类机制锁住LKM 加载不进去只能走 GKI。这正是官方的选型口径手机优先 LKM模拟器 / WSA / Waydroid 优先 GKI。两条路线的本质差别在于 KernelSU 以什么身份进入内核LKM原内核不动KernelSU 的可加载内核模块被注入现有内核。落点不是 boot 分区而是 ramdisk——Android 13 及以上的设备对应的是 init_boot 分区。好处是升级省事管理器里点直接安装即可完成A/B 分区设备 OTA 之后直接装到非活跃槽再重启。它还支持临时 root以及免重启的临时卸载——不碰 boot 分区也就不会触发 AVB 校验。GKI用 KernelSU 提供的通用内核镜像Generic Kernel Image整个替换 boot 分区里的原内核。镜像通用、不依赖官方固件KMI 对得上就能用代价是常驻式运行升级时要重新刷镜像。 KernelSU 安装前准备刷之前先问内核三个问题我的 KMI 和目标镜像对得上吗GKI 设备的内核版本格式是Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-后缀即w.x.y-zzz-k-xxx。其中w.x-zzz-k三段才是 KMI例如5.10.101-android12-9-g30979850fc20的 KMI 是5.10-android12-9。两个推论值得记住中间的 SubLevel101、137 这类数字不属于 KMI5.10.101-android12-9与5.10.137-android12-9的 KMI 完全相同只差 SubLevel 的镜像之间可以安全过渡KMI 不同的内核互不兼容刷错往往直接 bootloop。安全补丁级别会不会倒退新机型普遍带防回滚机制。你的系统补丁级别是2023-11却刷入2023-06级别的镜像——哪怕 KMI 分毫不差——也可能开不了机。结论同 KMI 的候选镜像里挑安全补丁级别最新的那个。为什么系统是 Android 13内核却写着 android12正常现象。内核版本号跟的是设备出厂时的 Android 版本后续系统升级一般不改它。选镜像永远以设备上实际显示的内核版本为准别盯着设置页里的 Android 版本号。再补一个容易漏掉的细节同一 KMI、同一补丁级别通常提供lz4、gz、未压缩三种压缩格式的 boot 镜像格式必须和你原来的 boot.img 一致。小米机型常见gz或未压缩Pixel 则常用lz4_legacy这种机型要走手动修补路线见下一节。 照着四步走就装好KernelSU 安装步骤第一步备份原厂镜像先把原厂 bootAndroid 13 走 LKM 路线的话还有 init_boot完整备份下来这是回滚的唯一依据。另外管理器执行直接安装时会自动备份当前原厂镜像后续可用卸载 → 恢复原厂镜像一键还原。第二步拿到正确的目标镜像LKM 路线修补对象是官方固件里的 boot或 init_boot。设备支持fastboot boot时最省事的走法是先用 KernelSU 的 GKI 内核临时启动一次装好管理器后直接在应用里操作全程不用手动下载固件不支持的机型就从官方固件包里解出 boot 镜像。GKI 路线按上面核对出的 KMI 与安全补丁级别从发布页挑对应的通用镜像并确认压缩格式与原 boot 一致。第三步刷入LKM打开管理器点安装图标三选一——选择文件未 root 时把官方 boot 交给管理器自动修补产出文件再自行刷入、直接安装已 root 时最快修补与刷入全自动也是日常升级的主路径、安装到非活跃槽A/B 设备 OTA 之后直接装到另一个槽。不想用图形界面KernelSU 发布包里的ksud工具macOS / Linux / Windows 均支持一条命令完成修补ksud boot-patch -b boot.img --kmi 你的KMI修补完成后用 fastboot 刷入即可。GKI进 fastboot 模式执行fastboot flash boot刷入后重启支持fastboot boot的设备可以先试启动确认没问题再正式刷。Pixel 这类lz4_legacy机型直接刷官方镜像可能起不来需要用 magiskboot 解开原厂 boot、把 AnyKernel3 包里的Image换掉原内核、重新打包再刷完整命令序列见官方安装文档。已经刷了 TWRP 的机型可以直接走 AnyKernel3 ZIP下载与设备 KMI 匹配的包在 Recovery 界面选择安装或用 adb sideload 推送初装和后续升级都适用。第四步重启验证重启后打开管理器确认 root 状态已生效。LKM 用户可以顺手试一下临时 root 与免重启卸载确认行为符合预期整条链路就算走通了。 装好了模块为什么还不动直接说结论刚装好的 KernelSU 不会自动挂载普通模块。这是架构设计不是故障。KernelSU 把模块如何挂载这类基础设施从核心剥离出来交给可插拔的 metamodule元模块实现——好比先有物业入驻住户的门才能被打开。所以只跑脚本、sepolicy、system.prop 的模块不需要元模块装完即可用要修改/system等分区的模块必须先装一个元模块。官方参考实现是meta-overlayfs基于 overlayfs 做无感挂载安装流程与普通模块完全相同下载 zip → 管理器安装 → 重启。两条硬约束同一时间只能装一个元模块装第二个会被拒绝卸载当前元模块后所有模块的挂载会整体停摆直到装入新的。机制细节见元模块文档。顺带划清与 Magisk 的边界两边的模块目录同为/data/adb/modules脚本与 sepolicy 的执行语义完全一致存量模块大多可以无缝迁移。但 KernelSU 不支持.replace文件改用REMOVE/REPLACE变量或用 mknod 创建同名占位文件来删除目标而且两套模块系统不能同时启用——KernelSU 下启用任意一个模块Magisk 的 magic mount 就会整体失效。逐条对照见与 Magisk 的差异说明。 开不了机先从这里查起KernelSU 卡砖救援先分层卡在 boot 分区还是卡在模块回忆出问题前最后一步操作只刷过 boot 分区 → boot 层问题装了某个模块之后开不了机 → 模块层问题。两层的原因与救法完全不同先判断归属再动手。boot 分区层按顺序排除四个点压缩格式是否与原 boot 一致gz机型刷进lz4镜像是最高频的原因KMI 是否匹配安全补丁级别是否倒退该机型是否需要关闭 AVB 验证通常需要清除数据。对号后用 fastboot 把第一步备份的原厂 boot 刷回去就能恢复没备份就从官方固件包或同机型用户处获取。模块层两级内建救援安全模式开机动画出现后、结束前快速连按音量下键 3 次按下松开、按下松开、按下松开不是长按。进入后所有模块被禁用打开管理器卸载问题模块即可。注意操作要快监听窗口在启动动画前就已关闭开机很快的机型可能来不及触发部分系统MIUI/HyperOS 等长按音量下进入系统自带安全模式时KernelSU 也会同步进入安全模式。手动清理安全模式不顶用时能拿到 root shell 就执行ksud module disable id禁用问题模块彻底进不去系统时进 TWRP 挂载 data 分区并删除/data/adb/ksud重启后 KernelSU 不再加载任何模块等系统起来再进管理器处理。分场景的完整排查路径见卡砖救援文档。最后一条提醒别装来路不明的模块——它们手握 root 权限能造成不可逆的破坏。上面所有救援都建立在模块只是写坏了启动逻辑的前提上真被恶意模块动了系统只剩清数据、刷官方系统一条路。装好之后的日常维护日常升级的节奏很简单LKM 用户在管理器里点一下直接安装就算完成GKI 用户在每次内核版本变动时重新核对 KMI 与安全补丁级别再刷入对应的镜像。另外模块来源永远是第一位的风险点——安装前确认作者与渠道可靠远比事后救援划算。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
