KernelSU 安装实战指南：LKM 与 GKI 双模式、KMI 匹配原理与 ksud boot-patch 详解

KernelSU 安装实战指南：LKM 与 GKI 双模式、KMI 匹配原理与 ksud boot-patch 详解

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

本文基于 KernelSU 官方安装文档（website/docs/id_ID/guide/installation.md）展开，覆盖从设备支持性检查、boot.img 备份，到 LKM/GKI 两种安装模式的完整操作流程、ksud boot-patch命令行参数、KMI 与安全补丁级别的匹配规则，并结合仓库源码逐条印证分区选择、镜像备份与恢复的底层实现，帮助你在真实设备上独立完成 KernelSU 的安装、升级与恢复。

安装前的两步检查：设备支持性与 boot.img 备份

检查设备是否受支持

下载并安装 KernelSU 管理器后，根据应用显示的状态判断设备支持情况：

• 如果应用显示Unsupported，说明你需要自行编译内核。KernelSU 官方不会、也绝不会提供现成的 boot.img 供你刷机；
• 如果应用显示Not installed，说明你的设备被 KernelSU 官方支持。

对显示Unsupported的设备，可以查看非官方支持设备列表，自行编译内核后再安装。

备份原版 boot.img

刷机前必须备份原版（stock）boot.img。一旦遇到 bootloop，你随时可以用 fastboot 将原版 boot 刷回去恢复系统。

警告：刷机可能导致数据丢失。请务必先完成备份再进行下一步操作；如有必要，建议对设备上的全部数据做备份。

必要前置知识

ADB 与 fastboot

本文后续所有操作步骤默认使用 ADB 和 fastboot 工具。如果你不熟悉它们，建议先自行学习再动手。

KMI（Kernel Module Interface）

KMI 即内核模块接口：KMI 相同的内核版本之间是兼容的，这正是 GKI 中 "Generic（通用）" 的含义；反之，KMI 不同的内核彼此不兼容，向设备刷入 KMI 不一致的 kernel image 可能导致 bootloop。

对 GKI 设备，内核版本号格式应如下所示：

KernelRelease := Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix w .x .y -zzz -k -something

其中w.x-zzz-k就是 KMI 版本。例如设备内核版本为5.10.101-android12-9-g30979850fc20，其 KMI 为5.10-android12-9，理论上它可以正常启动其他符合该 KMI 的内核。

提示：注意 SubLevel 不属于 KMI 的一部分！也就是说5.10.101-android12-9-g30979850fc20与5.10.137-android12-9-g30979850fc20拥有相同的 KMI。

从源码结构看，这个"从内核版本号中提取 KMI"的逻辑在仓库中有两处完全对齐的实现：

• 管理器端 manager/app/src/main/java/me/weishu/kernelsu/core/tasks/BootKernelVersion.kt 使用正则(\d+\.\d+)(?:\S+)?(android\d+)扫描 boot 镜像内核块中的内核 banner 字符串，输出形如android15-6.6的 KMI（注释中明确写着 "Mirrors ksud's parse_kmi_from_boot"）；
• 命令行工具端 userspace/ksud/src/boot_patch.rs 的parse_kmi用同样的正则扫描内核字节流。自动识别失败时，ksud 会打印 "Try to choose LKM manually"，即提示你改用--kmi手动指定。

安全补丁级别（Security Patch Level）

较新的 Android 设备可能带有防回滚（anti-rollback）机制，阻止刷入安全补丁级别过旧的 boot 镜像。例如：你的设备内核是5.10.101-android12-9-g30979850fc20，其安全补丁级别为2023-11；即使你刷的内核 KMI 匹配，只要其安全补丁级别早于2023-11（比如2023-06），就可能引起 bootloop。

因此，在 KMI 相同的前提下，优先选择安全补丁级别最新的内核镜像。

内核版本 vs Android 版本

请注意：内核版本与 Android 系统版本并不一定相同！

如果你发现内核版本是android12-5.10.101，而系统已经是 Android 13 或其他版本，不要感到意外。Linux 内核版本号一般对应设备出厂时搭载的 Android 版本；之后系统升级，内核版本通常不会改变。所以，在刷入任何东西之前，一定要以内核版本为准！

KernelSU 的两种运行模式：LKM 与 GKI

自 v0.9.0 起，KernelSU 在 GKI 设备上支持两种运行模式，二者适配不同场景，可按需选择：

