目录
[1.1 Android 启动流程简述](#1.1 Android 启动流程简述)
[1.2 init.rc 中的 Class 机制](#1.2 init.rc 中的 Class 机制)
[1.3 为什么 HAL 服务是优化重点](#1.3 为什么 HAL 服务是优化重点)
[2.1 查看当前有哪些 HAL 服务](#2.1 查看当前有哪些 HAL 服务)
[2.2 第二步：确定可延迟的服务](#2.2 第二步：确定可延迟的服务)
[2.3 找到源码中的 .rc 文件路径](#2.3 找到源码中的 .rc 文件路径)
[2.4 修改服务启动类](#2.4 修改服务启动类)
前言
如果你做过 Android 嵌入式开发，一定对漫长的开机等待深有体会。尤其是在车载、智能家居等场景，用户对"上电即用"的期望越来越高。
最近在 RK3568 Android 13 平台上，我发现系统从 U-Boot 到进入 Launcher 需要等待较长时间。通过分析启动日志，发现大量 HAL 服务在开机早期被集中启动，其中很多服务（如蓝牙、摄像头）在用户解锁屏幕前根本不会被用到。
于是我开始尝试：能不能让这些"非必需"服务晚点启动？
本文记录了完整的分析、实施和验证过程，希望对同样被开机时间困扰的开发者有所帮助。
一、技术背景
1.1 Android 启动流程简述
Android 系统的启动大致分为以下几个阶段：
Boot ROM → U-Boot/SPL → Kernel → init 进程 → Zygote → SystemServer → Launcher在 init 进程阶段，系统会根据 .rc 文件中的配置启动各类服务。其中，HAL（硬件抽象层）服务的启动时机由 class 关键字控制。
1.2 init.rc 中的 Class 机制
Android init 进程通过 class 对服务进行分组管理，常见的 class 有：
| Class 类型 | 启动时机 | 说明 |
|---|---|---|
class core |
系统启动最早阶段 | 最核心的基础服务，如 ueventd、logd |
class main |
系统启动早期 | 核心系统服务，启动顺序靠前 |
class hal |
main 之后启动 | 硬件抽象层服务专用，大量 HAL 服务集中在此 |
class late_start |
系统完全启动后 | 用户可见桌面后才启动，适合非关键服务 |
从 class hal 到 class late_start 之间，存在一个明显的时间窗口。把非关键 HAL 服务移到 late_start，就能让它们不阻塞桌面显示。
1.3 为什么 HAL 服务是优化重点
在安卓板子上的 vendor/etc/init/ 目录下，存放着大量 HAL 服务的 .rc 文件：
这些服务在开机早期被 class_start hal 命令一次性全部启动 。但实际上，用户进入桌面后才会打开相机、连接蓝牙、播放视频。提前启动这些服务，白白消耗了开机时间。
二、具体实施
2.1 查看当前有哪些 HAL 服务
首先进入编译输出目录，查看 vendor/etc/init/ 下的所有服务文件：
bash
cd out/target/product/rk3568_t/vendor/etc/init
ls -l *.rc输出显示了几十个 .rc 文件，每个对应一个 HAL 服务，如下
2.2 第二步：确定可延迟的服务
根据翻阅资料，可以将服务分为三类：
| 类别 | 服务示例 | 处理方式 |
|---|---|---|
| 🔴 绝对不能延迟 | graphics.composer、graphics.allocator、audio、gatekeeper、keymint、thermal、health |
保持 class hal |
| 🟡 可以延迟 | bluetooth、camera、sensors、drm、cas |
改为 class late_start |
| 🟢 按需延迟 | media.c2、media.omx、neuralnetworks |
根据业务场景评估 |
2.3 找到源码中的 .rc 文件路径
使用 find 命令定位 .rc 文件的源码位置：
bash
# 在 SDK 根目录搜索
find . -name "android.hardware.media.omx@1.0-service.rc"输出示例：
对于其他服务，操作类似。
2.4 修改服务启动类
我最终选择延迟以下服务（经过验证是安全的）：
bash
# 传感器服务
hardware/interfaces/sensors/1.0/default/android.hardware.sensors@1.0-service.rc
# 摄像头服务
hardware/interfaces/camera/provider/2.4/default/android.hardware.camera.provider@2.4-service.rc
# 蓝牙服务
hardware/interfaces/bluetooth/1.0/default/android.hardware.bluetooth@1.0-service.rc
# Codec2 媒体服务
vendor/rockchip/hardware/interfaces/codec2/services/android.hardware.media.c2@1.1-service.rc
# Rockit 硬件服务（Rockchip 专用）
vendor/rockchip/hardware/interfaces/rockit/hw/hidl/services/rockchip.hardware.rockit.hw@1.0-service.rc修改方式： 编辑对应的 .rc 文件，将 class hal 改为 class late_start：
修改前：
bash
service vendor.sensors-hal /vendor/bin/hw/android.hardware.sensors@1.0-service
class hal
user system
...修改后：
bash
service vendor.sensors-hal /vendor/bin/hw/android.hardware.sensors@1.0-service
class late_start
user system
...总结
Android init 的 class 机制是开机优化的利器 ------用对 late_start 可以显著缩短开机时间。不是所有 HAL 服务都需要尽早启动 ------蓝牙、摄像头、传感器等在用户解锁前用不到。优化需要结合硬件平台特性，分步验证是安全的保障。优化开机时间是一个系统工程，从 Bootloader 到 Kernel 再到 Android 层，每一层都有优化空间。HAL 服务启动优化只是其中一环，但往往是最容易落地、效果最明显的一环。