企业官网建设流程全解析

KernelSU 变砖自救指南：Bootloop 救援的完整实操手册

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

刷机与模块玩法总是伴随着风险。无论是刷入 boot 分区时格式不匹配，还是某个模块在开机阶段触发了死循环，设备卡在开机动画、无法进入系统（即俗称的"变砖"），都是 KernelSU 用户最常遇到的故障场景。本文基于仓库官方救援文档（rescue-from-bootloop.md）展开，系统梳理 boot 分区刷砖、模块导致的 bootloop 两类问题的成因，并给出内核内置安全模式、ksud命令行、Recovery 手动清理三套由易到难的完整救援方案。读完本文，你将能够根据设备状态判断故障类型，按步骤恢复设备，并理解 KernelSU 安全模式在底层是如何实现与触发的。

故障成因分析：KernelSU 为什么会把设备"刷砖"

"变砖"在绝大多数情况下并非不可逆，关键在于判断故障发生在哪一环节。KernelSU 的救援文档将故障归纳为两大来源：boot 分区刷写问题与模块安装问题，二者的成因、危害程度和救援手段完全不同。

刷写 boot 分区导致的引导失败

使用 fastboot 只刷 boot 分区本身风险相对可控，但以下三种情况会导致设备无法启动：

1. 刷入了错误格式的 boot 镜像。不同设备的 boot 分区压缩格式并不相同。例如，若设备的启动格式是gz（gzip 压缩），却误刷入了lz4格式的镜像，内核将无法解压引导，设备自然无法开机。
2. 未关闭 AVB 校验。部分设备在修改 boot 分区后需要关闭 AVB（Android Verified Boot）验证才能正常引导，而关闭 AVB 通常意味着需要清空设备全部数据。
3. 内核本身存在缺陷或不兼容。刷入的 KernelSU 内核若包含 bug，或与设备硬件、固件版本不匹配，同样会导致引导失败。

无论具体是哪种情况，刷回官方（stock）boot 镜像都是恢复设备的最可靠手段。正因为如此，官方安装指南从一开始就强烈建议：刷机前务必备份原始 boot 镜像。如果你没有备份，可以从同型号设备的其他用户处获取原厂 boot，或直接从官方固件中提取。

模块导致的 bootloop：最常见也最危险

安装模块是导致变砖的更常见原因。模块运行在 root 权限之下，能力与内核同级，一旦出错可能造成不可逆的损害。因此官方文档给出了明确警告：绝对不要安装来源不明的模块。

不过，模块导致的 bootloop 也需要区分两种情况：

• 正常模块：模块本身来源可靠、行为安全，只是恰好与设备环境不兼容导致无法开机。这类问题在 KernelSU 中几乎都可以轻松恢复。
• 恶意或破坏性模块：模块包含恶意操作（如格式化数据、破坏分区），或直接损坏了设备。这类问题只能通过清数据重刷官方系统或送修解决。

判断模块属于哪一类，决定了你该采用下面的哪种救援手段。

内核级安全模式：音量键三连击救援法

对于来源可靠但导致无法开机的"正常模块"，KernelSU 内置了**安全模式（Safe Mode）**救援机制。进入安全模式后，所有模块都会被禁用，系统得以正常启动；之后再进入 KernelSU Manager 的模块页面，就能卸载引发问题的模块。

两种进入安全模式的途径

1. 利用系统自带的 Safe Mode：部分 ROM 内置安全模式，通常通过长按音量减键进入；另一些系统（如 MIUI/HyperOS）可以在 Recovery 中开启。系统进入安全模式时，KernelSU 也会同步进入该模式并自动禁用模块。在用户态侧，utils.rs 会通过getprop("persist.sys.safemode")与getprop("ro.sys.safemode")检测系统级安全模式属性，一旦命中即判定为安全模式。
2. KernelSU 自带的安全模式：在开机动画出现（第一个开机画面）之后，连续快速按下音量减键 3 次以上。注意手法是"按下-松开、按下-松开、按下-松开"，而不是长按不松。

底层实现：内核态的按键监听

安全模式的检测并非由用户态完成，而是实现在内核中。从源码看，其核心逻辑位于 ksud_integration.c：

• 内核通过 kprobe 挂载input_event符号（见 ksud_integration.c），监听全局输入事件；
• 在ksu_handle_input_handle_event()中，每当捕获到EV_KEY+KEY_VOLUMEDOWN的按下事件，就累加volumedown_pressed_count计数；
• is_volumedown_enough()的判定阈值是count >= 3，即至少按满 3 次；
• 计数达标后立即通过ksu_stop_input_hook_runtime()停止监听，随后ksu_is_safe_mode()返回 true。

