快速掌握Android init.rc配置，启动脚本轻松集成
1. 引言：为何需要自定义开机启动脚本
在Android系统开发中，尤其是在定制ROM、设备初始化或嵌入式场景下，经常需要在系统启动过程中执行一些特定的初始化操作。这些操作可能包括设置系统属性、挂载特殊分区、启动守护进程或调试硬件状态等。
虽然可以通过应用层的BroadcastReceiver监听BOOT_COMPLETED广播来实现部分功能，但这种方式存在明显延迟——必须等待整个Zygote和System Server启动完成。对于需要早期介入系统启动流程的任务，必须依赖更底层的机制：init.rc脚本。
本文将详细介绍如何通过修改init.rc配置文件，在Android 8.0及以上系统中安全、可靠地集成自定义开机启动脚本，并涵盖SELinux权限配置的关键步骤，帮助开发者避免常见陷阱。
2. 核心概念解析：init.rc与Android Init语言
2.1 什么是init.rc？
init.rc是Android系统中由init进程读取的第一个脚本文件，位于根文件系统的/init.rc路径。它是用Android Init语言编写的文本文件，用于定义：
- 系统服务（service）
- 动作触发器（on action）
- 环境变量设置（export）
- 权限配置（chown, chmod）
- 文件挂载（mount）
init进程是Android系统中所有用户空间进程的祖先（PID=1），它负责解析并执行init.rc中的指令，从而拉起关键系统服务。
2.2 Init语言的基本结构
Init语言主要包含以下几类语句：
on <trigger> # 定义动作触发条件 <command> # 执行命令列表 service <name> <path> # 定义一个服务 <option> # 服务选项（用户、组、seclabel等）例如，一个典型的开机启动服务定义如下：
service my_startup /system/bin/my_script.sh class main user root group root oneshot seclabel u:object_r:my_script_exec:s0其中：
class main表示该服务属于主启动类oneshot表示只运行一次，不重启seclabel指定SELinux安全上下文
3. 实现步骤详解：从脚本编写到系统集成
3.1 编写可执行Shell脚本
首先创建你的启动脚本，建议命名为init.test.sh，存放于device/<company>/<target>/root/system/bin/或统一管理目录中。
#!/system/bin/sh # # init.test.sh - 测试开机启动脚本 # # 设置测试属性，便于验证脚本是否执行 setprop test.boot.script.executed 1 # 输出日志到dmesg（可用于调试） log -t "InitScript" -p i "Test startup script is running" # 可选：创建标记文件（注意权限问题） # touch /data/local/tmp/boot_script_done # 示例：检查某个节点是否存在 if [ -e "/sys/class/leds/blue/brightness" ]; then echo 1 > /sys/class/leds/blue/brightness fi重要提示：脚本首行必须为
#!/system/bin/sh，不能使用/bin/sh，否则在Android系统中无法正确解析。
构建完成后，该脚本应被打包进system.img，最终位于/system/bin/init.test.sh。
3.2 将脚本添加到系统镜像
在设备的Android.mk或BoardConfig.mk中确保脚本被正确打包：
# Android.mk 示例 LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := init.test.sh LOCAL_SRC_FILES := root/system/bin/init.test.sh LOCAL_MODULE_CLASS := ETC LOCAL_MODULE_PATH := $(TARGET_ROOT_OUT)/system/bin include $(BUILD_PREBUILT)或者使用PRODUCT_COPY_FILES方式：
PRODUCT_COPY_FILES += \ device/example/target/root/system/bin/init.test.sh:system/bin/init.test.sh3.3 在init.rc中注册服务
不建议直接修改顶层init.rc，而应在设备专属的init.<target>.rc文件中添加服务定义，如init.target.rc。
# service name path [arg1] [arg2] ... service test_startup /system/bin/init.test.sh class main user root group root oneshot disabled # 先禁用，通过trigger手动启动 seclabel u:object_r:test_startup_exec:s0 # 触发器：在boot-complete阶段执行 on property:sys.boot_completed=1 start test_startup说明：
disabled防止自动启动，配合start命令控制时机on property:sys.boot_completed=1确保在系统完全启动后运行- 若需更早执行，可使用
on early-init、on init或on fs等阶段
3.4 SELinux策略配置（te文件）
由于Android启用了SELinux强制模式，任何新服务都必须声明其安全上下文。
创建.te策略文件
在设备SELinux策略目录下新建test_startup.te（如device/<company>/<target>/sepolicy/test_startup.te）：
# 定义类型 type test_startup, coredomain; # 定义可执行文件类型 type test_startup_exec, exec_type, file_type; # 允许init域转换到该域 init_daemon_domain(test_startup) # 可选：允许shell域访问（用于调试） # allow shell test_startup_exec:file { read open getattr execute };注册文件上下文
在file_contexts文件中绑定文件路径与SELinux标签：
# device/<company>/<target>/sepolicy/file_contexts /system/bin/init\.test\.sh u:object_r:test_startup_exec:s0编译策略
确保.te文件被纳入编译系统，通常在sepolicy/Android.mk或BOARD_SEPOLICY_DIRS中引用：
BOARD_SEPOLICY_DIRS += \ device/example/target/sepolicy3.5 调试与验证方法
方法一：查看属性是否设置
adb shell getprop test.boot.script.executed # 输出 1 表示脚本已执行方法二：查看内核日志
adb logcat -b kernel | grep "InitScript"方法三：检查服务状态
adb shell dumpsys activity services test_startup方法四：使用dmesg观察init输出
adb shell dmesg | grep init若出现类似starting service 'test_startup'...日志，则表示服务已被触发。
4. 常见问题与解决方案
4.1 脚本未执行的可能原因
| 问题 | 排查方法 | 解决方案 |
|---|---|---|
| SELinux拒绝 | dmesg | grep avc | 添加对应allow规则 |
| 路径错误 | ls /system/bin/init.test.sh | 确认文件存在且权限为755 |
| Shebang错误 | file /system/bin/init.test.sh | 修改为#!/system/bin/sh |
| 服务未启动 | dumpsys init | grep test_startup | 检查trigger是否满足 |
4.2 SELinux权限不足典型报错
avc: denied { execute } for name="init.test.sh" dev="sdaXX" ino=XXXX解决方法是在.te文件中添加相应权限：
# 如果需要访问特定目录 allow test_startup system_file:dir search; allow test_startup system_prop:file read; # 如果需要写文件 allow test_startup data_file:file write;可借助audit2allow工具自动生成规则：
adb pull /proc/kmsg kmsg.log grep avc kmsg.log | audit2allow4.3 启动时机选择建议
| 需求场景 | 推荐trigger | 说明 |
|---|---|---|
| 修改系统属性 | on init | 早期设置 |
| 操作/sys节点 | on fs | 文件系统挂载后 |
| 依赖Zygote服务 | on property:sys.boot_completed=1 | 系统完全启动后 |
| 网络相关操作 | on property:net.eth0.got_ip=1 | 获取IP后执行 |
5. 最佳实践与工程建议
5.1 安全性建议
- 最小权限原则：仅授予脚本必需的SELinux权限
- 避免硬编码路径：使用环境变量或系统属性
- 日志脱敏：避免在log中输出敏感信息
- 失败处理：添加错误判断和退出码
if ! touch /data/misc/test.flag; then log -t "InitScript" -p w "Failed to create flag file" exit 1 fi5.2 可维护性优化
- 使用统一前缀命名服务（如
svc_test_*） - 将多个小任务合并为单一服务，减少init负担
- 提供开关属性控制启用状态：
on property:test.startup.enabled=1 && property:sys.boot_completed=1 start test_startup5.3 多版本兼容性考虑
不同Android版本init行为略有差异：
- Android 8.0+：Treble架构，vendor和system分离
- Android 10+：Stronger SELinux，默认deny未知domain
- Android 12+：More restricted init context
建议在BoardConfig.mk中通过宏控制：
ifeq ($(TARGET_USES_TEST_INIT),true) PRODUCT_COPY_FILES += \ device/example/target/init.test.sh:system/bin/init.test.sh endif6. 总结
通过本文的系统化梳理，我们完成了从零开始集成Android开机启动脚本的完整闭环：
- 脚本编写：确保语法正确、路径合规；
- 系统集成：通过
PRODUCT_COPY_FILES打包进镜像； - 服务注册：在
init.<target>.rc中定义service； - SELinux配置：编写
.te策略并绑定file_contexts； - 调试验证：利用属性、日志和dumpsys确认执行效果。
这套方法已在Android 8.0至Android 13多个版本上验证有效，适用于高通、MTK、瑞芯微等主流平台。
掌握init.rc的配置不仅有助于实现开机自动化任务，更是深入理解Android系统启动流程的关键一步。合理运用这一机制，可以显著提升系统级定制能力。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