1. LKM：将Loadable Kernel Module（LKM）加载进设备内核，不替换原内核；
2. GKI：用 KernelSU 提供的Generic Kernel Image（GKI）替换设备原内核。

LKM 模式的优势

LKM 模式下原内核不会被替换，只是将可加载内核模块注入设备内核。其优点：

1. 不替换设备原内核。如果你对原内核有特殊需求，或希望在第三方内核上叠加 KernelSU，可用 LKM 模式；
2. 升级与 OTA 更便捷。升级 KernelSU 时可直接在管理器中安装，无需手动刷机；系统 OTA 后可直接安装到第二个槽位；
3. 适合特殊场景。LKM 可以在临时 root 权限下加载；由于不替换 boot 分区，不会触发 AVB 校验，不会导致设备变砖；
4. 可临时卸载。想暂时禁用 root 时，卸载 LKM 即可，无需刷分区、甚至无需重启；想恢复 root 时重启设备即可。

GKI 模式的优势

GKI 模式用 KernelSU 提供的通用内核镜像替换设备原内核。其优点：

1. 通用性强，适合大多数设备。例如三星 KNOX 设备上 LKM 模式无法工作，部分小众修改设备也只能用 GKI 模式；
2. 不依赖官方固件。只要 KMI 一致即可使用，无需等待官方固件更新。

如何选择

• 如果设备是手机，优先选择LKM 模式；
• 如果设备是模拟器、WSA 或 Waydroid，优先选择GKI 模式。

LKM 模式安装

获取官方固件

使用 LKM 模式需要获取官方固件，并基于官方固件进行 patch。如果你使用的是第三方内核，可以直接把该第三方内核的boot.img当作"官方固件"。

获取固件的方式很多。若设备支持fastboot boot，最推荐、最简单的做法是：用fastboot boot临时引导 KernelSU 提供的 GKI 内核，安装管理器，最后直接在管理器中完成安装——全程无需手动下载官方固件、也无需手动提取 boot。若设备不支持fastboot boot，可能需要手动下载官方固件包并从中提取 boot。

与 GKI 模式不同，LKM 模式修改的是ramdisk。因此在 Android 13 设备上，需要 patch 的是init_boot分区而不是boot分区；而 GKI 模式始终操作boot分区。

从源码可以印证这一判断逻辑：userspace/ksud/src/boot_patch.rs 的choose_boot_partition会先读取ro.boot.slot_suffix得到当前 A/B 槽位后缀，然后检查/dev/block/by-name/init_boot{slot_suffix}是否存在——LKM 模式（is_replace_kernel == false）且 init_boot 存在、且 KMI 不是android12-*（Android 12 无独立 init_boot 分区）时选择init_boot，否则回落到boot；显式指定--partition boot|init_boot|vendor_boot时则直接采用。

通过管理器安装

打开管理器，点击右上角的安装图标，会出现以下选项：

1. 选择文件：设备没有 root 权限时可选此项，选择你的官方固件文件，管理器会自动完成 patch，之后刷入该已 patch 的文件即可获得永久 root；
2. 直接安装：设备已 root 时可选此项。管理器会自动获取设备信息、自动 patch 官方固件并自动刷入。可以配合fastboot bootKernelSU 的 GKI 内核获得临时 root 来安装管理器，再使用本选项。这也是升级 KernelSU 的主要方式；
3. 安装到非活动槽位：设备支持 A/B 分区时可选此项。管理器自动 patch 官方固件并安装到另一个分区，适合 OTA 之后直接装入另一槽位再重启。

关于原版 boot 镜像的自动备份使用管理器的"直接安装"会自动备份原版 boot（或 init_boot）镜像，供增量 OTA 更新期间临时恢复。注意：仅当当前槽位尚未被 KernelSU patch 过才会创建该备份。 备份镜像的 SHA1 值存放在已 patch 的 boot 镜像内，备份文件保存在/data/adb/ksu/ksu_backup_$SHA1。 使用管理器的"卸载 → 恢复原版镜像"功能时，若存在与当前已 patch 镜像中记录的 SHA1 匹配的备份文件，会直接恢复该备份。 自 3.3.0 起，若是无 root 状态首次安装 KernelSU，在"选择文件"patch boot 镜像之后可以选择"备份为原版镜像"。此时备份暂存于管理器内部存储；刷入并启动已 patch 镜像后，首次打开管理器会自动将该备份转移到/data/adb/ksu。

