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刷机前必须备份原版stockboot.img。一旦遇到 bootloop你随时可以用 fastboot 将原版 boot 刷回去恢复系统。警告刷机可能导致数据丢失。请务必先完成备份再进行下一步操作如有必要建议对设备上的全部数据做备份。必要前置知识ADB 与 fastboot本文后续所有操作步骤默认使用 ADB 和 fastboot 工具。如果你不熟悉它们建议先自行学习再动手。KMIKernel Module InterfaceKMI 即内核模块接口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 ksuds 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 设备上支持两种运行模式二者适配不同场景可按需选择LKM将Loadable Kernel ModuleLKM加载进设备内核不替换原内核GKI用 KernelSU 提供的Generic Kernel ImageGKI替换设备原内核。LKM 模式的优势LKM 模式下原内核不会被替换只是将可加载内核模块注入设备内核。其优点不替换设备原内核。如果你对原内核有特殊需求或希望在第三方内核上叠加 KernelSU可用 LKM 模式升级与 OTA 更便捷。升级 KernelSU 时可直接在管理器中安装无需手动刷机系统 OTA 后可直接安装到第二个槽位适合特殊场景。LKM 可以在临时 root 权限下加载由于不替换 boot 分区不会触发 AVB 校验不会导致设备变砖可临时卸载。想暂时禁用 root 时卸载 LKM 即可无需刷分区、甚至无需重启想恢复 root 时重启设备即可。GKI 模式的优势GKI 模式用 KernelSU 提供的通用内核镜像替换设备原内核。其优点通用性强适合大多数设备。例如三星 KNOX 设备上 LKM 模式无法工作部分小众修改设备也只能用 GKI 模式不依赖官方固件。只要 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时则直接采用。通过管理器安装打开管理器点击右上角的安装图标会出现以下选项选择文件设备没有 root 权限时可选此项选择你的官方固件文件管理器会自动完成 patch之后刷入该已 patch 的文件即可获得永久 root直接安装设备已 root 时可选此项。管理器会自动获取设备信息、自动 patch 官方固件并自动刷入。可以配合fastboot bootKernelSU 的 GKI 内核获得临时 root 来安装管理器再使用本选项。这也是升级 KernelSU 的主要方式安装到非活动槽位设备支持 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.sha1userspace/ksud/src/boot_patch.rs 的calculate_sha1计算原版镜像 SHA1find_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重点选项说明--magiskboot可指定 magiskboot 路径不指定时 ksud 会优先使用内置版本或从环境变量中查找。如何获取 magiskboot 可参考下文手动 patch boot.img--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、--ramdiskpatch 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写入新的initksuinit与kernelsu.ko→ 重打包镜像。两条硬约束来自源码enforce_bootimage_version要求 boot 镜像头版本不低于 Android 3userspace/ksud/src/boot_patch.rs若目标 ramdisk 已被 Magisk patch 过patch 会直接拒绝Cannot work with Magisk patched image。此外在未指定--boot的 Android 设备上ksud 会先检查当前内核是否为 GKI5.10 或 6.x不满足则报 only support GKI kerneluserspace/ksud/src/boot_patch.rs。GKI 模式安装GKI 模式有几种安装方法各自适合不同场景按需选择使用 KernelSU 提供的 boot.img通过 fastboot 安装使用 Kernel Flasher 一类的刷 kernel 应用安装手动修补 boot.img 后安装使用自定义 Recovery如 TWRP安装。使用 KernelSU 提供的 boot.img 安装如果你的设备boot.img采用常见的压缩格式可以直接使用 KernelSU 提供的 GKI 镜像刷入无需 TWRP、也无需自行 patch 镜像。选择合适的 boot.imgKernelSU 为 GKI 设备提供通用 boot.img你需要将其刷入设备 boot 分区。请特别注意选用正确版本的 boot.img——如果不确定该下载哪个文件请仔细阅读本文 KMI 与安全补丁级别 两节的说明。通常同一个 KMI 安全补丁级别会对应三个不同格式的 boot 文件除内核压缩格式外内容一致。请核对原版 boot.img 的内核压缩格式并使用正确格式如lz4、gz选错压缩格式可能刷入后 bootloop。关于 boot.img 压缩格式的提示可用 magiskboot 查看原版 boot.img 的压缩格式也可以询问拥有相同机型的社区成员或开发者。内核压缩格式一般保持不变——若某格式曾成功引导后续可沿用该格式小米设备通常使用gz或uncompressedPixel 设备请看下文手动 patch 一节。管理器端的镜像校验逻辑与文档一致manager/app/src/main/java/me/weishu/kernelsu/core/tasks/BootKernelVersion.kt 中识别的压缩 magic 包括 gzip0x1F 0x8B、xzFD 37 7A 58 5A 00与 lz4 frame04 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 安装步骤下载 AnyKernel3 ZIP。如果不确定下载哪个文件请仔细阅读本文 KMI 与安全补丁级别 说明打开 Kernel Flasher 应用授予所需 root 权限使用 KernelSU 提供的 AnyKernel3 ZIP 刷入。该方式要求 Kernel Flasher 拥有 root 权限可通过以下途径获得设备已 root。例如已安装 KernelSU 想升级到最新版或已通过 Magisk 等方式 root设备未 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修补镜像有两个获取途径Magisk 官方 Release 中的magiskboot官方构建只能运行在 Android 设备上magiskboot_build社区构建可运行在 PC 上。提示目前不推荐 Android-Image-Kitchen因为它对 boot metadata如安全补丁级别处理不正确可能在部分设备上无法工作。准备工作获取设备原版 boot.img可来自设备厂商的固件包可能用到 payload-dumper-go 一类工具提取下载与设备 KMI 匹配的 KernelSU 提供的 AnyKernel3 ZIP可参考下文自定义 Recovery 安装解压 AnyKernel3 包取出其中的Image文件——这就是 KernelSU 的内核文件。在 Android 设备上使用 magiskboot下载最新版 Magisk将Magisk-*(version).apk重命名为Magisk-*.zip并解压通过 ADB 推送Magisk-*/lib/arm64-v8a/libmagiskboot.so到设备adb push Magisk-*/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot将原版 boot.img 与 AnyKernel3 中的 Image 推送到设备进入 ADB shellcd /data/local/tmp/后执行chmod x magiskboot执行./magiskboot unpack boot.img解包得到kernel文件即原版内核用 Image 替换内核mv -f Image kernel执行./magiskboot repack boot.img重新打包得到new-boot.img用 fastboot 刷入设备。在 Windows/macOS/Linux PC 上使用 magiskboot下载对应操作系统的magiskboot二进制可来自 magiskboot_build 的 CI 构建在 PC 上准备好原版boot.img与Image执行chmod x magiskboot进入对应目录执行./magiskboot unpack boot.img解包得到kernel原版内核用 Image 替换内核mv -f Image kernel执行./magiskboot repack boot.img重新打包得到new-boot.img用 fastboot 刷入设备。官方magiskboot在 Linux 环境下可正常运行Linux 用户可直接使用官方构建。自定义 Recovery 安装前提设备已有 TWRP 等自定义 Recovery如果没有可用的自定义 Recovery请改用其他方法。步骤在 KernelSU 的 GitHub Release 页面下载以AnyKernel3开头、与设备版本匹配的 ZIP 包。例如设备内核版本为android12-5.10.66则应下载AnyKernel3-android12-5.10.66_yyyy-MM.zipyyyy为年份MM为月份重启设备进入 TWRP用 ADB 将AnyKernel3-*.zip放到设备/sdcard下在 TWRP 图形界面中选择安装或者直接执行adb sideload AnyKernel-*.zip刷入。注意只要使用 TWRP该方法适用于任何安装场景不限于首次安装或后续升级。其他安装方法事实上以上所有安装方法的核心思路只有一个用 KernelSU 提供的内核替换原内核——只要能达成这一点即可安装成功。其他可行路径还包括先安装 Magisk 获得 root再用 Kernel Flasher 刷入 KernelSU 的 AnyKernel3 ZIP使用 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 模式改 ramdiskAndroid 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 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刷机前必须备份原版stockboot.img。一旦遇到 bootloop你随时可以用 fastboot 将原版 boot 刷回去恢复系统。警告刷机可能导致数据丢失。请务必先完成备份再进行下一步操作如有必要建议对设备上的全部数据做备份。必要前置知识ADB 与 fastboot本文后续所有操作步骤默认使用 ADB 和 fastboot 工具。如果你不熟悉它们建议先自行学习再动手。KMIKernel Module InterfaceKMI 即内核模块接口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 ksuds 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 设备上支持两种运行模式二者适配不同场景可按需选择LKM将Loadable Kernel ModuleLKM加载进设备内核不替换原内核GKI用 KernelSU 提供的Generic Kernel ImageGKI替换设备原内核。LKM 模式的优势LKM 模式下原内核不会被替换只是将可加载内核模块注入设备内核。其优点不替换设备原内核。如果你对原内核有特殊需求或希望在第三方内核上叠加 KernelSU可用 LKM 模式升级与 OTA 更便捷。升级 KernelSU 时可直接在管理器中安装无需手动刷机系统 OTA 后可直接安装到第二个槽位适合特殊场景。LKM 可以在临时 root 权限下加载由于不替换 boot 分区不会触发 AVB 校验不会导致设备变砖可临时卸载。想暂时禁用 root 时卸载 LKM 即可无需刷分区、甚至无需重启想恢复 root 时重启设备即可。GKI 模式的优势GKI 模式用 KernelSU 提供的通用内核镜像替换设备原内核。其优点通用性强适合大多数设备。例如三星 KNOX 设备上 LKM 模式无法工作部分小众修改设备也只能用 GKI 模式不依赖官方固件。只要 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时则直接采用。通过管理器安装打开管理器点击右上角的安装图标会出现以下选项选择文件设备没有 root 权限时可选此项选择你的官方固件文件管理器会自动完成 patch之后刷入该已 patch 的文件即可获得永久 root直接安装设备已 root 时可选此项。管理器会自动获取设备信息、自动 patch 官方固件并自动刷入。可以配合fastboot bootKernelSU 的 GKI 内核获得临时 root 来安装管理器再使用本选项。这也是升级 KernelSU 的主要方式安装到非活动槽位设备支持 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.sha1userspace/ksud/src/boot_patch.rs 的calculate_sha1计算原版镜像 SHA1find_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重点选项说明--magiskboot可指定 magiskboot 路径不指定时 ksud 会优先使用内置版本或从环境变量中查找。如何获取 magiskboot 可参考下文手动 patch boot.img--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、--ramdiskpatch 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写入新的initksuinit与kernelsu.ko→ 重打包镜像。两条硬约束来自源码enforce_bootimage_version要求 boot 镜像头版本不低于 Android 3userspace/ksud/src/boot_patch.rs若目标 ramdisk 已被 Magisk patch 过patch 会直接拒绝Cannot work with Magisk patched image。此外在未指定--boot的 Android 设备上ksud 会先检查当前内核是否为 GKI5.10 或 6.x不满足则报 only support GKI kerneluserspace/ksud/src/boot_patch.rs。GKI 模式安装GKI 模式有几种安装方法各自适合不同场景按需选择使用 KernelSU 提供的 boot.img通过 fastboot 安装使用 Kernel Flasher 一类的刷 kernel 应用安装手动修补 boot.img 后安装使用自定义 Recovery如 TWRP安装。使用 KernelSU 提供的 boot.img 安装如果你的设备boot.img采用常见的压缩格式可以直接使用 KernelSU 提供的 GKI 镜像刷入无需 TWRP、也无需自行 patch 镜像。选择合适的 boot.imgKernelSU 为 GKI 设备提供通用 boot.img你需要将其刷入设备 boot 分区。请特别注意选用正确版本的 boot.img——如果不确定该下载哪个文件请仔细阅读本文 KMI 与安全补丁级别 两节的说明。通常同一个 KMI 安全补丁级别会对应三个不同格式的 boot 文件除内核压缩格式外内容一致。请核对原版 boot.img 的内核压缩格式并使用正确格式如lz4、gz选错压缩格式可能刷入后 bootloop。关于 boot.img 压缩格式的提示可用 magiskboot 查看原版 boot.img 的压缩格式也可以询问拥有相同机型的社区成员或开发者。内核压缩格式一般保持不变——若某格式曾成功引导后续可沿用该格式小米设备通常使用gz或uncompressedPixel 设备请看下文手动 patch 一节。管理器端的镜像校验逻辑与文档一致manager/app/src/main/java/me/weishu/kernelsu/core/tasks/BootKernelVersion.kt 中识别的压缩 magic 包括 gzip0x1F 0x8B、xzFD 37 7A 58 5A 00与 lz4 frame04 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 安装步骤下载 AnyKernel3 ZIP。如果不确定下载哪个文件请仔细阅读本文 KMI 与安全补丁级别 说明打开 Kernel Flasher 应用授予所需 root 权限使用 KernelSU 提供的 AnyKernel3 ZIP 刷入。该方式要求 Kernel Flasher 拥有 root 权限可通过以下途径获得设备已 root。例如已安装 KernelSU 想升级到最新版或已通过 Magisk 等方式 root设备未 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修补镜像有两个获取途径Magisk 官方 Release 中的magiskboot官方构建只能运行在 Android 设备上magiskboot_build社区构建可运行在 PC 上。提示目前不推荐 Android-Image-Kitchen因为它对 boot metadata如安全补丁级别处理不正确可能在部分设备上无法工作。准备工作获取设备原版 boot.img可来自设备厂商的固件包可能用到 payload-dumper-go 一类工具提取下载与设备 KMI 匹配的 KernelSU 提供的 AnyKernel3 ZIP可参考下文自定义 Recovery 安装解压 AnyKernel3 包取出其中的Image文件——这就是 KernelSU 的内核文件。在 Android 设备上使用 magiskboot下载最新版 Magisk将Magisk-*(version).apk重命名为Magisk-*.zip并解压通过 ADB 推送Magisk-*/lib/arm64-v8a/libmagiskboot.so到设备adb push Magisk-*/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot将原版 boot.img 与 AnyKernel3 中的 Image 推送到设备进入 ADB shellcd /data/local/tmp/后执行chmod x magiskboot执行./magiskboot unpack boot.img解包得到kernel文件即原版内核用 Image 替换内核mv -f Image kernel执行./magiskboot repack boot.img重新打包得到new-boot.img用 fastboot 刷入设备。在 Windows/macOS/Linux PC 上使用 magiskboot下载对应操作系统的magiskboot二进制可来自 magiskboot_build 的 CI 构建在 PC 上准备好原版boot.img与Image执行chmod x magiskboot进入对应目录执行./magiskboot unpack boot.img解包得到kernel原版内核用 Image 替换内核mv -f Image kernel执行./magiskboot repack boot.img重新打包得到new-boot.img用 fastboot 刷入设备。官方magiskboot在 Linux 环境下可正常运行Linux 用户可直接使用官方构建。自定义 Recovery 安装前提设备已有 TWRP 等自定义 Recovery如果没有可用的自定义 Recovery请改用其他方法。步骤在 KernelSU 的 GitHub Release 页面下载以AnyKernel3开头、与设备版本匹配的 ZIP 包。例如设备内核版本为android12-5.10.66则应下载AnyKernel3-android12-5.10.66_yyyy-MM.zipyyyy为年份MM为月份重启设备进入 TWRP用 ADB 将AnyKernel3-*.zip放到设备/sdcard下在 TWRP 图形界面中选择安装或者直接执行adb sideload AnyKernel-*.zip刷入。注意只要使用 TWRP该方法适用于任何安装场景不限于首次安装或后续升级。其他安装方法事实上以上所有安装方法的核心思路只有一个用 KernelSU 提供的内核替换原内核——只要能达成这一点即可安装成功。其他可行路径还包括先安装 Magisk 获得 root再用 Kernel Flasher 刷入 KernelSU 的 AnyKernel3 ZIP使用 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 模式改 ramdiskAndroid 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考