KernelSU 完全 FAQ 指南设备兼容性、模块生态与常见疑难解答【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU导读本文是 KernelSU 官方日文 FAQ 的深度解析版。KernelSU 是一款基于内核的 Android root 解决方案本文围绕「设备兼容性判定」「模块/Xposed/Zygisk 支持」「与 Magisk 的共存与差异」「metamodule 机制」「GKI 与非 GKI 设备」「挂载命名空间」等 FAQ 核心议题展开并结合仓库源码Kconfig、KsuCli.kt、metamodule.md 等做纵深解析。读完本文你将能准确判断自己的设备是否可用 KernelSU、理解模块生态的边界与 metamodule 的安装必要性并掌握非 GKI 内核的集成路径与全局挂载命名空间的实操方法。设备兼容性我的设备支持 KernelSU 吗官方支持的前提条件KernelSU 官方对设备的支持范围可以用两句话概括必须能够解锁 Bootloader如果设备无法解锁引导加载程序则不属于 KernelSU 的支持范围。官方支持仅面向 GKI 内核Linux Kernel 5.10从实践来看这意味着设备出厂预装 Android 12 才可能获得官方支持。KernelSU 的版本兼容性由设备的内核决定与 Android 系统版本无直接关系。判定设备是否受支持的最直接方法是使用 KernelSU Manager 应用KernelSU Manager应用显示Not installed说明设备属于官方支持范围可以直接安装。应用显示Unsupported说明设备当前不在官方支持名单内但仍有两种出路自行编译内核源码并把 KernelSU 集成进去或者借助社区维护的非官方内核详见下文「非 GKI 设备」。Android 版本与内核版本的常见混淆FAQ 中有一个高频问题「我的 Android 版本是 13为什么内核显示android12-5.10」答案是内核版本与 Android 版本没有对应关系。需要刷写内核时永远以内核版本为准例如android12-5.10表示 GKI 内核分支Android 版本并不重要。这一点在刷机、选择内核镜像时务必牢记。旧内核4.14 及更早与 Android 12 以下KernelSU 的兼容性取决于内核而非 Android 版本Android 12 起售的设备必然搭载内核 5.10GKI 设备应当受支持。内核较旧的设备部分 Android 12 设备也使用旧内核以及所有 Android 12 以下的设备具备兼容的可能性但需要自行编译内核。KernelSU 目前已经将支持回移植backport到内核 4.14对于更老的内核则需要手动回移植官方欢迎社区提交 Pull Request。这一能力边界在仓库的 how-to-integrate-for-non-gki.md 中有完整记录——注意该文档已标记为仅存档用途自 KernelSU v1.0 起官方已放弃对非 GKI 设备的支持最后一版支持版本为v0.9.5。GKI 1.0 与 GKI 2.0为什么必须自己编译内核GKIGeneric Kernel Image通用内核镜像1.0 与 2.0 在架构上完全不同。FAQ 明确指出GKI 1.0 设备无法直接使用官方发布的 KernelSU必须自行编译内核。从内核侧配置看KernelSU 的编译开关定义在 kernel/Kconfigconfig KSU tristate KernelSU function support depends on KPROBES EXT4_FS default y help Enable kernel-level root privileges on Android System. Requires CONFIG_KPROBES for kernel hooking support. Requires CONFIG_EXT4_FS for ext4_unregister_sysfs. To compile as a module, choose M here: the module will be called kernelsu.从源码结构看KSU依赖KPROBES内核插桩与EXT4_FS可编译为内建y或可加载内核模块m此时模块名为kernelsuKSU_DEBUG开启调试模式KSU_DISABLE_MANAGER关闭 Manager 集成KSU_DISABLE_POLICY关闭按应用 root 配置文件KSU_X86_PATCH_SYSCALL_DISPATCHER用于 x86_64 LKM 模式下动态修补加固的系统调用分发器。因此无论是 GKI 1.0、非 GKI 还是旧内核设备能否使用 KernelSU 的核心变量始终是内核是否开放源码、是否可自行构建。模块支持KernelSU 的模块生态大多数 Magisk 模块可以直接运行KernelSU支持模块机制且大多数 Magisk 模块都能在 KernelSU 上运行。但有一个关键边界不需要修改/system文件的模块开箱即用无需额外安装任何东西需要修改/system文件的模块必须先安装一个metamodule例如官方参考实现meta-overlayfs否则system目录不会被挂载。模块的完整结构/data/adb/modules/MODID/目录树、module.prop格式、customize.sh变量与函数、post-fs-data.sh/service.sh引导脚本等细节请参阅仓库的 模块指南。FAQ 指向的 metamodule.md 则系统性地解释了 metamodule 的架构。什么是 metamodule为什么它如此重要Metamodule 是一种特殊类型的 KernelSU 模块它为普通模块的「安装与挂载」提供基础设施。它把原本内置于 root 方案核心的挂载逻辑迁移为可插拔的模块实现。这与 Magisk 将挂载逻辑内建于核心的做法形成鲜明对比。关键特性引自 metamodule.md基础设施角色普通模块依赖它提供的挂载服务单实例同一时间只能安装一个 metamodule安装第二个会被 KernelSU 拒绝以防冲突优先执行metamodule 脚本总是先于普通模块脚本运行三个特殊钩子metamount.sh挂载处理、metainstall.sh安装钩子、metauninstall.sh清理钩子符号链接机制安装后 KernelSU 会创建/data/adb/metamodule - /data/adb/modules/metamodule_id提供稳定的访问路径。::: warning 重要如果没有安装 metamodule普通模块将不会被挂载。全新安装 KernelSU 后为了让需要挂载的模块生效必须先安装 metamodule如meta-overlayfs。 :::这也解释了 FAQ 中的经典问题「全新安装后为什么模块不工作」——如果模块需要修改/system文件就必须安装 metamodule 来挂载system目录而脚本、sepolicy 规则、system.prop 等其他模块功能则无需metamodule 即可工作。metamodule 的安装与卸载安装步骤与普通模块完全相同下载 metamodule ZIP例如meta-overlayfs.zip打开 KernelSU Manager点击悬浮操作按钮➕选择 metamodule ZIP 文件重启设备。卸载注意事项::: danger 警告 卸载 metamodule 会影响所有模块删除后在安装另一个 metamodule 之前任何模块都不会再被挂载。 :::切换到另一个 metamodule 的推荐流程卸载所有普通模块 → 卸载当前 metamodule → 重启 → 安装新 metamodule → 重装普通模块 → 再次重启。Xposed、Zygisk 与 LSPosedKernelSU 支持吗FAQ 明确回答Xposed支持。Dreamland、TaiChi 可以直接运行对于 LSPosed或其它现代 Xposed 衍生框架配合 ZygiskNext 即可使用。ZygiskKernelSU 没有内建 Zygisk 支持。需要使用 ZygiskNext 模块来提供 Zygisk 能力之后 Zygisk 模块的内容与 Magisk 下完全一致。这也与 模块指南 中的提示一致KernelSU 模块内不包含 Zygisk 相关内容但安装 ZygiskNext 后即可运行 Zygisk 模块。KernelSU 与 Magisk共存、兼容与替代关系两者能共存吗FAQ 给出了细致且微妙的回答模块系统互相冲突KernelSU 的模块系统与 Magisk 的 magic mount 冲突。只要 KernelSU 启用了任何模块Magisk 整体就会停止工作。仅使用su时可以共存如果只使用 KernelSU 的su不启用模块两者可以很好地协同——因为KernelSU 修改的是kernel而 Magisk 修改的是ramdisk两者互不干扰。KernelSU 会取代 Magisk 吗不会而且这也不是 KernelSU 的目标。官方 FAQ 的表述是Magisk 作为用户态 root 解决方案已经足够优秀并将长期存在KernelSU 的定位是向用户暴露内核接口而非取代 Magisk。在模块层面的差异详见 difference-with-magisk.md维度KernelSUMagisk模块挂载架构委托给可插拔的 metamodule如meta-overlayfs挂载逻辑内建于核心删除/替换文件不支持.replace用mknod filename c 0 0白名单删除支持.replaceBusyBox 路径/data/adb/ksu/bin/busybox/data/adb/magisk/busybox新增执行阶段boot-completed、post-mount阶段无对应阶段Recovery 安装不支持在 Recovery 中安装模块—两边的共同点也很显著模块均为 ZIP 格式、安装目录同为/data/adb/modules、都支持 systemless 修改/system、post-fs-data.sh/service.sh/system.prop/sepolicy.rule语义一致、脚本都在启用 Standalone 模式的 BusyBox 中运行。如何区分脚本运行在 KernelSU 还是 Magisk在所有可执行模块脚本的位置customize.sh、post-fs-data.sh、service.sh环境变量KSU在 KernelSU 下会被设为true。注意不要依赖MAGISK_VER_CODE/MAGISK_VER来判断——在 KernelSU 中它们恒为25200/v25.2不具备区分能力。挂载命名空间KernelSU 有--mount-master/global吗FAQ 明确当前没有内置的全局挂载命名空间选项未来可能会有但提供了多种手动切换到全局挂载命名空间的方法进入全局命名空间的 shellnsenter -t 1 -m sh让单条命令在全局命名空间执行nsenter --mount/proc/1/ns/mnt command从仓库 Manager 侧源码看KernelSU Manager 在构建 root shell 时也提供了全局挂载选项。KsuCli.kt 中fun createRootShell(globalMnt: Boolean false): Shell { ... if (globalMnt) { builder.build(getKsuDaemonPath(), debug, su, -g) } else { builder.build(getKsuDaemonPath(), debug, su) } ... }可以看到su -g用于获取全局挂载命名空间的 root shell普通su则是常规命名空间Manager 内部通过GLOBAL_MNT_SHELL与getRootShell(globalMnt true)区分两种会话。这正是 FAQ 所描述的「以这种方式使用」在代码层的落地——即通过su -g这类内建参数获取全局挂载命名空间能力终端内亦可配合nsenter使用。非 GKI 设备如何把 KernelSU 集成进旧内核尽管官方自 v1.0 起放弃了非 GKI 支持但 FAQ 仍指出了历史上v0.9.5 及以前的集成路径完整流程记录在 how-to-integrate-for-non-gki.md前提必须能自行从内核源码构建出可启动的内核如果内核不开源基本无法运行 KernelSU。两种集成方式自动方式kprobe将 KernelSU 加入内核源码树后确认内核配置开启CONFIG_KPROBESy CONFIG_HAVE_KPROBESy CONFIG_KPROBE_EVENTSy若 KPROBES 仍未生效可尝试开启CONFIG_MODULES或用make menuconfig排查其它依赖。集成后若出现启动循环多半是内核的 kprobe 有缺陷需修复或改用手动方式。手动方式在内核源码中按补丁指引修改四个关键函数——do_faccessat通常位于fs/open.c、do_execveat_commonfs/exec.c、vfs_readfs/read_write.c、vfs_statxfs/stat.c若不存在则改用vfs_fstatat并在 defconfig 中启用# KernelSU CONFIG_KSUy此外还包括 Safe Mode 的input_handle_event修改强烈建议启用可防止启动循环、fs/devpts/inode.c的pm命令修复、以及 5.9 以下内核path_umount的回移植保证「卸载模块」功能可用。总结FAQ 的决策树面对「KernelSU 能不能用」的问题可以按以下逻辑快速判断能解锁 Bootloader 吗不能 → 不支持。是 GKI 内核5.10吗是 → 官方支持Manager 显示Not installed即可安装。不是 GKI含 GKI 1.0、非 GKI、旧内核→ 需要自行编译内核并集成v0.9.5 及以前或使用社区非官方内核。装好之后模块不工作→ 检查模块是否修改/system若是先安装 metamodulemeta-overlayfs。想用 Zygisk/LSPosed→ 安装 ZygiskNext想与 Magisk 共存 → 只使用su且不启用 KernelSU 模块。更详细的内容可继续阅读仓库中的相关文档模块指南、metamodule 指南、与 Magisk 的差异、非 GKI 集成指南。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考