这条备份链路在源码中有完整对应：

• userspace/ksud/src/defs.rs 定义了KSU_BACKUP_DIR = /data/adb/ksu/、KSU_BACKUP_FILE_PREFIX = "ksu_backup_"、BACKUP_FILENAME = "stock_image.sha1"；
• userspace/ksud/src/boot_patch.rs 的calculate_sha1计算原版镜像 SHA1，find_backup_location首选/data/adb/ksu/ksu_backup_$SHA1，无权限时回退到应用私有目录/data/user_de/$USER/$PKG/boot_backup（这正是管理器"内部存储暂存"的实现）；
• userspace/ksud/src/boot_patch.rs 的do_backup将原版镜像拷贝到备份路径，并把 SHA1 写入 ramdisk 中名为stock_image.sha1的 cpio 条目；
• 恢复时 userspace/ksud/src/boot_patch.rs 从 cpio 中读取 SHA1，定位/data/adb/ksu/ksu_backup_$SHA1直接刷回，并用clean_backup清掉其他过期备份文件。

通过命令行安装（ksud boot-patch）

如果不使用管理器，也可以走命令行。KernelSU 提供的ksud工具可以快速 patch 官方固件并刷入，支持 macOS、Linux 与 Windows。

用法为ksud boot-patch，具体选项可用命令行帮助查看：

oriole:/ # ksud boot-patch -h Patch boot or init_boot images to apply KernelSU Usage: ksud boot-patch [OPTIONS] Options: -b, --boot <BOOT> Boot image path. If not specified, it will try to find the boot image automatically -k, --kernel <KERNEL> Kernel image path to be replaced -m, --module <MODULE> LKM module path to be replaced. If not specified, the built-in module will be used -i, --init <INIT> init to be replaced -u, --ota Will use another slot if the boot image is not specified -f, --flash Flash it to boot partition after patch -o, --out <OUT> Output path. If not specified, the current directory will be used --magiskboot <MAGISKBOOT> magiskboot path. If not specified, the built-in version will be used --kmi <KMI> KMI version. If specified, the indicated KMI will be used -h, --help Print help

重点选项说明：

1. --magiskboot可指定 magiskboot 路径；不指定时 ksud 会优先使用内置版本，或从环境变量中查找。如何获取 magiskboot 可参考下文手动 patch boot.img；
2. --kmi可指定 KMI 版本。当你的设备内核命名不符合 KMI 规范（自动识别会失败）时，可用该选项显式指定。

最常用的用法：

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

从源码看（userspace/ksud/src/boot_patch.rs 的BootPatchArgs），文档帮助输出之外还有一批参数值得了解：--backup（强制备份原版镜像）、--partition <init_boot|boot|vendor_boot>（覆盖目标分区）、--out-name（输出文件名）、--cmdline（向 boot 头追加 cmdline）、--allow-shell（始终允许 shell 获取 root）、--enable-adbd/--adb-debug-prop（强制启用 adbd 并关闭鉴权，用于救砖）、--no-install（只改配置、不重装 KernelSU）、--no-custom-rc（不加载自定义 rc）、--arch（非 Android 端的架构，默认 aarch64）、--ramdisk（patch ramdisk 而非 boot 镜像，用于 AVD 场景）。其中--ota、--flash、--out、--backup、--partition等仅在 Android 目标编译时可用（#[cfg(target_os = "android")]），在 Android 设备上带--flash时，ksud 会直接打开/dev/block/by-name/boot{slot}块设备、先用BLKROSETioctl 解除只读再写入（userspace/ksud/src/boot_patch.rs），实现免电脑刷机。

patch 流程本身在 userspace/ksud/src/boot_patch.rs 的patch函数中：解析 boot 头 → 校验 bootimage 版本 → 按 KMI 选取内嵌的{kmi}_kernelsu.ko→ 将 ramdisk 中的原init改名为init.real，写入新的init（ksuinit）与kernelsu.ko→ 重打包镜像。

