企业官网建设流程全解析

KernelSU 实战指南：从确认设备支持到刷入翻车自救的完整流程

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

KernelSU 是一套运行在 Android 内核空间的 root 方案：它直接在内核中拦截系统调用并为用户态应用授予 root 权限，不依赖传统用户态框架。这篇文章按"自检设备 → 选择安装方式 → 启用模块 → 出事恢复"的顺序，把每个节点上你会看到的现象、该做的决定和具体操作串起来，所有路径与命令均来自项目文档。

动手前先确认：你的设备能不能装

刷机前有两个硬性前置条件，缺一个后面的路都不通：

• 能解锁 Bootloader：无法解锁的设备直接放弃，这是 FAQ 中明确的前提。
• 内核版本达标：连接电脑后执行下面命令查看：

adb shell cat /proc/version

KernelSU 目前最低支持 4.14 内核；出厂 Android 12 及以后的设备基本是 GKI 设备，开箱即支持。

然后安装 KernelSU 管理器并打开，界面状态直接告诉你结论：

注意：选"不支持"路线时，非官方支持设备列表和非 GKI 设备集成教程可以作为参考，但官方明确不会为你编译内核。

刷之前必须弄懂的三个概念

这三个概念决定了你下载/修补哪个镜像，选错就直接变砖，官方安装文档对此反复强调：

1. KMI（Kernel Module Interface）：相同 KMI 的内核互相兼容。GKI 设备内核版本形如5.10.101-android12-9-g30979850fc20，其中5.10-android12-9就是 KMI。注意 SubLevel（101）不算在 KMI 内，5.10.101和5.10.137的 KMI 相同。
2. 安全补丁级别：新设备有防回滚机制，刷入安全补丁比现有内核更旧的镜像可能无法开机。KMI 一致的前提下，优先选安全补丁更新的内核。
3. 内核版本 ≠ Android 版本：系统升到 Android 13 后内核版本号通常不变。刷机永远以内核版本为准，而不是系统版本。

选择安装方式：GKI 模式还是 LKM 模式

自 0.9.0 起，GKI 设备上有两种安装模式，二者的差别在于动不动原厂内核：

怎么选：官方建议是——真机手机优先考虑 LKM，模拟器 / WSA / Waydroid 优先考虑 GKI。如果你只是想要 root、又在意后续 OTA 省事，LKM 是更稳的路；如果你在用第三方内核或 KNOX 设备，再走 GKI。

第一步永远是备份原厂 boot

无论选哪种模式，动手前先备份：

dd if=/dev/block/by-name/boot of=/sdcard/boot_backup.img

这是全文最重要的一条。后续所有"刷坏了怎么办"的方案，本质都是把原厂 boot 刷回去。没有备份，你就只能去翻官方固件包或找同机型用户提取，成本和风险都高得多。

LKM 模式的最小步骤

最省事的路径是借助fastboot boot临时启动 KernelSU 的 GKI 内核获得临时 root，再在管理器中"直接安装"——全程不需要手动下载固件、提取 boot：

1. 用fastboot boot boot.img临时启动 KernelSU 内核，安装管理器；
2. 打开管理器 → 右上角安装图标 → 选择"直接安装"；
3. 管理器自动识别设备信息、修补并刷入，重启完成。

如果设备不支持fastboot boot，就需要手动下载官方固件提取 boot，然后在管理器里选"选择并修补一个文件"。也可以用命令行工具ksud（源码见 userspace/ksud/src/，支持 macOS/Linux/Windows）：

ksud boot-patch -b boot.img --kmi android13-5.10

修补完成后，把生成的镜像fastboot flash进对应分区即可。设备已 root 时，管理器的"直接安装"还会自动备份原厂 boot（或 init_boot）到/data/adb/ksu/下，卸载时的"还原原厂镜像"功能会直接调用它。

GKI 模式的最小步骤

核心思路只有一个：把原厂内核换成 KernelSU 提供的内核。最直接的刷法：

fastboot flash boot boot.img fastboot reboot

这里最容易翻车的点是内核压缩格式：同一 KMI、同一安全补丁下通常有 lz4、gz 等不同压缩格式的镜像，刷错格式会直接无法开机。用 magiskboot 解包原厂 boot 可查看原格式（小米通常为gz或不压缩）。Pixel 的lz4_legacy格式比较特殊，官方推荐用 magiskboot 手动解包原厂 boot、替换其中kernel文件为 KernelSU 的 Image 再 repack，这一步的详细操作在安装文档中有完整清单。

如果设备有 TWRP 之类的自定义 Recovery，也可以用 AnyKernel3 刷机包走 Recovery 路线，KMI 和安全补丁的选择规则与上面完全一致。

