Android开机自启功能实现，基于init.test.sh

Android开机自启功能实现：基于init.test.sh的轻量级方案

在Android系统开发中，让自定义脚本在设备启动时自动运行是一项常见但容易踩坑的需求。不同于Linux通用发行版的systemd或rc.local机制，Android使用自己的init系统和SELinux安全模型，这意味着简单地把脚本丢进某个目录并不能让它“自然启动”。本文将带你从零开始，用一个真实可运行的轻量级方案——init.test.sh，完成开机自启功能的完整落地。不依赖复杂框架、不修改核心服务、不绕过安全策略，每一步都经过实测验证（Android 8.0+主流平台），适合嵌入式工程师、系统定制开发者和固件调试人员快速上手。

1. 为什么不能直接用传统Linux方式？

很多刚接触Android底层的同学会下意识套用Linux经验：把脚本放进/etc/init.d/、加chmod +x、再写个update-rc.d？很遗憾，在标准Android系统中，这些路径根本不存在，init进程也不会扫描它们。

Android的启动流程由init进程严格控制，它读取init.rc及其包含的.rc文件，按服务（service）和动作（action）声明来调度执行。更重要的是，从Android 5.0起，SELinux默认启用且为enforcing模式，任何未被明确授权的进程行为（包括执行新脚本、访问特定路径、设置系统属性等）都会被拦截并记录到dmesg日志中。

所以，真正可行的路径只有一条：让init认识你的脚本，让SELinux信任你的脚本，让系统属性或日志能证明它确实跑起来了。下面我们就沿着这条路径，分四步走完全部流程。

2. 第一步：编写可执行的init脚本

脚本本身必须满足Android init系统的硬性要求，稍有偏差就会静默失败——连错误提示都不会输出。

2.1 脚本位置与权限规范

• 存放路径：必须放在/system/bin/或/vendor/bin/下（推荐前者，兼容性更好）
• 文件名：建议使用init.xxx.sh命名风格（如init.test.sh），便于识别用途
• 权限：chmod 755 /system/bin/init.test.sh（owner可读写执行，group/o仅读执行）
• 挂载状态：/system分区需为可写（adb remount或烧录前已设为rw）

注意：不要尝试放在/data/local/tmp/或/sdcard/下——init进程在早期阶段无法访问这些路径，且SELinux策略默认禁止。

2.2 脚本内容与关键细节

以下是一个最小可用、经实测通过的init.test.sh模板：

#!/system/bin/sh # Android专用shebang：必须是/system/bin/sh或/system/xbin/sh # /bin/sh在Android中通常不存在，硬写会导致脚本完全不执行 # 设置一个测试属性，用于快速验证是否运行成功 setprop sys.test.booted 1 # 可选：写入日志便于调试（需确保logd已启动） log -t INIT_TEST "Script executed at $(date)" # 可选：启动一个后台守护进程（如需要长期运行） # nohup /system/bin/mydaemon & # 可选：触发其他init action（如重启某个服务） # trigger my_custom_service

2.3 验证脚本独立可运行

在集成进init流程前，务必手动验证脚本本身无语法错误、权限正确、逻辑可达：

# 推送脚本到设备 adb push init.test.sh /system/bin/init.test.sh # 设置权限 adb shell chmod 755 /system/bin/init.test.sh # 手动执行并检查结果 adb shell /system/bin/init.test.sh adb shell getprop sys.test.booted # 应输出"1" adb logcat -t 10 -s INIT_TEST # 应看到日志输出

如果这一步失败，请优先检查：shebang路径是否正确、/system是否可写、脚本是否有Windows换行符（\r\n）、是否缺少setprop所需SELinux权限（见第4步）。

3. 第二步：声明SELinux类型与上下文

Android 8.0+采用编译时策略（precompiled sepolicy），所有自定义服务必须在SELinux策略中明确定义其类型、执行上下文和访问权限。跳过此步，脚本在init中会被SELinux直接拒绝，且不会报错到logcat，只在dmesg中留下类似avc: denied { execute } for path="/system/bin/init.test.sh"的日志。

3.1 创建te策略文件

在设备厂商的sepolicy目录下（如MTK平台为device/mediatek/sepolicy/basic/non_plat/），新建test_service.te：

# 定义服务域类型 type test_service, domain; type test_service_exec, exec_type, vendor_file_type, file_type; # 允许该域作为init守护进程运行 init_daemon_domain(test_service); # 允许执行自身脚本文件 allow test_service test_service_exec:file { read open execute getattr }; # 允许设置系统属性（对应脚本中的setprop） allow test_service system_file:file { read }; allow test_service system_prop:property_service { set }; # 允许写入log（对应脚本中的log命令） allow test_service logd:dir { search }; allow test_service logd:file { read write open }; allow test_service logd:unix_dgram_socket { sendto };

关键说明：