两条硬约束来自源码：enforce_bootimage_version要求 boot 镜像头版本不低于 Android 3（userspace/ksud/src/boot_patch.rs）；若目标 ramdisk 已被 Magisk patch 过，patch 会直接拒绝（"Cannot work with Magisk patched image"）。此外在未指定--boot的 Android 设备上，ksud 会先检查当前内核是否为 GKI（5.10+ 或 6.x），不满足则报 "only support GKI kernel"（userspace/ksud/src/boot_patch.rs）。

GKI 模式安装

GKI 模式有几种安装方法，各自适合不同场景，按需选择：

1. 使用 KernelSU 提供的 boot.img，通过 fastboot 安装；
2. 使用 Kernel Flasher 一类的刷 kernel 应用安装；
3. 手动修补 boot.img 后安装；
4. 使用自定义 Recovery（如 TWRP）安装。

使用 KernelSU 提供的 boot.img 安装

如果你的设备boot.img采用常见的压缩格式，可以直接使用 KernelSU 提供的 GKI 镜像刷入，无需 TWRP、也无需自行 patch 镜像。

选择合适的 boot.img：KernelSU 为 GKI 设备提供通用 boot.img，你需要将其刷入设备 boot 分区。请特别注意选用正确版本的 boot.img——如果不确定该下载哪个文件，请仔细阅读本文 KMI 与安全补丁级别 两节的说明。

通常同一个 KMI + 安全补丁级别会对应三个不同格式的 boot 文件，除内核压缩格式外内容一致。请核对原版 boot.img 的内核压缩格式并使用正确格式（如lz4、gz）；选错压缩格式可能刷入后 bootloop。

关于 boot.img 压缩格式的提示

1. 可用 magiskboot 查看原版 boot.img 的压缩格式；也可以询问拥有相同机型的社区成员或开发者。内核压缩格式一般保持不变——若某格式曾成功引导，后续可沿用该格式；
2. 小米设备通常使用gz或uncompressed；
3. Pixel 设备请看下文手动 patch 一节。

管理器端的镜像校验逻辑与文档一致：manager/app/src/main/java/me/weishu/kernelsu/core/tasks/BootKernelVersion.kt 中识别的压缩 magic 包括 gzip（0x1F 0x8B）、xz（FD 37 7A 58 5A 00）与 lz4 frame（04 22 4D 18），与 manager/app/src/main/java/me/weishu/kernelsu/Kernels.kt 中"5.10 及以上 / 6.x 才判定为 GKI"的支持性检查相配合。

刷入设备：用adb连接设备，执行adb reboot bootloader进入 fastboot 模式，然后：

fastboot flash boot boot.img

若设备支持fastboot boot，建议先用fastboot boot boot.img临时引导验证，出现意外时重新开机即可回到原系统。

重启：刷入完成后重启设备：

fastboot reboot

使用 Kernel Flasher 安装

步骤：

1. 下载 AnyKernel3 ZIP。如果不确定下载哪个文件，请仔细阅读本文 KMI 与安全补丁级别 说明；
2. 打开 Kernel Flasher 应用，授予所需 root 权限，使用 KernelSU 提供的 AnyKernel3 ZIP 刷入。

该方式要求 Kernel Flasher 拥有 root 权限，可通过以下途径获得：

1. 设备已 root。例如已安装 KernelSU 想升级到最新版，或已通过 Magisk 等方式 root；
2. 设备未 root 但支持fastboot boot boot.img临时引导：用 KernelSU 提供的 GKI 镜像临时启动设备获得临时 root，再用该类应用刷入获得永久 root。

常见的可配合使用的刷 kernel 应用包括 Kernel Flasher、Franco Kernel Manager、Ex Kernel Manager 等（在管理器 Release 页面获取对应工具）。

注意：此方法在升级KernelSU 时尤为方便，且无需电脑即可完成（前提是先做好备份）。

手动 Patch boot.img

部分设备的 boot.img 格式并非常见的lz4、gz、uncompressed。典型案例是 Pixel：其 boot.img 采用lz4_legacy格式压缩，ramdisk 可能是gz或同样为lz4_legacy。这种情况下直接刷 KernelSU 提供的 boot.img 可能导致设备无法启动，需要手动 patch boot.img。

推荐始终使用magiskboot修补镜像，有两个获取途径：

1. Magisk 官方 Release 中的magiskboot（官方构建只能运行在 Android 设备上）；
2. magiskboot_build社区构建（可运行在 PC 上）。

提示：目前不推荐 Android-Image-Kitchen，因为它对 boot metadata（如安全补丁级别）处理不正确，可能在部分设备上无法工作。

