想让App开机自启？先搞懂这个shell脚本原理（实测）
在Android系统开发中，实现某个功能或服务的开机自启动是一个常见需求。比如你希望某个后台服务自动拉起、某个配置文件在系统启动时被写入，或者你的应用需要在系统就绪后第一时间运行——这些都可以通过一个简单的shell脚本 + init机制来完成。
但很多人一上来就想“怎么让App开机启动”，却忽略了底层真正的执行逻辑：脚本能不能跑起来？权限够不够？SELinux会不会拦截？系统服务有没有正确注册？
本文以真实项目经验为基础，结合实际测试过程，带你一步步搞懂Android 8.0环境下如何编写并部署一个能真正生效的开机启动shell脚本。我们不讲空理论，只讲你能在设备上亲手验证的内容。
1. 开机启动的本质：init进程与service管理
Android系统的启动流程始于init进程，它是用户空间的第一个进程（PID=1），负责解析init.rc及其包含的其他.rc文件，并根据其中定义的服务（service）来启动各种系统组件。
我们要做的开机启动脚本，本质上就是向这个机制中注册一个一次性执行的服务（oneshot service），由init在特定时机调用它。
关键点：
- 脚本必须被
init识别为可执行服务 - 脚本路径需符合系统安全策略
- 必须处理SELinux权限问题
- 推荐使用属性设置等方式验证执行结果，避免因文件操作权限导致失败
2. 编写开机启动shell脚本
我们先创建一个最简单的shell脚本，用于验证是否成功执行。
### 2.1 创建脚本文件init.test.sh
#!/system/bin/sh # 设置一个系统属性，用于后续检测脚本是否运行 setprop test.boot.script.executed true # 可选：输出日志到logcat，便于调试 log -t "BootScript" -p i "Init test script is running!" # 示例：可以在这里添加你需要的操作 # mkdir /data/local/tmp/mydir # echo "hello" > /data/local/tmp/test.txt注意：
- 第一行
#!/system/bin/sh是关键，不能写成/bin/sh，否则在Android设备上可能无法找到解释器。- 使用
setprop设置属性是最轻量、最安全的验证方式，不会涉及复杂权限。log命令可将信息输出到logcat，方便通过adb logcat | grep BootScript查看执行情况。
### 2.2 脚本存放位置和权限设置
通常我们将脚本放在以下两个位置之一：
/system/bin/init.test.sh/vendor/bin/init.test.sh
推荐使用/vendor/bin/，因为这是厂商扩展区域，不容易和系统升级冲突。
设置正确权限：
chmod 755 init.test.sh确保所有者是root:root。
你可以先手动 push 到设备测试：
adb push init.test.sh /vendor/bin/ adb shell chmod 755 /vendor/bin/init.test.sh adb shell sh /vendor/bin/init.test.sh adb shell getprop test.boot.script.executed如果返回true，说明脚本本身没问题。
3. 在init.rc中注册服务
接下来要告诉init进程：“请在启动时运行这个脚本”。
### 3.1 添加service定义
不要直接修改主init.rc，而是查找是否有平台提供的扩展.rc文件，例如：
init.mtk.rc（MTK平台）init.qcom.rc（高通平台）- 或者你自己项目的
init.project.rc
在对应的.rc文件中添加如下内容：
service test_boot_script /vendor/bin/init.test.sh class main user root group root oneshot disabled seclabel u:r:test_service:s0字段说明：
oneshot：表示只执行一次，适合初始化脚本disabled：防止被自动启动，我们会在合适时机用trigger激活seclabel：指定SELinux上下文，必须与te文件匹配
### 3.2 触发服务执行
你可以在系统就绪后触发该脚本，比如当sys.boot_completed=1时：
on property:sys.boot_completed=1 start test_boot_script或者如果你想更早执行（如zygote启动前），可以用：
on early-init start test_boot_script具体时机根据你的需求调整。
4. 处理SELinux权限（关键步骤）
即使脚本能手动执行，在开机时也可能被SELinux阻止。这是最常见的“脚本没反应”原因。
我们需要为这个服务添加SELinux策略。
### 4.1 创建.te策略文件
假设你使用的是MTK平台，建议在以下路径新建文件：
device/mediatek/sepolicy/basic/non_plat/test_service.te内容如下：
type test_service, coredomain; type test_service_exec, exec_type, file_type; init_daemon_domain(test_service) # 如果需要访问某些资源，再逐步添加 # allow test_service sysfs:file { read write }; # allow test_service system_file:dir search;### 4.2 配置 file_contexts
为了让init能够加载这个可执行文件，必须在file_contexts中声明其安全上下文。
编辑文件：
device/mediatek/sepolicy/basic/non_plat/file_contexts添加一行：
/vendor/bin/init\.test\.sh u:object_r:test_service_exec:s0这表示：当你执行/vendor/bin/init.test.sh时，SELinux会将其标记为test_service_exec类型，并关联到test_service域。
5. 编译烧录与实测验证
完成上述步骤后，进行完整编译并烧录镜像。
### 5.1 验证方法
重启设备后，使用adb命令检查：
adb shell getprop test.boot.script.executed预期输出：
true查看日志：
adb logcat | grep BootScript应能看到类似输出：
BootScript I Init test script is running!如果你什么都没看到，说明脚本未执行，可能是以下原因：
| 问题 | 检查方法 |
|---|---|
| 脚本路径错误 | ls /vendor/bin/init.test.sh |
| 权限不足 | ls -l /vendor/bin/init.test.sh应为rwxr-xr-x |
| SELinux拒绝 | `adb logcat |
| .rc语法错误 | `dmesg |
| 服务未触发 | 检查trigger条件是否满足 |
6. 常见问题与避坑指南
### 6.1 脚本明明存在却不执行？
很可能是SELinux拦截了。即使你关闭了SELinux（setenforce 0），某些强制规则仍可能生效。务必添加.te策略和file_contexts映射。
### 6.2 修改.rc文件无效？
注意.rc文件的加载顺序。有些平台只加载特定命名的.rc文件。确认你的.rc是否被import导入了主配置。
例如在init.rc中应有：
import /init.project.rc### 6.3 属性设置了但读不到？
确保属性名符合规范：
- 不能太长（最多31字符）
- 不能包含非法字符
- 推荐前缀为
persist.或sys.（如果是持久化）
也可以改用persist.test.ran=1来验证：
setprop persist.test.ran 1然后重启两次看是否保留。
### 6.4 如何调试没有串口的设备？
可以通过写临时文件+logcat双保险：
echo "script ran at $(date)" > /data/local/tmp/boot_log.txt log -t "BootScript" -p i "Script executed successfully"7. 进阶技巧：让App真正实现“开机自启”
虽然我们目前只是运行了一个shell脚本，但它完全可以作为“启动App”的桥梁。
### 7.1 启动前台Activity
am start -n com.example.myapp/.MainActivity### 7.2 启动后台Service
am startservice -n com.example.myapp/.BootService### 7.3 发送广播（需动态注册除外）
am broadcast -a android.intent.action.BOOT_COMPLETED --ei extra_source 9527注意：从Android 8.0开始，后台限制变严格，很多隐式广播不再发送。建议结合
JobScheduler或WorkManager做兼容处理。
8. 总结
通过本次实测，我们完整走通了Android 8.0环境下shell脚本开机自启的全流程。这不是一个简单的“加个命令就行”的功能，而是一套涉及init机制、SELinux、权限控制、系统服务调度的综合工程实践。
### 8.1 核心要点回顾
- 脚本必须放在
/vendor/bin/或/system/bin/ - 第一行解释器路径必须准确：
#!/system/bin/sh - 在
.rc文件中注册为oneshot服务，并设置正确的seclabel - 必须添加SELinux策略（
.te+file_contexts） - 使用
setprop和log做轻量级验证，避免权限干扰 - 通过
on property:触发服务，控制执行时机
### 8.2 实际价值
这套方案适用于：
- 设备出厂预配置
- 自动化测试环境初始化
- 第三方服务注入
- 特定硬件模块唤醒
- 替代复杂JNI层操作
只要你想在系统启动阶段做点事，这个shell脚本机制就是最直接、最可控的方式。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
