RK3568 Android 13 开机时间优化-HAL 服务延时启动

前言

一、技术背景

[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 服务启动优化只是其中一环，但往往是最容易落地、效果最明显的一环。