准备工作

1. 获取设备原版 boot.img（可来自设备厂商的固件包，可能用到 payload-dumper-go 一类工具提取）；
2. 下载与设备 KMI 匹配的 KernelSU 提供的 AnyKernel3 ZIP（可参考下文自定义 Recovery 安装）；
3. 解压 AnyKernel3 包，取出其中的Image文件——这就是 KernelSU 的内核文件。

在 Android 设备上使用 magiskboot

1. 下载最新版 Magisk；
2. 将Magisk-*(version).apk重命名为Magisk-*.zip并解压；
3. 通过 ADB 推送Magisk-*/lib/arm64-v8a/libmagiskboot.so到设备：adb push Magisk-*/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot；
4. 将原版 boot.img 与 AnyKernel3 中的 Image 推送到设备；
5. 进入 ADB shell，cd /data/local/tmp/后执行chmod +x magiskboot；
6. 执行./magiskboot unpack boot.img解包，得到kernel文件（即原版内核）；
7. 用 Image 替换内核：mv -f Image kernel；
8. 执行./magiskboot repack boot.img重新打包，得到new-boot.img，用 fastboot 刷入设备。

在 Windows/macOS/Linux PC 上使用 magiskboot

1. 下载对应操作系统的magiskboot二进制（可来自 magiskboot_build 的 CI 构建）；
2. 在 PC 上准备好原版boot.img与Image；
3. 执行chmod +x magiskboot；
4. 进入对应目录，执行./magiskboot unpack boot.img解包，得到kernel（原版内核）；
5. 用 Image 替换内核：mv -f Image kernel；
6. 执行./magiskboot repack boot.img重新打包，得到new-boot.img，用 fastboot 刷入设备。

官方magiskboot在 Linux 环境下可正常运行，Linux 用户可直接使用官方构建。

自定义 Recovery 安装

前提：设备已有 TWRP 等自定义 Recovery；如果没有可用的自定义 Recovery，请改用其他方法。

步骤：

1. 在 KernelSU 的 GitHub Release 页面，下载以AnyKernel3开头、与设备版本匹配的 ZIP 包。例如设备内核版本为android12-5.10.66，则应下载AnyKernel3-android12-5.10.66_yyyy-MM.zip（yyyy为年份，MM为月份）；
2. 重启设备进入 TWRP；
3. 用 ADB 将AnyKernel3-*.zip放到设备/sdcard下，在 TWRP 图形界面中选择安装；或者直接执行adb sideload AnyKernel-*.zip刷入。

注意：只要使用 TWRP，该方法适用于任何安装场景（不限于首次安装或后续升级）。

其他安装方法

事实上，以上所有安装方法的核心思路只有一个：用 KernelSU 提供的内核替换原内核——只要能达成这一点，即可安装成功。其他可行路径还包括：

1. 先安装 Magisk 获得 root，再用 Kernel Flasher 刷入 KernelSU 的 AnyKernel3 ZIP；
2. 使用 PC 上任意刷机工具集刷入 KernelSU 提供的内核。

如果上述方法均不奏效，回退到magiskboot手动修补路线。

安装后：模块支持（Metamodule）

警告：修改 /system 文件需要 metamodule如果要使用会修改/system文件的模块，必须在安装 KernelSU 之后安装metamodule；仅使用脚本、sepolicy 或 system.prop 的模块则无需 metamodule。

关于/system修改支持，请继续阅读Metamodule 指南，了解：

• metamodule 是什么、为什么需要；
• 如何安装官方meta-overlayfsmetamodule；
• 其他可选的 metamodule 方案。

小结

安装 KernelSU 的关键决策点可以浓缩为四步：先用管理器判定Not installed/Unsupported，再备份原版 boot.img；确认内核 KMI 与安全补丁级别（注意 SubLevel 不参与 KMI、以内核版本而非 Android 版本为准）；手机优先 LKM 模式（改 ramdisk，Android 13 上作用于 init_boot），模拟器/WSA/Waydroid 优先 GKI 模式（直接替换内核，压缩格式必须匹配）；遇到非常规 boot 格式时用 magiskboot 手动 unpack/repack 兜底。配合ksud boot-patch的--ota、--flash与自动备份/恢复机制，升级、OTA 与救砖都有明确路径可循。

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