oneshot服务是什么？Android开机脚本必知
在Android系统开发中，经常需要让某些程序或脚本在设备启动时自动运行。但你是否遇到过这样的问题：脚本明明写好了、权限也加了、init.rc里也注册了，可开机后一查——属性没设上、文件没生成、服务根本没执行？这时候，你大概率忽略了oneshot这个关键词背后的关键逻辑。
本文不讲抽象概念，不堆砌术语，只说清楚三件事：
oneshot到底是什么，它和普通服务有什么本质区别；- 为什么你的开机脚本“看似配置完整却始终不执行”；
- 如何用最简方式验证、调试并真正跑通一个开机启动的shell脚本。
全文基于真实MTK平台实测（Android 8.0+），所有步骤已在量产项目中验证通过，不依赖ADB日志、不强求串口，小白也能照着操作成功。
1. oneshot不是开关，而是一种生命周期约定
很多人把oneshot理解成“只运行一次”，这没错，但远远不够。它真正的含义是：该服务一旦退出（无论成功或失败），init进程就认为任务已完成，不再重启、不持续监控、不重试。
这和disabled、manual、默认服务有本质区别：
| 启动类型 | 是否自动启动 | 进程退出后行为 | 典型用途 |
|---|---|---|---|
| 默认（无标记） | 是 | 自动重启，保持常驻 | zygote、surfaceflinger等核心守护进程 |
disabled | 否 | 不启动，需手动触发 | 临时禁用某服务 |
manual | 否 | 需显式start <name>触发 | 调试用、按需启动的服务 |
oneshot | 是 | 立即标记为完成，永不重启 | 初始化脚本、一次性配置、属性设置 |
关键提醒：如果你的脚本里只写了
setprop test.prop 111然后就退出，那它确实执行了——只是太快，快到你还没来得及getprop就结束了。这不是没运行，而是“运行完就收工”。
所以，oneshot服务不是“容易失效”，而是“极其诚实”：它严格按你写的逻辑走，不帮你兜底，也不替你等待。
2. 开机脚本四步落地，缺一不可
很多开发者卡在第三步或第四步，其实问题往往出在第一步的细节里。下面以init.test.sh为例，拆解每个环节的真实要点。
2.1 写shell脚本：路径、解释器、退出逻辑全要对
新建init.test.sh，内容如下：
#!/system/bin/sh # 注意：Android必须用 /system/bin/sh 或 /system/xbin/sh # Linux的 /bin/sh 在Android上通常不存在，硬写会导致静默失败 # 设置一个测试属性（推荐方式，避免文件权限问题） setprop test.oneshot.status "started" # 模拟一点耗时操作（可选，用于观察执行时机） sleep 1 # 再设一个确认属性 setprop test.oneshot.status "done" # 必须显式退出，且返回码为0（非0会被init视为失败） exit 0实操要点：
#!/system/bin/sh必须顶格、无空格、无BOM；- 所有命令必须在Android环境存在（如
sleep、setprop都OK，但curl、jq不一定）； - 最后一定要
exit 0，否则init可能记录service 'test_service' exited with status 1； - 不要创建文件、不要修改系统分区——初期调试阶段，一切以
setprop为准，规避SELinux和权限干扰。
小技巧：写完先
adb push init.test.sh /data/local/tmp/ && adb shell chmod +x /data/local/tmp/init.test.sh && adb shell /data/local/tmp/init.test.sh，手动执行看是否报错。能手动跑通，才具备开机执行基础。
2.2 为脚本写te策略：不是复制粘贴，而是精准授权
新建test_service.te，内容如下：
# 定义服务域类型 type test_service, coredomain; # 定义可执行文件类型 type test_service_exec, exec_type, vendor_file_type, file_type; # 声明该服务由init管理 init_daemon_domain(test_service); # 允许init以test_service身份执行test_service_exec类型的文件 allow init test_service_exec:file { read open getattr execute };关键说明：
coredomain表示它属于系统核心域，可访问基础资源；init_daemon_domain()是必须调用的宏，它自动赋予test_service对init相关接口的访问权；allow init ...这一行才是执行权限的核心——没有它，init连execve都失败，脚本根本不会被加载。
注意：网上常见写法
allow shell test_service_exec:file ...是错的！开机阶段shell进程尚未启动，真正执行脚本的是init进程，授权对象必须是init。
2.3 在init.rc中注册服务：位置比语法更重要
在init.xxx.rc（如init.mt6765.rc）中添加：
service test_service /system/bin/init.test.sh class main user root group root oneshot seclabel u:object_r:test_service_exec:s0避坑指南：
- ❌ 不要直接改
system/core/rootdir/init.rc——这是AOSP通用文件，厂商定制应走device/mediatek/.../init.xxx.rc； class main确保它随主服务类一起启动（通常在zygote之前）；user root和group root是必须的，普通用户无法调用setprop；seclabel必须与.te中定义的test_service_exec完全一致，大小写、下划线都不能错。
2.4 添加file_contexts：SELinux的“门牌号”
在device/mediatek/sepolicy/basic/non_plat/file_contexts中追加一行：
/system/bin/init\.test\.sh u:object_r:test_service_exec:s0注意细节：
- 路径用正则转义：
.sh要写成\.sh，否则匹配失败； - 路径必须与
init.rc中service声明的路径完全一致（包括/system/bin/前缀）； - 即使关闭SELinux（
setenforce 0），这行也必须存在——因为init在解析init.rc时会预检查file_contexts，缺失即报错退出。
验证方法：
adb shell ls -Z /system/bin/init.test.sh，输出中第三段应为u:object_r:test_service_exec:s0。如果不是，说明file_contexts未生效或路径不匹配。
3. 调试不靠猜：三步定位执行失败原因
开机脚本失败，90%的问题都能通过以下三步快速定位，无需串口、不依赖logcat。
3.1 第一步：确认服务是否被init识别
重启后立即执行：
adb shell getenforce # 确认SELinux状态（Permissive或Enforcing） adb shell ls -l /system/bin/init.test.sh # 检查文件是否存在、权限是否为755 adb shell ls -Z /system/bin/init.test.sh # 检查SELinux标签是否正确如果ls -Z显示u:object_r:shell_exec:s0，说明file_contexts没生效；如果显示u:object_r:unlabeled:s0，说明sepolicy未编译进镜像。
3.2 第二步：检查init是否尝试启动该服务
adb shell dmesg | grep -i "test_service" adb shell cat /proc/kmsg | grep -i "test_service" # 需root正常情况下，你会看到类似：
[ 5.123456] init: starting service 'test_service'... [ 5.124567] init: Created socket '/dev/socket/test_service' with mode '0666', user '0', group '0'如果没有这些日志，说明init压根没读到你的service定义——检查init.xxx.rc是否被正确include，或init.rc中是否有语法错误导致后续内容跳过。
3.3 第三步：验证脚本是否真正执行
在脚本开头加入日志输出（仅调试用）：
#!/system/bin/sh echo "[test_service] start at $(date)" > /data/local/tmp/oneshot.log setprop test.oneshot.status "started" echo "[test_service] setprop done" >> /data/local/tmp/oneshot.log exit 0重启后查看：
adb shell cat /data/local/tmp/oneshot.log adb shell getprop test.oneshot.status如果log文件存在且内容完整，但getprop为空，说明脚本执行了但setprop失败（常见于属性未在property_contexts中声明）；如果log文件为空，则脚本根本没运行。
属性声明补充：若需自定义属性，务必在
device/mediatek/sepolicy/basic/non_plat/property_contexts中添加：test\.oneshot\.status u:object_r:default_prop:s0
4. 常见误区与工程化建议
很多团队踩过坑才明白：开机脚本不是“能跑就行”，而是要兼顾稳定性、可维护性和可追溯性。
4.1 三个典型误区
误区一：“我加了
oneshot，脚本就应该只跑一次”
→ 实际上，只要设备重启，oneshot服务就会再次执行。它不记录历史状态，“一次”指的是单次启动过程中的生命周期。误区二：“关掉SELinux就能跳过te和file_contexts”
→ 错。setenforce 0只影响运行时检查，init在解析init.rc时仍会校验file_contexts是否存在。缺失即报错，服务注册失败。误区三：“脚本里sleep 5秒，就能确保它在zygote之后运行”
→ 错。class main服务并行启动，sleep只会阻塞当前服务，不影响其他服务顺序。如需依赖zygote，应使用on property:触发，而非oneshot。
4.2 四条工程化建议
用属性代替文件做状态标记
setprop test.service.ready 1比touch /data/misc/test/ready更轻量、更安全，避免分区满、权限错等问题。所有开机脚本统一放在
/system/bin/，命名带init.前缀
便于grep查找、避免与普通工具混淆，也符合Android命名惯例。调试期脚本末尾加
log -p i -t TEST "script finished"logcat -s TEST即可过滤，比dmesg更聚焦，且无需root。量产前移除所有
echo > /data/...日志/data分区IO频繁，开机阶段大量写入可能拖慢启动速度，甚至引发分区损坏风险。
5. 总结：oneshot的本质是“契约精神”
oneshot不是一个技术开关，而是一份与Android init进程签订的契约：
- 我承诺只做一件事；
- 我承诺做完立刻退出；
- 我承诺退出时返回成功码；
- 你承诺不重试、不监控、不干预。
当你的脚本严格履行这份契约，它就会在每次开机时准时、安静、可靠地完成使命。
本文所用镜像“测试开机启动脚本”，正是基于上述原则构建的最小可行验证环境。它不包含冗余组件，不依赖外部服务，所有配置开箱即用，专为验证oneshot行为而生。
你现在可以明确回答：
- oneshot服务是什么？→ 是init对一次性任务的标准化生命周期管理；
- 为什么我的脚本不执行？→ 先查
ls -Z，再看dmesg，最后验getprop； - 下一步做什么？→ 把
init.test.sh换成你的业务逻辑，沿用同一套te+rc+contexts结构，稳稳落地。
--- > **获取更多AI镜像** > > 想探索更多AI镜像和应用场景？访问 [CSDN星图镜像广场](https://ai.csdn.net/?utm_source=mirror_blog_end)，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