root 之后：让模块真正跑起来

刷好 boot 只是拿到 root，KernelSU 的价值一半在模块系统。这里有一个新手最容易忽略的前置步骤。

重要：如果你的模块需要修改/system文件，必须先安装一个metamodule（如meta-overlayfs）。没有元模块，模块的挂载功能不会生效；而仅靠脚本、sepolicy.rule、system.prop的模块不需要元模块。元模块文档对此有说明。

安装方式与常规模块相同：管理器 → 点 ➕ → 选择元模块 zip → 重启。一次只能运行一个元模块，管理器会拦截第二个的安装。

模块的工作机制一句话版

模块就是/data/adb/modules下的一个文件夹，核心结构是：

• module.prop：模块的身份信息（id、name、version），缺了它就不算模块；
• system/：启动时以 overlayfs 叠加到系统/system上，实现"systemless"修改；
• post-fs-data.sh/service.sh/boot-completed.sh等：在不同启动阶段执行脚本，所有脚本都在 KernelSU 内置的 BusyBox（/data/adb/ksu/bin/busybox）中以独立模式运行。

模块开发文档里有完整的目录结构和启动时序图。对普通用户来说记住两点就够了：KernelSU 模块不支持在 Recovery 中安装（必须在管理器中刷入）；模块与 Magisk 的 magic mount 机制互斥，两边同时启用模块会导致 Magisk 不工作（详见差异说明）。

进阶：用 App Profile 给 root 上"笼子"

授出 root 后如果想收紧权限，可以在管理器的应用配置中为每个应用单独设置 Root Profile：自定义su后的 UID/GID/groups、Capabilities 乃至 SELinux context。比如给防火墙应用去掉inet组，它的su就无法访问网络。这套限制是在内核中强制执行的，不依赖应用自身的自觉，机制细节见App Profile 文档。

出事了：分三级恢复

变砖不可怕，可怕的是不知道从哪一级开始救。按下面的顺序逐级尝试，前面的方法能解决时不要跳级。

第一级：刷回原厂 boot

能进 fastboot 模式（长按电源键+音量减）时，变砖问题基本都有解：

fastboot flash boot stock_boot.img fastboot reboot

这里的stock_boot.img就是你第一步备份的文件。如果没有备份，从官方固件包中提取，或向同机型用户索要。

第二级：音量下键进入安全模式

这是 KernelSU 内置的机制，进入后所有模块全部被禁用。开机第一屏出现后，连续按音量下键超过三次——注意是"按下-松开"重复三次，不是长按。触发成功后，在管理器的模块页面卸载可疑模块即可。

两个容易踩的坑：

• 监听窗口只在启动早期（on_post_fs_data阶段前）有效，设备启动快时要手快；
• 安全模式只会禁用模块，不会跳过模块注入 initrc 的代码。如果模块的.rc文件本身写坏了启动流程，安全模式也救不了，需要走第三级。

另外，如果 ADB 能拿到 root shell，也可以直接用ksud命令行处理，比进安全模式更精确：

ksud module list # 列出所有模块 ksud module disable <id> # 禁用问题模块 ksud module uninstall <id> # 或直接卸载

第三级：Recovery 手动清理

连 ADB 都不通时，需要第三方 Recovery（如 TWRP）。KernelSU 的模块加载依赖内核侧的 init.rc 注入和用户态的 ksud 进程，把这条链打断即可：

mount /data rm -f /data/adb/ksud mount /metadata rm -f /metadata/ksu/modules.rc rm -f /metadata/watchdog/ksu/modules.rc reboot

重启后 KernelSU 会跳过所有模块加载，正常进入系统后再回管理器处理。

底线建议：以上都无效时，大概率是模块有恶意行为，只剩两条路——清除数据刷完整官方系统，或联系售后。所以装模块前务必确认来源，[rescue-from-bootloop 文档](https://link.gitcode.com/i/e83a35b9051d662654a37dd752b71253)中专门警告了"请勿刷入来路不明的模块"。

收尾清单

走完全流程，把这几件事固化成习惯：

1. 刷机前备份原厂 boot，永远放在第一位；
2. 下载镜像时核对 KMI + 安全补丁 + 压缩格式三要素；
3. 依赖挂载的模块先装 metamodule；
4. 每次只加一个模块，重启观察稳定后再加下一个；
5. 记住"音量下 ×3"和ksud module disable这两张底牌。

KernelSU 的恢复机制设计得比多数 root 方案更宽容：只要没动原厂 boot 备份，绝大多数翻车都能收场。剩下的风险只来自两点——选错了镜像，或者装了来路不明的模块。

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