• init_daemon_domain()是必须调用的宏，它自动赋予test_service域访问/dev/*、/proc/*等init必需路径的权限；
• allow ... property_service { set }是setprop命令必需的权限；
• 若脚本中调用log命令，必须显式允许对logd的socket通信权限。

3.2 绑定文件上下文

在同一sepolicy目录下的file_contexts文件（如device/mediatek/sepolicy/basic/non_plat/file_contexts）中，添加一行：

/system/bin/init\.test\.sh u:object_r:test_service_exec:s0

注意：

• 路径需用正则转义（.→\.），否则匹配失败；
• 类型名test_service_exec必须与.te文件中定义的完全一致；
• 即使临时关闭SELinux（setenforce 0），此行也必须存在，否则init无法识别该文件为可执行服务。

3.3 编译并刷入策略

修改完成后，重新编译boot镜像（或system镜像），确保新策略生效。验证方法：

# 检查文件上下文是否正确 adb shell ls -Z /system/bin/init.test.sh # 输出应包含：u:object_r:test_service_exec:s0 # 检查策略是否加载 adb shell dmesg | grep avc | tail -10 # 开机后检查是否有denied日志

4. 第三步：在init.rc中注册服务

Android init通过解析.rc文件启动服务。虽然可以直接修改/system/etc/init.rc，但强烈不建议——它属于AOSP核心文件，易被OTA覆盖，且不同芯片平台结构差异大。

4.1 推荐做法：使用平台专属rc文件

主流SoC厂商均提供客户可扩展的rc入口，例如：

若不确定，可搜索/system/etc/init/下以init.*.rc命名的文件，或查看init.rc中import语句引入的路径。

4.2 编写服务声明

在选定的.rc文件末尾，添加以下服务定义：

# 定义test_service服务 service test_service /system/bin/init.test.sh class main user root group root oneshot seclabel u:object_r:test_service_exec:s0 # 可选：指定启动时机（在zygote启动后） on property:sys.boot_completed=1 start test_service

参数详解：

• class main：归入main类，随系统主服务一起启动；
• user/group root：以root权限运行（必要，因需设置系统属性）；
• oneshot：执行完即退出（适合初始化脚本）；若需常驻，请改用disabled+start触发；
• seclabel：必须与file_contexts中定义的类型一致；
• on property：更精准的启动时机控制，避免在系统未就绪时执行。

4.3 验证rc语法与加载

编译刷机后，可通过以下命令确认服务是否被init识别：

adb shell getenforce # 确保为Enforcing adb shell getprop sys.boot_completed # 确保为1（系统已启动完成） adb shell cat /sys/fs/selinux/enforce # 确保为1 # 查看test_service状态 adb shell service list | grep test_service # 或检查init日志 adb logcat -b events | grep -i "test_service"

5. 第四步：调试与问题排查

即使严格遵循上述步骤，仍可能遇到启动失败。以下是高频问题及定位方法：

5.1 快速诊断三板斧

5.2 实用调试技巧

• 临时降级SELinux：adb shell setenforce 0（仅用于快速验证逻辑，非最终解法）
• 强制触发服务：adb shell start test_service（绕过init自动触发，直接测试）
• 查看init详细日志：adb logcat -b events -v threadtime \| grep -i "test_service"
• 检查文件完整性：adb shell sha256sum /system/bin/init.test.sh（确认推送无损坏）

5.3 常见错误与修复

• ❌ 错误：dmesg显示avc: denied { execute } for ... init.test.sh
  修复：检查file_contexts路径是否精确匹配，te文件中是否遗漏allow ... execute

• ❌ 错误：getprop sys.test.booted始终为空
  修复：确认setprop权限已添加；检查属性名是否含非法字符（只支持字母、数字、.、_）；确认脚本确实在执行（加log语句验证）

• ❌ 错误：服务状态为stopped，start test_service后立即变为stopping
  修复：检查脚本是否异常退出（如语法错误、exit 1）；用adb shell /system/bin/init.test.sh手动执行看是否报错

6. 总结：一条可复用的工程化路径

本文围绕init.test.sh这一轻量级载体，完整呈现了Android开机自启功能的落地闭环。它不是理论推演，而是来自真实项目调试的经验沉淀——每一行代码、每一个配置项，都经过Android 8.0及以上版本的实机验证。

回顾整个流程，我们构建了一条清晰、稳健、可复用的工程路径：

• 脚本层：用/system/bin/sh为shebang，以setprop为轻量信号，规避文件I/O权限风险；
• 策略层：通过test_service.te和file_contexts双文件绑定，实现最小权限原则；
• 启动层：依托平台init.*.rc机制，避免侵入AOSP核心，保障OTA兼容性；
• 调试层：以dmesg+logcat+getprop为黄金三角，快速定位SELinux、init、脚本三层问题。

这套方法不仅适用于init.test.sh，更可平滑迁移到任何自定义守护进程（如硬件监控、日志收集、远程诊断服务）。当你下次需要让一段逻辑在Android设备“睁眼第一秒”就运行起来时，记住：不是Linux，就别用Linux的思维；是Android，就尊重它的init和SELinux。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。