之所以把实现放在内核而不是用户态，正是为了避免按键事件被上层拦截而丢失——系统起不来时，用户态服务可能根本没有机会运行，而内核的 kprobe 钩子只要设备通电就能工作。不过需要注意：对于非 GKI 内核，可能需要手动集成这部分代码，具体请参考官方集成文档（how-to-integrate-for-non-gki.md）。

时序要求与两个限制

官方文档对此机制有一个醒目的警告，实操时务必留意：

• 内核模块在初始化阶段注册音量键监听（LKM 模式下，即内核执行 init 进程时加载），并在on_post_fs_data阶段（开机动画之前）取消注册。查看 boot_event.c 可以看到，on_post_fs_data中正是通过ksu_stop_input_hook_runtime()停止按键采样的。也就是说，只有在开机画面出现后、on_post_fs_data之前的极短时间窗内连续按下 3 次音量减键才能触发安全模式。如果设备启动很快或操作不及时，安全模式可能不会触发，需要重试。
• 如果模块在 init.rc 中写入了不合理的代码导致无法开机，这些代码即使在安全模式下依然会执行——因为 init.rc 的注入发生在更早的内核引导阶段，安全模式的禁用逻辑影响不到它。这类情况需要走下面的手动救援流程。

手动救援方案一：ADB 配合 ksud 命令行

如果设备还能通过 ADB 获得 root shell，就不需要动用 Recovery，直接命令行操作即可。

在 ADB shell 中依次执行：

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

ksud是 KernelSU 的用户态守护进程/命令行工具（源码位于 userspace/ksud），其模块子命令在 cli.rs 中定义，list、disable、uninstall分别对应列出、禁用、卸载操作，底层分别调用module::disable_module()与module::uninstall_module()（见 cli.rs）。

一个实用的技巧：在 Recovery 模式下也可以运行/data/adb/ksud。只要先挂载metadata和data分区，就能在 Recovery 中管理模块。由于 GKI 设备共用init，KernelSU 内核模块在 Recovery 模式下依然会被加载，因此ksud的大多数功能（例如设置 feature）都能正常使用。

手动救援方案二：Recovery 手动清理

如果设备完全进不了系统（连 ADB 都连不上），就需要借助第三方 Recovery（如 TWRP）。

KernelSU 的模块加载链路依赖两个关键环节：内核侧的 init.rc 注入文件与用户态的 ksud 进程。只要删除这些文件并重启，KernelSU 就不会再加载任何模块。完整操作步骤如下：

1. 进入 Recovery（如 TWRP）。
2. 挂载 data 分区：

   mount /data

   （如果 data 分区已加密，需要先解密，具体方法取决于设备和加密方案。）

3. 删除 ksud，阻止模块加载：

   rm -f /data/adb/ksud

4. （可选）挂载 metadata 分区，删除模块生成的 init.rc 注入文件：

   mount /metadata rm -f /metadata/ksu/modules.rc rm -f /metadata/watchdog/ksu/modules.rc

5. 重启设备：

   reboot

重启后 KernelSU 会跳过所有模块的加载，系统即可正常进入；随后打开 KernelSU Manager 即可处理模块问题。

这一步的底层依据同样能在源码中找到：模块的 init.rc 注入文件正是由 ksud 在 preinit 阶段生成的modules.rc（常量定义见 defs.rs，其中PREINIT_DIR_WATCHDOG指向/metadata/watchdog/ksu/），内核通过挂钩 init 读取/system/etc/init/init.rc的过程，将模块 rc 内容拼接注入（见 ksud_integration.c 的ksu_install_rc_hook）。删除ksud与两个位置的modules.rc，等于同时切断"注入源头"和"注入内容"，下次开机便不再有任何模块参与引导。另外注意，init_event.rs 显示 ksud 每次正常启动还会重新生成 preinit rc 作为"安全网"，因此手动清理后首次进入系统时，不要再让旧的 ksud 残留重新执行。

兜底方案：格式化数据与送修

如果以上所有手段都无法救回设备，那么大概率是模块包含了恶意操作，或已经以其他方式损坏了设备。此时只剩下两个选择：

1. 清除数据并完整刷入官方系统（wipe 后刷入官方固件，相当于彻底重装）。
2. 联系售后服务中心进行检修。

救援决策速查

预防建议

救援永远不如预防。结合官方文档的告诫，建议在刷机前做好三件事：一是始终备份原始 boot 镜像，这是刷坏 boot 分区后最快恢复的前提；二是只安装可信来源的模块，对来源不明、评价存疑的模块保持警惕；三是熟悉安全模式的触发时机，在设备启动缓慢时可抓住开机画面出现后的短暂窗口完成三次按键，为后续救援留出退路。理解 KernelSU 安全模式的内核实现与模块加载链路，不仅能让你在故障发生时从容应对，也能帮助你在集成 KernelSU 到非 GKI 设备时，正确地保留和适配这套救援机制。

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