如何用 KernelSU 模块 initrc 注入在不改 /system 的情况下注册自定义 Android 服务？

如何用 KernelSU 模块 initrc 注入在不改 /system 的情况下注册自定义 Android 服务【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU如果你在开发 KernelSU 模块需要注册一个自定义的 Android init 服务例如开机后以 root 身份常驻一个守护进程又不想动/system分区模块的 initrc 注入机制就是文档给出的实现方式.rc指令在开机时被透明追加到系统init.rc由 init 按标准 Android Init 语言语法解析执行。前提条件均来自 模块指南 的说明模块必须被 KernelSU 识别且处于启用状态模块目录必须包含module.prop否则不算模块其initrc/下的.rc文件也不会被包含。设备必须运行在标准启动流程下。late-load 模式下 initrc 注入不可用因为该模式不安装相关的系统调用 hook。制作 boot 镜像时如果用 ksud 传了--no-custom-rc参数模块 RC 注入会被禁用本方案不生效。机制initrc 内容是如何进入 init.rc 的理解这条链路有助于判断每一步在做什么内核侧KernelSU 内核模块拦截read()和fstat()系统调用。当 Android init 进程读取/system/etc/init/hw/init.rc时KernelSU 把自定义 RC 内容透明地追加到文件末尾init 将这些注入指令当作原始 init.rc 的一部分解析。用户空间侧ksud 把所有已启用模块的.rc文件拼接成单个modules.rc存放在/metadata分区路径为/metadata/ksu/modules.rcRecovery 救援文档中另提到/metadata/watchdog/ksu/modules.rc。模块安装、启用、禁用、卸载等状态变化时该文件会自动重新生成。注入时机非常早发生在 init 读取 init.rc 的阶段早于post-fs-data和任何模块脚本。注入内容支持全部 Android Init 语言语法service 定义、trigger、属性设置等。也就是说/system分区从头到尾没有被修改服务定义是通过读路径注入生效的。第一步创建模块目录与 module.prop模块是放置在/data/adb/modules下、以模块 ID 命名的文件夹。module.prop是模块的元数据文件缺少它模块不会被识别。按文档格式写idstring namestring versionstring versionCodeint authorstring descriptionstring注意事项文档明确要求id必须匹配正则^[a-zA-Z][a-zA-Z0-9._-]$例如a_module、a.module、module-101合法1_module、-a-module不合法它是模块唯一标识发布后不应再改。versionCode必须是整数用于版本比较。文件必须使用UNIX (LF)换行不能用Windows (CRLF)或Macintosh (CR)。updateJson、actionIcon、webuiIcon为可选字段本文场景不需要。以模块 ID 为mymodule为例最终目录结构为/data/adb/modules/mymodule/ ├── module.prop └── initrc/ └── myservice.rc第二步编写 initrc 下的 .rc 文件在模块目录内创建initrc/子目录把你的.rc文件放进去。文档给出的完整示例——注册一个自定义服务并在sys.boot_completed1触发后启动它service myservice /data/adb/modules/mymodule/bin/myservice user root group root disabled seclabel u:r:ksu:s0 on property:sys.boot_completed1 start myservice把该文件放在/data/adb/modules/mymodule/initrc/myservice.rc。示例中的/data/adb/modules/mymodule/bin/myservice是服务二进制的路径需要替换为你自己模块 ID 和实际二进制路径disabledon property:sys.boot_completed1的组合表示服务开机时注册但不立即启动等开机完成触发器到达后由 init 启动。.rc文件的规则文件必须是.rc扩展名。只要模块启用initrc/目录下所有.rc文件都会被包含不需要可执行权限。目录内文件按文件名字母顺序处理模块之间按模块 ID 字母顺序处理。顺序敏感的服务请据此命名。可选分支——全局 initrc 目录除模块级文件外文档还允许把.rc文件放到/data/adb/initrc.d/全局目录。与模块目录不同这里的文件必须有可执行权限否则会被静默跳过且全局文件先于任何模块 RC 文件处理。模块开发场景下建议优先用模块自己的initrc/目录这样启用/禁用模块时注入随之自动增删。第三步刷新 modules.rc 并重启模块状态变化安装、启用、禁用、卸载等时 ksud 会自动重新生成modules.rc。如果你手动修改了文件、想立即触发重新拼接文档给出的命令是ksud initrc refresh注意变更在下一次开机后生效。因为注入发生在 init 读取 init.rc 的瞬间修改后必须重启才能看到服务注册结果。结果验证文档给出的成功条件是文件位于/data/adb/modules/mymodule/initrc/myservice.rc时名为myservice的服务会在开机时注册并在sys.boot_completed1到达时启动。对应的可核对产物是/metadata分区上的拼接文件/metadata/ksu/modules.rc——模块状态变化或执行ksud initrc refresh后它会被重新生成其中应包含你写入的 service 定义。限制与故障排查late-load 模式通过ksud late-load加载的内核模块在系统完全启动后才加载此模式下 initrc 注入不可用KSU_LATE_LOAD变量被设为1时即处于该模式。如果你的设备走 late-load这个方案不适用。注入被整体禁用patch 镜像时传过--no-custom-rc的话模块 RC 注入不生效。initrc 写坏导致开不了机启动循环救援文档 明确警告——如果模块在 initrc 里写了不合理的代码导致无法开机安全模式下这些代码依然会执行因为注入发生在极早阶段。文档给出的手动救援路径是进入第三方 Recovery如 TWRP挂载 data 分区可能需要先解密具体取决于设备mount /data删除 ksud 防止模块加载rm -f /data/adb/ksud此命令会删除用户空间的 ksud会导致 KernelSU 跳过所有模块加载可选挂载 metadata 分区并删除 init.rc 注入文件mount /metadata rm -f /metadata/ksu/modules.rc rm -f /metadata/watchdog/ksu/modules.rc删除后 KernelSU 开机不会加载任何模块、也不会注入自定义 RC。重启设备reboot。重启进入系统后再通过 KernelSU manager 处理模块问题。如果设备仍可通过 ADB 获得 root shell则可以直接用ksud module list、ksud module disable id或ksud module uninstall id定位并禁用/卸载问题模块再reboot无需动 Recovery。按上述路径操作后验证落点是重启后myservice服务随sys.boot_completed1触发而启动若设备因 RC 内容无法开机则按上面的救援步骤恢复后再修正.rc文件。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考