为什么脚本不执行？Android开机启动常见问题
在Android系统开发中，让自定义脚本随系统启动自动运行看似简单，实则暗藏多个关键陷阱。很多开发者遇到“脚本写好了、rc文件改了、也push进去了，但开机后属性没设、日志没打、文件没生成——脚本就像没存在过一样”。这不是代码逻辑错了，而是被几个隐蔽却致命的环节卡住了。
本文聚焦真实工程场景，不讲抽象理论，只说你正在踩的坑：为什么脚本明明存在却完全不执行？从Shell解释器路径、SELinux策略、init.rc语法细节，到调试验证的最小闭环方法，全部基于实测经验整理。所有操作均在Android 8.0+主流平台（包括高通、MTK）验证通过，适用于“测试开机启动脚本”这类轻量级镜像的快速验证与排障。
1. 第一关：Shell解释器路径写错，脚本根本不会被加载
很多人复制Linux脚本直接改个名字就往Android里放，结果第一行#!/bin/sh成了最大障碍。
1.1 Android和Linux的Shell路径完全不同
- 正确路径（Android系统分区）：
/system/bin/sh—— 大多数AOSP设备默认使用/system/xbin/sh—— 部分定制ROM或带busybox的设备- 错误路径（Linux习惯，Android上会静默失败）：
/bin/sh/usr/bin/sh#!/sh
关键提示：
#开头的行不是注释，是shebang机制的硬性声明。内核在fork进程时会严格按这个路径去加载解释器。路径不存在 → 进程启动失败 → 脚本一行都不执行，连log都看不到。
1.2 验证方法：不依赖开机，先手动跑通
在push脚本后，务必执行这三步验证：
adb root adb remount adb push init.test.sh /system/bin/ adb shell chmod 755 /system/bin/init.test.sh adb shell /system/bin/init.test.sh # 直接调用，看是否报错如果输出类似/system/bin/sh: can't execute '/system/bin/init.test.sh': No such file or directory，说明shebang路径错误；如果是Permission denied，则是权限或SELinux拦截；只有成功返回且adb shell getprop test.prop能查到值，才代表脚本本身可执行。
2. 第二关：SELinux策略缺失，脚本被静默拒绝
Android 5.0之后默认启用SELinux enforcing模式。即使你把脚本放在/system/bin/，没有对应策略，init进程也无法以test_service身份执行它。
2.1 策略文件必须成对出现
仅写.te文件远远不够，必须同时配置三处：
| 文件位置 | 文件名 | 关键内容 | 作用 |
|---|---|---|---|
device/xxx/sepolicy/basic/non_plat/ | test_service.te | type test_service_exec, exec_type, vendor_file_type;init_daemon_domain(test_service); | 声明服务类型与执行域关系 |
device/xxx/sepolicy/basic/non_plat/file_contexts | file_contexts | /(system\/vendor|vendor)\/bin\/init\.test\.sh u:object_r:test_service_exec:s0 | 将脚本文件打上正确安全上下文标签 |
init.rc或init.xxx.rc | service定义块 | seclabel u:object_r:test_service_exec:s0 | 明确指定该service使用此标签启动 |
注意：
file_contexts中的正则表达式必须精确匹配你的脚本路径。例如脚本放在/system/bin/，就写/system/bin/init\.test\.sh；若放在/vendor/bin/，则需对应修改。路径不匹配 → 标签打不上 → SELinux拒绝执行。
2.2 快速验证SELinux是否拦截
开机后立即执行：
adb shell dmesg | grep avc # 或 adb shell cat /proc/kmsg | grep avc如果看到类似以下日志，就是SELinux拦截：
avc: denied { execute } for path="/system/bin/init.test.sh" dev="dm-0" ino=123456 scontext=u:r:init:s0 tcontext=u:object_r:shell_data_file:s0 tclass=file permissive=0此时tcontext显示的是文件当前标签（shell_data_file），而非你期望的test_service_exec，说明file_contexts未生效或路径不匹配。
3. 第三关：init.rc语法细节出错，service根本未注册
init.rc不是普通脚本，它是Android init进程解析的配置语言，对空格、缩进、换行极其敏感。
3.1 最易忽略的四个语法雷区
| 错误写法 | 正确写法 | 后果 |
|---|---|---|
service test_service /system/bin/init.test.shclass mainuser root | service test_service /system/bin/init.test.shclass mainuser root | 缩进必须是4个空格，不能用Tab，否则整段service被忽略 |
oneshot写在seclabel后面 | oneshot必须在seclabel之前 | 属性顺序错误 → 解析失败，service不注册 |
路径含空格：/system/bin/ init.test.sh | /system/bin/init.test.sh | 路径中多一个空格 → init认为命令是/system/bin/，参数是init.test.sh，执行失败 |
on property:sys.boot_completed=1放在service块内 | on property:sys.boot_completed=1必须独立成段，不能嵌套 | 触发条件失效，脚本永不执行 |
3.2 推荐写法：用标准模板，避免手写错误
# 在 init.xxx.rc 中添加（不要动 init.rc 原文件） service test_service /system/bin/init.test.sh class main user root group root oneshot seclabel u:object_r:test_service_exec:s0 # 单独触发段（确保系统完全就绪后再运行） on property:sys.boot_completed=1 start test_service
oneshot表示执行完即退出，适合一次性初始化任务；on property:sys.boot_completed=1是最稳妥的触发时机，比early-init或late-init更可靠；
所有行首缩进统一为4空格，无Tab混入。
4. 第四关：脚本内部逻辑被静默终止
即使前三个环节全对，脚本也可能因内部问题“执行了但没效果”。
4.1 Android Shell环境限制多，不是所有命令都能用
source xxx.sh、.命令在Android/system/bin/sh中不支持；$(command)命令替换在旧版mksh中可能失败，优先用反引号`command`；echo -n的-n参数在部分ROM中无效，换行用printf更稳妥；- 所有路径必须用绝对路径：
/system/bin/log而非log； - 设置属性必须用
setprop，不能用export（后者只在当前shell有效）。
4.2 推荐最小化健壮脚本模板
#!/system/bin/sh # init.test.sh - 开机启动测试脚本（已验证Android 8.0+） # 1. 记录启动时间（验证是否执行） /system/bin/log -t TEST_INIT "Starting at $(/system/bin/date)" # 2. 设置测试属性（最简验证点） setprop test.prop "booted_$(/system/bin/date +%s)" # 3. 创建标记文件（验证文件系统可写） /system/bin/touch /data/local/tmp/test_init_done /system/bin/chmod 644 /data/local/tmp/test_init_done # 4. 写入日志（验证log功能） printf "Init script executed successfully at %s\n" "$(/system/bin/date)" > /data/local/tmp/test_init.log # 5. 清理临时变量（可选） unset i j k每行都加注释，便于快速定位哪一步失败；
所有命令用绝对路径，避免PATH不可靠；
关键动作后加log -t，方便adb logcat -s TEST_INIT实时追踪；
使用/data/local/tmp/而非/tmp/（Android中/tmp常为内存挂载，重启丢失）。
5. 第五关：调试闭环不完整，无法定位真实失败点
很多开发者只看getprop或ls，却漏掉最关键的两层日志。
5.1 五步闭环调试法（推荐顺序执行）
| 步骤 | 命令 | 判断依据 | 说明 |
|---|---|---|---|
| 1. 查init是否识别service | adb shell getenforceadb shell ls -Z /system/bin/init.test.sh | Enforcing+u:object_r:test_service_exec:s0 | 确认SELinux状态与文件标签正确 |
| 2. 查service是否注册 | `adb shell getprop | grep init.svc.test_service` | 输出stopped或running |
| 3. 查是否触发启动 | `adb logcat -b events | grep boot_completed` | 看到boot_completed=1事件 |
| 4. 查脚本是否被调用 | adb logcat -s TEST_INIT | 看到Starting at ...日志 | 确认脚本第一行已执行 |
| 5. 查最终效果 | adb shell getprop test.propadb shell ls -l /data/local/tmp/test_init* | 属性值存在 + 文件存在 | 确认脚本逻辑完整走通 |
5.2 一个真实排障案例
现象：
getprop test.prop始终为空，logcat -s TEST_INIT无输出
排查：
- Step1：
ls -Z显示标签是shell_data_file→file_contexts路径写错，应为/system/bin/init\.test\.sh而非/system/bin/init.test.sh（少转义点）- Step2：修正后重编译烧写，
getprop init.svc.test_service仍无输出- Step3：
logcat -b events发现boot_completed=1已触发 → 触发正常- Step4：检查
init.xxx.rc，发现seclabel行缩进用了Tab → 整个service块被忽略- 修复缩进后，
getprop init.svc.test_service显示running，日志立即出现
这就是典型的“多层拦截”，必须逐层验证，不能跳步。
6. 总结：开机脚本执行失败的五大根因与应对清单
真正让脚本“不执行”的，从来不是某一行代码写错，而是整个启动链路上某个环节彻底断开。根据上百次实测排障经验，我们归纳出最常发生的五类根因，并给出可立即执行的检查清单：
6.1 根因清单与速查表
| 根因类别 | 典型表现 | 一句话诊断命令 | 立即修复建议 |
|---|---|---|---|
| Shell路径错误 | dmesg无avc日志，logcat无任何输出，手动执行报No such file or directory | adb shell ls -l /system/bin/sh | 改shebang为#!/system/bin/sh，重新push |
| SELinux标签缺失 | dmesg大量avc denied日志，ls -Z显示非test_service_exec | adb shell ls -Z /system/bin/init.test.sh | 检查file_contexts正则，确认路径转义，重刷sepolicy |
| init.rc语法错误 | getprop init.svc.test_service无输出，logcat -b events有boot_completed | adb shell cat /proc/last_kmsg | grep test_service | 检查缩进（4空格）、oneshot位置、路径空格，用标准模板重写 |
| 触发时机不当 | 脚本执行但/data未挂载，导致touch失败 | `adb shell getprop | grep vold.decrypt` |
| 脚本内部命令失效 | log -t有输出，但setprop不生效，touch失败 | adb shell /system/bin/sh -x /system/bin/init.test.sh | 替换source为.（若支持），用printf替代echo -n，所有路径绝对化 |
6.2 给新手的三条铁律
铁律一：永远先手动验证，再依赖开机
adb shell /system/bin/init.test.sh能跑通，才是脚本正确的起点；否则一切优化都是空中楼阁。铁律二：日志是唯一真相，不要猜
dmesg | grep avc看SELinux，logcat -s TEST_INIT看脚本，getprop init.svc.xxx看service状态——三者结合，99%问题可定位。铁律三：用最小闭环验证每一步
不要一上来就写100行脚本。先写setprop test.prop 1，验证能设置属性；再加log -t，验证能打日志；最后加文件操作。层层递进，稳扎稳打。
当你下次再遇到“脚本不执行”，请打开这篇清单，按顺序执行五步闭环。你会发现，所谓玄学问题，不过是几个确定性极强的工程细节没对齐而已。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
