本溪市网站建设_网站建设公司_导航易用性_seo优化

开箱即用！测试开机启动脚本快速落地Android项目

在嵌入式开发和定制化系统集成中，让某些功能在设备启动时自动执行是一项非常基础但关键的需求。比如自定义服务拉起、硬件初始化检测、日志开关配置等场景，都需要通过开机启动脚本来实现。

本文将围绕“测试开机启动脚本”这一镜像能力，手把手带你完成一个可在 Android 8.0 系统上稳定运行的开机启动 Shell 脚本部署流程。整个过程无需从零搭建环境，基于预置镜像即可实现“开箱即用”，大幅降低调试门槛，帮助你快速验证逻辑、推进项目落地。

1. 明确目标与适用场景

我们这次要解决的核心问题是：如何在 Android 设备开机过程中，自动执行一段自定义 Shell 脚本，并确保其在 SELinux 安全机制下正常运行？

适用场景包括：

• 自动设置系统属性用于后续服务判断
• 启动前对特定硬件进行状态检测
• 批量设备部署时统一初始化配置
• 快速验证底层服务依赖关系

最终达成效果：

• 脚本随系统启动自动执行一次（oneshot）
• 不影响正常开机流程
• 可通过getprop test.prop验证执行结果
• 全流程适配 Android 8.0 及主流 MTK 平台

接下来我们将分步拆解实现路径，每一步都给出可操作指令和注意事项。

2. 编写可执行的开机启动脚本

2.1 创建 Shell 脚本文件

新建一个名为init.test.sh的脚本文件，内容如下：

#!/system/bin/sh # 设置一个测试属性，便于后续验证是否执行成功 setprop test.prop 111 # （可选）可以添加其他调试信息输出到日志 log -t "InitScript" -p i "Test init script executed successfully"

2.2 注意事项说明

• 解释器路径必须正确：Android 系统中的 Shell 解释器位于/system/bin/sh，不能使用 Linux 常见的/bin/sh。
• 避免复杂操作：初期建议只做简单属性设置或日志打印，避免创建文件、修改权限等可能触发 SELinux 拒绝的操作。
• 手动测试先行：建议先通过 adb push 将脚本推送到设备并手动执行，确认语法无误：

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 adb shell getprop test.prop # 应返回 111

只有手动能跑通，才具备进入开机自动执行的前提条件。

3. 配置 SELinux 策略支持

Android 自 Android 5.0 起全面启用 SELinux 强制模式，即使你的设备暂时关闭了 enforcing，也建议完整配置策略，否则可能导致脚本无法被 init 进程调用。

3.1 新建 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); # （可选）如果需要 shell 调试时访问此脚本，取消下面这行注释 # allow shell test_service_exec:file { read open getattr execute };

3.2 放置策略文件位置

对于 MTK 平台，通常将上述.te文件放入以下目录：

device/mediatek/sepolicy/basic/non_plat/test_service.te

提示：不同芯片厂商路径略有差异，高通平台一般为device/qcom/sepolicy/vendro/目录下，请根据实际项目结构调整。

3.3 添加 file_contexts 上下文映射

编辑或创建文件：

device/mediatek/sepolicy/basic/non_plat/file_contexts

添加如下规则：

/(system\/vendor|vendor)/bin/init\.test\.sh u:object_r:test_service_exec:s0

这条规则的作用是告诉 SELinux：当系统看到/vendor/bin/init.test.sh这个文件时，应赋予它test_service_exec类型的安全上下文。

即使你当前处于 permissive 模式，缺少这一步也会导致 init 找不到或拒绝加载脚本！

4. 在 init.rc 中注册启动服务

Android 系统由init进程读取.rc文件来启动各类服务。我们需要在此类文件中声明我们的脚本为一项 service。

4.1 修改对应的 init.XXX.rc 文件

不建议直接修改根目录下的init.rc，而应选择厂商提供的扩展.rc文件，例如：

device/xxx/xxx/init.mt6765.rc # MTK 示例 vendor/etc/init/hw/init.xxx.rc # 通用路径

在合适的位置加入以下 service 声明：

service test_service /vendor/bin/init.test.sh class main user root group root oneshot disabled seclabel u:object_r:test_service_exec:s0

4.2 关键字段解释

若希望开机即运行，可去掉disabled，或在其他 rc 文件中添加on property sys.boot_completed=1 start test_service实现延后启动。

5. 构建与部署流程

完成代码编写后，进入构建阶段。以下是标准集成步骤：

5.1 脚本拷贝到 vendor 分区

确保init.test.sh被编译进最终镜像，可在Android.mk或Android.bp中添加安装规则。

示例（Android.mk）：

LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := init.test.sh LOCAL_SRC_FILES := init.test.sh LOCAL_MODULE_CLASS := EXECUTABLES LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR_EXECUTABLES) LOCAL_MODULE_TAGS := optional include $(BUILD_PREBUILT)

这样会在编译时自动把脚本打包进/vendor/bin/init.test.sh。

5.2 编译并刷机验证

执行完整编译：

mka test_service # 如果模块名已注册 # 或 mka systemimage # 编译完整系统镜像

烧录新固件后重启设备：

adb reboot adb shell getprop test.prop

若返回111，说明脚本已成功执行！

5.3 查看日志辅助调试

如未生效，可通过串口或 logcat 查看错误原因：

adb logcat | grep -i "avc denied"

常见问题：

• AVC denied 错误 → SELinux 策略缺失，需补全 allow 规则
• Permission denied → 文件没有可执行权限，检查 build rule 是否设置了 mode
• Script not found → 路径错误或未正确打包进 vendor 分区

6. 实战优化建议与避坑指南

虽然流程看似清晰，但在真实项目中仍有不少“坑”。以下是多年工程实践中总结的经验点。

6.1 快速验证技巧

• 使用chcon临时修改上下文测试（无需重编译）：

adb shell chcon u:object_r:system_file:s0 /vendor/bin/init.test.sh

• 临时开启调试日志：

service test_service ... ... writepid /dev/cpuset/background/tasks # 加一行 log 输出便于追踪 console

6.2 安全性建议

• 尽量避免长期保留user root，若只需读写特定节点，可用更细粒度权限；
• 生产环境建议启用disabled+ 属性触发机制，防止异常反复执行；
• 脚本本身应具备幂等性，避免多次执行造成副作用。

6.3 多版本兼容注意点

因此，在跨版本移植时务必检查分区结构和 SEPolicy 加载顺序。

获取更多AI镜像

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