尧图网站建设 
KernelSU 与 Magisk 模块的差异详解兼容开发与实现机制深度对比【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSUKernelSU 与 Magisk 都是基于模块化机制实现 systemless 系统改动的 root 方案但由于两者在内核态与用户态的完全不同的实现架构模块在安装、挂载、脚本执行时机等方面存在诸多差异。本文以官方文档 difference-with-magisk.md 为主体结合 KernelSU 仓库中ksud用户态守护进程的源码实现系统梳理两者的相同点与差异点并给出让同一模块同时兼容 KernelSU 与 Magisk 的实战建议。读完本文你将掌握通过KSU环境变量区分运行环境、使用REMOVE/REPLACE替代.replace机制、以及理解 KernelSU 独有的post-mount与boot-completed脚本阶段等关键能力。一、KernelSU 与 Magisk 模块的相同点尽管两者实现机制截然不同但为了降低模块开发者的迁移成本KernelSU 在模块格式与约定上高度对齐 Magisk。官方文档明确列出以下相同点模块文件格式两者均使用 ZIP 压缩包组织模块模块内部的文件结构几乎一致。模块安装目录两者都安装到/data/adb/modules目录下。Systemless 机制两者都支持以无系统修改systemless的方式通过模块改动/system分区。post-fs-data.sh执行时机与语义完全一致。service.sh执行时机与语义完全一致。system.prop行为完全一致用于在开机阶段注入系统属性。sepolicy.rule行为完全一致用于追加 SELinux 策略规则。BusyBox两种环境下模块脚本都在开启了 standalone mode 的 BusyBox 中运行。从源码层面看KernelSU 的ksud在脚本执行环境中显式设置了ASH_STANDALONE1见 module.rs 中的get_common_script_envs这正是文档所述 standalone mode 的落实sh脚本通过 BusyBox 的独立模式运行保证各模块脚本行为可预期。二、如何区分模块运行在 KernelSU 还是 Magisk在模块脚本可执行的所有位置customize.sh、post-fs-data.sh、service.sh以及 KernelSU 新增的阶段脚本都可以通过环境变量KSU判断当前运行环境在 KernelSU 中该变量会被设置为true。对应源码实现在ksud的get_common_script_envs中let mut envs vec![ (ASH_STANDALONE, 1.to_string()), (KSU, true.to_string()), (KSU_KERNEL_VER_CODE, ksucalls::get_version().to_string()), (KSU_VER_CODE, defs::VERSION_CODE.to_string()), (KSU_VER, defs::VERSION_NAME.to_string()), (KSU_UAPI_VER, ksucalls::uapi_version().to_string()), (KSU_RUNTIME_MODE, ksucalls::runtime_mode().to_string()), ... ];参考 module.rs除KSUtrue外KernelSU 还会注入KSU_VER、KSU_VER_CODE、KSU_UAPI_VER、KSU_RUNTIME_MODE等版本与运行模式信息当模块通过ksud安装时还会注入KSU_MODULE模块 ID在 late load 场景下额外注入KSU_LATE_LOAD1。因此模块脚本中可以这样分支处理if [ $KSU true ]; then ui_print - Running in KernelSU else ui_print - Running in Magisk fi需要说明的是以上KSU_*系列变量的完整集合属于 KernelSU 内部实现细节官方文档仅保证KSU变量在 KernelSU 环境中为trueMagisk 环境不会设置该变量这是最稳妥的判别依据。三、核心差异总览官方文档列出的主要差异如下表所示维度KernelSUMagiskRecovery 模式安装不支持支持Zygisk 内置支持无需通过 ZygiskNext 等方案加载内置文件替换/删除方式不支持.replace使用mknod filename c 0 0或REMOVE/REPLACE变量支持.replaceBusyBox 路径/data/adb/ksu/bin/busybox/data/adb/magisk/busybox脚本阶段在post-fs-data、service基础上新增post-mount与boot-completed传统两个阶段以下对各差异逐项展开说明。3.1 Recovery 模式安装KernelSU 模块不能在 Recovery 模式下安装。KernelSU 的模块安装完全依赖ksud守护进程在 Android 系统启动完成后执行这与 Magisk 通过 Recovery 侧脚本安装的能力不同。从源码看ksud在模块安装前会显式校验系统是否已完成启动ensure_boot_completed检查sys.boot_completed属性未完成则直接bail!(Android is Booting!)见 module.rs这也印证了安装流程强依赖运行中的 Android 环境。3.2 Zygisk 支持KernelSU 模块没有内置Zygisk 支持但可以通过 ZygiskNext 等第三方实现加载 Zygisk 模块从而在 KernelSU 上使用 Zygisk 生态的模块。官方文档明确说明此差异属于 KernelSU 设计上的取舍核心保持精简能力通过生态扩展。3.3 文件替换与删除机制.replacevsmknod/REMOVE/REPLACE这是两者差异最大、也最影响模块兼容性的部分Magisk 支持在模块目录内放置.replace文件或目录来替换系统对应路径。KernelSU 不支持.replace方法。要删除屏蔽系统对应文件需要创建一个同名文件类型为字符设备节点mknod filename c 0 0同时KernelSU 提供了REMOVE与REPLACE两个变量用于在customize.sh中声明需要删除或替换的文件与目录。REMOVE/REPLACE的实现位于内置安装脚本 installer.sh# Handle replace folders for TARGET in $REPLACE; do ui_print - Replace target: $TARGET mark_replace $MODPATH$TARGET done # Handle remove files for TARGET in $REMOVE; do ui_print - Remove target: $TARGET mark_remove $MODPATH$TARGET doneksud在运行阶段会读取模块目录下的标记文件remove等见 defs.rs 的REMOVE_FILE_NAME来决定是否跳过/卸载对应模块。实战中兼容两种环境的模块通常这样写# customize.sh 片段 if [ $KSU true ]; then REMOVE /system/app/SomeApp REPLACE /system/priv-app/AnotherApp else # Magisk 使用 .replace touch $MODPATH/system/app/SomeApp/.replace fi注意REPLACE主要用于目录级替换系统会保留模块内的同名目录REMOVE用于移除路径两者语义不同使用时需按需选择。3.4 BusyBox 路径差异两个环境的 BusyBox 位置不同KernelSU/data/adb/ksu/bin/busyboxMagisk/data/adb/magisk/busybox在 KernelSU 源码中BINARY_DIR定义为${WORKING_DIR}bin/见 defs.rsBUSYBOX_PATH即${BINARY_DIR}busybox见 assets.rsksud执行模块安装与阶段脚本时统一使用该 BusyBox见 module.rs。⚠️ 官方文档特别提醒这是 KernelSU 的内部行为未来可能发生变化。因此模块脚本不应硬编码依赖该路径而应优先通过PATH环境中的busybox命令或仅将路径用于显式调用场景。3.5 KernelSU 新增的脚本阶段post-mount与boot-completed在 Magisk 传统的post-fs-data、service两阶段之外KernelSU 额外引入了两个阶段post-mount在模块挂载完成后运行。从 init_event.rs 可以看到post-fs-data阶段依次执行 metamodule 与普通模块的post-fs-data.sh、加载system.prop、执行 metamodule 挂载脚本metamount.sh之后紧跟着run_stage(post-mount, true)。该阶段为阻塞执行blocktrue适合在挂载完成后对文件系统做进一步处理。boot-completed在系统启动完成后运行。ksud会等待sys.boot_completed属性变为有效值见 init_event.rs 中reset_boot_completed/wait_for_boot_completed随后触发on_boot_completed并执行run_stage(boot-completed, false)非阻塞。阶段脚本的执行顺序由 init_event.rs 的run_stage统一调度先执行公共目录如post-mount.d、boot-completed.d中的通用脚本再执行 metamodule 的阶段脚本最后执行普通模块的阶段脚本且检测到 Magisk 存在或处于安全模式时会跳过阶段脚本避免冲突。四、架构差异的延伸模块挂载与 Metamodule虽然越南语文档主体未展开但当前仓库中英文版 difference-with-magisk.md 与 metamodule.md 补充了最重要的架构级差异在此一并说明Magisk 将模块挂载逻辑内建于核心中KernelSU 采用metamodule元模块机制把挂载能力从核心剥离到可插拔的 metamodule例如官方的meta-overlayfs中。未安装任何 metamodule 时模块不会被挂载因此全新安装 KernelSU 后需要先安装一个 metamodule如meta-overlayfs模块挂载才能生效。对应实现位于 metamodule.rsmetamodule 通过module.prop中的metamodule1标记身份并可通过metamount.sh、metainstall.sh、metauninstall.sh三个钩子接管挂载、安装与卸载逻辑。这意味着 KernelSU 的模块系统更具可扩展性但模块开发者需要理解挂载依赖 metamodule这一前提。五、兼容开发实战建议结合官方文档与源码为让模块同时兼容 KernelSU 与 Magisk建议遵循以下实践统一用KSU环境变量分支所有脚本customize.sh、post-fs-data.sh、service.sh、新增阶段脚本中都可通过[ $KSU true ]判断环境。弃用.replace改用REMOVE/REPLACE这是 KernelSU 不支持的机制迁移时必须处理。不硬编码 BusyBox 路径KernelSU 的/data/adb/ksu/bin/busybox是内部实现未来可能变动优先依赖脚本环境的PATH。利用新增阶段post-mount阶段适合依赖挂载结果的操作boot-completed阶段适合需要在系统完全启动后执行的任务如等待属性、与用户态服务交互。理解挂载前提KernelSU 环境需要安装 metamodule 模块挂载才生效若模块只运行脚本、不改动系统文件则无需 metamodule。六、总结KernelSU 与 Magisk 在模块格式和基础约定上刻意保持一致降低了模块生态的迁移成本但在 Recovery 安装、Zygisk、文件替换机制、BusyBox 路径以及脚本阶段上存在明确差异。其中最关键的三点是用KSU变量做环境判别、用REMOVE/REPLACE或mknod替代.replace、以及理解 KernelSU 的 metamodule 挂载架构与post-mount/boot-completed新增阶段。模块开发者只要围绕这些差异做兼容处理即可让同一模块稳定运行在两种 root 方案之上。相关文档与源码索引官方对比文档英文版website/docs/guide/difference-with-magisk.md元模块机制详解website/docs/guide/metamodule.md脚本环境变量注入与模块安装userspace/ksud/src/module.rs阶段脚本调度与 boot-completed 实现userspace/ksud/src/init_event.rsREMOVE/REPLACE处理逻辑userspace/ksud/src/installer.shBusyBox 路径定义userspace/ksud/src/assets.rs【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 KernelSU 与 Magisk 模块的差异详解：兼容开发与实现机制深度对比
KernelSU 与 Magisk 模块的差异详解兼容开发与实现机制深度对比【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSUKernelSU 与 Magisk 都是基于模块化机制实现 systemless 系统改动的 root 方案但由于两者在内核态与用户态的完全不同的实现架构模块在安装、挂载、脚本执行时机等方面存在诸多差异。本文以官方文档 difference-with-magisk.md 为主体结合 KernelSU 仓库中ksud用户态守护进程的源码实现系统梳理两者的相同点与差异点并给出让同一模块同时兼容 KernelSU 与 Magisk 的实战建议。读完本文你将掌握通过KSU环境变量区分运行环境、使用REMOVE/REPLACE替代.replace机制、以及理解 KernelSU 独有的post-mount与boot-completed脚本阶段等关键能力。一、KernelSU 与 Magisk 模块的相同点尽管两者实现机制截然不同但为了降低模块开发者的迁移成本KernelSU 在模块格式与约定上高度对齐 Magisk。官方文档明确列出以下相同点模块文件格式两者均使用 ZIP 压缩包组织模块模块内部的文件结构几乎一致。模块安装目录两者都安装到/data/adb/modules目录下。Systemless 机制两者都支持以无系统修改systemless的方式通过模块改动/system分区。post-fs-data.sh执行时机与语义完全一致。service.sh执行时机与语义完全一致。system.prop行为完全一致用于在开机阶段注入系统属性。sepolicy.rule行为完全一致用于追加 SELinux 策略规则。BusyBox两种环境下模块脚本都在开启了 standalone mode 的 BusyBox 中运行。从源码层面看KernelSU 的ksud在脚本执行环境中显式设置了ASH_STANDALONE1见 module.rs 中的get_common_script_envs这正是文档所述 standalone mode 的落实sh脚本通过 BusyBox 的独立模式运行保证各模块脚本行为可预期。二、如何区分模块运行在 KernelSU 还是 Magisk在模块脚本可执行的所有位置customize.sh、post-fs-data.sh、service.sh以及 KernelSU 新增的阶段脚本都可以通过环境变量KSU判断当前运行环境在 KernelSU 中该变量会被设置为true。对应源码实现在ksud的get_common_script_envs中let mut envs vec![ (ASH_STANDALONE, 1.to_string()), (KSU, true.to_string()), (KSU_KERNEL_VER_CODE, ksucalls::get_version().to_string()), (KSU_VER_CODE, defs::VERSION_CODE.to_string()), (KSU_VER, defs::VERSION_NAME.to_string()), (KSU_UAPI_VER, ksucalls::uapi_version().to_string()), (KSU_RUNTIME_MODE, ksucalls::runtime_mode().to_string()), ... ];参考 module.rs除KSUtrue外KernelSU 还会注入KSU_VER、KSU_VER_CODE、KSU_UAPI_VER、KSU_RUNTIME_MODE等版本与运行模式信息当模块通过ksud安装时还会注入KSU_MODULE模块 ID在 late load 场景下额外注入KSU_LATE_LOAD1。因此模块脚本中可以这样分支处理if [ $KSU true ]; then ui_print - Running in KernelSU else ui_print - Running in Magisk fi需要说明的是以上KSU_*系列变量的完整集合属于 KernelSU 内部实现细节官方文档仅保证KSU变量在 KernelSU 环境中为trueMagisk 环境不会设置该变量这是最稳妥的判别依据。三、核心差异总览官方文档列出的主要差异如下表所示维度KernelSUMagiskRecovery 模式安装不支持支持Zygisk 内置支持无需通过 ZygiskNext 等方案加载内置文件替换/删除方式不支持.replace使用mknod filename c 0 0或REMOVE/REPLACE变量支持.replaceBusyBox 路径/data/adb/ksu/bin/busybox/data/adb/magisk/busybox脚本阶段在post-fs-data、service基础上新增post-mount与boot-completed传统两个阶段以下对各差异逐项展开说明。3.1 Recovery 模式安装KernelSU 模块不能在 Recovery 模式下安装。KernelSU 的模块安装完全依赖ksud守护进程在 Android 系统启动完成后执行这与 Magisk 通过 Recovery 侧脚本安装的能力不同。从源码看ksud在模块安装前会显式校验系统是否已完成启动ensure_boot_completed检查sys.boot_completed属性未完成则直接bail!(Android is Booting!)见 module.rs这也印证了安装流程强依赖运行中的 Android 环境。3.2 Zygisk 支持KernelSU 模块没有内置Zygisk 支持但可以通过 ZygiskNext 等第三方实现加载 Zygisk 模块从而在 KernelSU 上使用 Zygisk 生态的模块。官方文档明确说明此差异属于 KernelSU 设计上的取舍核心保持精简能力通过生态扩展。3.3 文件替换与删除机制.replacevsmknod/REMOVE/REPLACE这是两者差异最大、也最影响模块兼容性的部分Magisk 支持在模块目录内放置.replace文件或目录来替换系统对应路径。KernelSU 不支持.replace方法。要删除屏蔽系统对应文件需要创建一个同名文件类型为字符设备节点mknod filename c 0 0同时KernelSU 提供了REMOVE与REPLACE两个变量用于在customize.sh中声明需要删除或替换的文件与目录。REMOVE/REPLACE的实现位于内置安装脚本 installer.sh# Handle replace folders for TARGET in $REPLACE; do ui_print - Replace target: $TARGET mark_replace $MODPATH$TARGET done # Handle remove files for TARGET in $REMOVE; do ui_print - Remove target: $TARGET mark_remove $MODPATH$TARGET doneksud在运行阶段会读取模块目录下的标记文件remove等见 defs.rs 的REMOVE_FILE_NAME来决定是否跳过/卸载对应模块。实战中兼容两种环境的模块通常这样写# customize.sh 片段 if [ $KSU true ]; then REMOVE /system/app/SomeApp REPLACE /system/priv-app/AnotherApp else # Magisk 使用 .replace touch $MODPATH/system/app/SomeApp/.replace fi注意REPLACE主要用于目录级替换系统会保留模块内的同名目录REMOVE用于移除路径两者语义不同使用时需按需选择。3.4 BusyBox 路径差异两个环境的 BusyBox 位置不同KernelSU/data/adb/ksu/bin/busyboxMagisk/data/adb/magisk/busybox在 KernelSU 源码中BINARY_DIR定义为${WORKING_DIR}bin/见 defs.rsBUSYBOX_PATH即${BINARY_DIR}busybox见 assets.rsksud执行模块安装与阶段脚本时统一使用该 BusyBox见 module.rs。⚠️ 官方文档特别提醒这是 KernelSU 的内部行为未来可能发生变化。因此模块脚本不应硬编码依赖该路径而应优先通过PATH环境中的busybox命令或仅将路径用于显式调用场景。3.5 KernelSU 新增的脚本阶段post-mount与boot-completed在 Magisk 传统的post-fs-data、service两阶段之外KernelSU 额外引入了两个阶段post-mount在模块挂载完成后运行。从 init_event.rs 可以看到post-fs-data阶段依次执行 metamodule 与普通模块的post-fs-data.sh、加载system.prop、执行 metamodule 挂载脚本metamount.sh之后紧跟着run_stage(post-mount, true)。该阶段为阻塞执行blocktrue适合在挂载完成后对文件系统做进一步处理。boot-completed在系统启动完成后运行。ksud会等待sys.boot_completed属性变为有效值见 init_event.rs 中reset_boot_completed/wait_for_boot_completed随后触发on_boot_completed并执行run_stage(boot-completed, false)非阻塞。阶段脚本的执行顺序由 init_event.rs 的run_stage统一调度先执行公共目录如post-mount.d、boot-completed.d中的通用脚本再执行 metamodule 的阶段脚本最后执行普通模块的阶段脚本且检测到 Magisk 存在或处于安全模式时会跳过阶段脚本避免冲突。四、架构差异的延伸模块挂载与 Metamodule虽然越南语文档主体未展开但当前仓库中英文版 difference-with-magisk.md 与 metamodule.md 补充了最重要的架构级差异在此一并说明Magisk 将模块挂载逻辑内建于核心中KernelSU 采用metamodule元模块机制把挂载能力从核心剥离到可插拔的 metamodule例如官方的meta-overlayfs中。未安装任何 metamodule 时模块不会被挂载因此全新安装 KernelSU 后需要先安装一个 metamodule如meta-overlayfs模块挂载才能生效。对应实现位于 metamodule.rsmetamodule 通过module.prop中的metamodule1标记身份并可通过metamount.sh、metainstall.sh、metauninstall.sh三个钩子接管挂载、安装与卸载逻辑。这意味着 KernelSU 的模块系统更具可扩展性但模块开发者需要理解挂载依赖 metamodule这一前提。五、兼容开发实战建议结合官方文档与源码为让模块同时兼容 KernelSU 与 Magisk建议遵循以下实践统一用KSU环境变量分支所有脚本customize.sh、post-fs-data.sh、service.sh、新增阶段脚本中都可通过[ $KSU true ]判断环境。弃用.replace改用REMOVE/REPLACE这是 KernelSU 不支持的机制迁移时必须处理。不硬编码 BusyBox 路径KernelSU 的/data/adb/ksu/bin/busybox是内部实现未来可能变动优先依赖脚本环境的PATH。利用新增阶段post-mount阶段适合依赖挂载结果的操作boot-completed阶段适合需要在系统完全启动后执行的任务如等待属性、与用户态服务交互。理解挂载前提KernelSU 环境需要安装 metamodule 模块挂载才生效若模块只运行脚本、不改动系统文件则无需 metamodule。六、总结KernelSU 与 Magisk 在模块格式和基础约定上刻意保持一致降低了模块生态的迁移成本但在 Recovery 安装、Zygisk、文件替换机制、BusyBox 路径以及脚本阶段上存在明确差异。其中最关键的三点是用KSU变量做环境判别、用REMOVE/REPLACE或mknod替代.replace、以及理解 KernelSU 的 metamodule 挂载架构与post-mount/boot-completed新增阶段。模块开发者只要围绕这些差异做兼容处理即可让同一模块稳定运行在两种 root 方案之上。相关文档与源码索引官方对比文档英文版website/docs/guide/difference-with-magisk.md元模块机制详解website/docs/guide/metamodule.md脚本环境变量注入与模块安装userspace/ksud/src/module.rs阶段脚本调度与 boot-completed 实现userspace/ksud/src/init_event.rsREMOVE/REPLACE处理逻辑userspace/ksud/src/installer.shBusyBox 路径定义userspace/ksud/src/assets.rs【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考