KernelSU 模块与 Magisk 模块的异同对比与双平台兼容开发指南【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSUKernelSU 与 Magisk 的模块机制在文件格式、安装目录和核心脚本语义上高度一致但底层实现机制截然不同导致文件替换、挂载架构、BusyBox 路径与生命周期脚本等方面存在显著差异。本文以官方《KernelSU 模块与 Magisk 的差异》文档为骨架结合 模块开发指南 与 ksud 用户空间源码逐条剖析相同点与差异点帮助你写出能够在两个平台无缝运行的模块。相同之处为什么你的模块可以一次编写双端运行KernelSU 在设计之初就刻意保持了与 Magisk 模块的高度兼容性两者的相同点如下模块文件格式都以 ZIP 方式组织模块模块内部的目录结构与关键文件module.prop、system/、各类脚本几乎相同模块安装目录都安装在/data/adb/modules下每个模块一个以模块 ID 命名的文件夹systemless都支持通过模块以 systemless 方式修改/system即不物理改动系统分区、仅在运行时叠加修改post-fs-data.sh执行时机完全一致语义完全一致service.sh执行时机完全一致语义完全一致system.prop文件格式与行为完全相同均以[key][value]形式在启动时生效sepolicy.rule规则文件格式与加载语义完全相同BusyBox脚本都在 BusyBox 中以独立模式Standalone Mode运行命令集可预测、不依赖 PATH。正因为如此模块开发指南 明确指出如果你熟悉 Magisk 模块开发开发 KernelSU 模块大同小异只需额外了解两者的异同即可。值得一提的是 BusyBox 兼容性的进一步保障从源码注释看KernelSU 的 BusyBox 直接使用 Magisk 项目编译的二进制文件两者完全一样因此你完全不必担心脚本在两个平台间的 BusyBox 兼容问题。如何区分运行环境KSU环境变量的使用在所有可以运行模块脚本的地方customize.sh、post-fs-data.sh、service.sh、post-mount.sh、boot-completed.sh等都可以通过环境变量KSU来区分当前运行在 KernelSU 还是 Magisk在 KernelSU 中该变量会被设置为true。这一行为在 ksud 源码中有明确实现。module.rs 中的get_common_script_envs函数为所有脚本统一注入了如下环境变量(ASH_STANDALONE, 1.to_string()), (KSU, true.to_string()), (KSU_KERNEL_VER_CODE, ...), (KSU_VER_CODE, ...), (KSU_VER, ...), (KSU_UAPI_VER, ...), (KSU_RUNTIME_MODE, ...),典型的判别写法if [ $KSU true ]; then # 当前运行在 KernelSU ui_print Running on KernelSU else # 当前运行在 Magisk ui_print Running on Magisk fi需要注意MAGISK_VER_CODE在 KernelSU 中恒为25200MAGISK_VER恒为v25.2见 installer.sh 的导出逻辑因此不要通过这两个变量来判断环境请一律使用KSU。不同之处逐条剖析以下差异如果要在双平台兼容模块中处理务必逐条落实。1. 不支持在 Recovery 中安装KernelSU 模块只能在系统启动后即 KernelSU Manager 或 ksud 在线安装安装不支持Recovery 模式刷入。相应地customize.sh中与 Recovery 相关的变量如OUTFD、recovery_actions等在 KernelSU 中基本无意义BOOTMODE变量在 KernelSU 中永远为true。2. 没有内置 Zygisk 支持KernelSU 模块系统没有内置 Zygisk。如果需要运行 Zygisk 模块需借助 ZygiskNext 之类的第三方方案。在 模块开发指南 中同样说明通过 ZygiskNext 使用 Zygisk 模块时其内容与 Magisk 所支持的 Zygisk 完全一致因此这一差异对写一次、两端跑的影响很小。3. 模块挂载架构metamodule 系统 vs 内置挂载这是两者最核心的架构差异Magisk将挂载逻辑内置在核心中安装即用KernelSU采用 metamodule 系统将挂载委托给可插拔的 metamodule官方参考实现为meta-overlayfs。KernelSU 需要先安装 metamodule 才能启用模块挂载。metamodule 在 ksud 中的实现位于 metamodule.rs其核心职责包括识别module.prop中metamodule1的模块is_metamodule函数、维护/data/adb/metamodule - /data/adb/modules/id符号链接ensure_symlink、在安装/卸载/挂载阶段调用元模块的钩子脚本metainstall.sh、metauninstall.sh、metamount.sh。启动时挂载流程的源码佐证见 init_event.rsksud 先执行元模块的post-fs-data.sh再执行常规模块的post-fs-data.sh随后加载system.prop最后调用metamodule::exec_mount_script执行metamount.sh完成模块挂载之后才进入post-mount阶段。从源码结构可以推断未安装 metamodule 时依赖system目录的挂载型模块将不会生效但纯脚本类模块、sepolicy.rule、system.prop等无需 metamodule 即可工作。4. 删除与替换文件的方式完全不同.replacevsmknod/REMOVE/REPLACEMagisk 通过.replace文件机制删除/替换系统文件而 KernelSU不支持.replace改为以下两种方式删除文件通过mknod filename c 0 0创建同名 char 设备节点whiteoutoverlayfs 会将其视为删除标记mknod $MODPATH/system/app/YouTube c 0 0批量删除在customize.sh中声明REMOVE变量每行一个路径REMOVE /system/app/YouTube /system/app/Bloatware installer 会为每个目标自动执行mknod其实现见 installer.sh 的mark_remove函数以及安装流程末尾对$REMOVE的循环处理install_module中for TARGET in $REMOVE段。替换目录在模块目录创建同名目录并设置 opaque 属性setfattr -n trusted.overlay.opaque -v y $MODPATH/system/app/YouTube批量替换在customize.sh中声明REPLACE变量REPLACE /system/app/YouTube /system/app/Bloatware installer 会为每个目标自动创建目录并设置 opaque 属性对应install_module中for TARGET in $REPLACE段调用mark_replace替换后系统原目录将变为空目录。从源码可以确认REMOVE/REPLACE的处理发生在customize.sh被 source 之后installer.sh因此你可以在customize.sh中按需动态构造这两个变量。5. BusyBox 目录不同KernelSU/data/adb/ksu/bin/busyboxMagisk/data/adb/magisk/busybox注意这是 KernelSU 的内部行为未来可能更改。因此模块脚本不要硬编码 BusyBox 路径而是直接依赖所有脚本都在 BusyBox ash 中以独立模式运行这一保证即可。ksud 执行所有模块脚本时都通过assets::BUSYBOX_PATH定位 BusyBox 并以sh解释执行见 module.rs并统一设置ASH_STANDALONE1。6. 新增脚本post-mount.sh与boot-completed.sh除 Magisk 已有的post-fs-data.sh、service.sh之外KernelSU 新增了两个生命周期阶段post-mount.sh在模块挂载完成后运行。ksud 在exec_mount_script完成 metamodule 挂载后调用run_stage(post-mount, true)init_event.rs该阶段会依次执行/data/adb/post-mount.d/通用脚本需可执行权限、元模块与常规模块的post-mount.shboot-completed.sh在 Android 系统启动完成ACTION_BOOT_COMPLETED后运行。ksud 通过on_boot_completed调用run_stage(boot-completed, false)init_event.rs非阻塞执行。从run_stage的实现init_event.rs可以看出统一的执行顺序通用.d脚本 → 元模块脚本 → 常规模块脚本且post-fs-data阶段为阻塞执行service、boot-completed阶段为非阻塞并行执行。对应的完整启动流程含各阶段脚本执行时机可参考 模块开发指南的启动脚本流程其中详细列出了从 Bootloader 到用户可操作界面之间 KernelSU 每个阶段的介入点。双平台兼容开发要点速查综合以上差异为同时兼容 Magisk 与 KernelSU模块开发者应遵循以下要点用KSU环境变量而非MAGISK_VER判断运行环境源码依据见 module.rs不要使用.replace文件KernelSU 不识别它。如需删除/替换使用REMOVE/REPLACE变量Magisk 同样支持这两个变量可放心使用或在customize.sh中按KSU分支分别处理不要硬编码 BusyBox 路径/data/adb/ksu/bin/busybox为内部行为可能变更直接依赖脚本的独立模式运行环境post-mount.sh与boot-completed.sh是 KernelSU 专有如果想让这类脚本在 Magisk 上同样生效需要在脚本内部做降级处理例如用service.sh检测系统状态代替挂载依赖 metamodule如果模块包含system目录请在文档中提示用户安装meta-overlayfs否则挂载不生效纯脚本模块则无此要求模块 ID 命名需满足^[a-zA-Z][a-zA-Z0-9._-]$正则见 module.rs 的validate_module_id以保证两个平台都能正确识别。延伸阅读模块开发指南模块目录结构、module.prop格式、启动脚本完整流程与 late-load 模式元模块指南metamodule 架构、钩子脚本与meta-overlayfs参考实现模块配置文档模块内置键值配置系统模块 WebUI 文档模块交互界面安装器源码installer.sh模块安装、权限设置、REMOVE/REPLACE处理生命周期源码init_event.rs、module.rs、metamodule.rs【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考