Android 11系统启动时init.rc命令执行时机深度解析

在Android系统启动过程中，init.rc文件的执行时机一直是开发者关注的焦点。本文将从一个实际案例出发，详细剖析从rc文件解析到命令执行的完整链路，帮助开发者掌握系统定制的关键节点。

1. init.rc文件解析机制

Android系统的init进程在第二阶段初始化时会加载并解析init.rc文件。这个解析过程并非简单的顺序执行，而是构建了一个复杂的动作管理系统。

1.1 rc文件加载顺序

init进程会按照特定顺序加载多个目录下的rc文件：

code复制/system/etc/init/hw/init.rc → 核心系统配置文件
/system/etc/init/ → 按字母顺序加载
/vendor/etc/init/ → SoC供应商配置
/odm/etc/init/ → 设备制造商配置

注意：目录加载是顺序执行的，但同一目录内的文件按字母顺序处理，这可能导致依赖关系问题。

1.2 解析过程关键步骤

解析过程主要通过Parser类实现：

1. 文件读取：将rc文件内容读入内存字符串
2. 分段处理：识别"on"、"service"、"import"等关键字划分段落
3. 命令映射：将文本命令映射到对应的函数指针
4. 数据结构构建：
   • Action对象存储触发条件和命令序列
   • Service对象描述后台服务配置

解析完成后，所有Action会被存入ActionManager的actions_向量，Service存入ServiceList的services_向量。

2. 命令执行触发机制

init.rc中的命令不会在解析时立即执行，而是需要等待特定触发条件满足。

2.1 触发器类型

Android init语言支持两种触发器：

2.2 执行队列管理

当触发器条件满足时，相关Action会被加入执行队列：

cpp复制void ActionManager::QueueEventTrigger(const std::string& trigger) {
    std::lock_guard<std::mutex> lock(event_queue_lock_);
    event_queue_.push(trigger);
}

执行时，init主循环不断调用ExecuteOneCommand()处理队列中的命令：

cpp复制while (true) {
    if (!(prop_waiter_state.MightBeWaiting() || Service::is_exec_service_running())) {
        am.ExecuteOneCommand();
    }
    // ...其他处理逻辑
}

3. mount_all命令案例分析

以常见的mount_all命令为例，解析其完整执行链路：

1. 命令映射：在BuiltinFunctionMap中，mount_all对应do_mount_all函数
2. 触发时机：通常在"fs"或"late-init"阶段触发
3. 执行过程：
   • 检查fstab文件
   • 分阶段挂载各分区
   • 触发post-fs-data事件

分区挂载典型顺序：

1. /system、/vendor等只读分区
2. /data等可读写分区
3. 动态分区（如A/B系统）

提示：修改fstab文件或init.rc中的mount命令可以调整挂载行为。

4. 调试与定制实践

掌握init.rc命令执行时机后，开发者可以进行系统级定制：

4.1 常见调试方法

• 查看执行日志：

  bash复制adb logcat | grep -i init
  

• 添加调试命令：

  rc复制on property:debug.init=1
    exec /system/bin/logwrapper /system/bin/sh -c "echo INIT_DEBUG > /dev/kmsg"
  

4.2 定制注意事项

1. 执行顺序控制：

   • 使用trigger命令建立依赖关系
   • 合理设置属性触发器条件

2. 服务启动优化：

   rc复制service myservice /system/bin/myservice
       class main
       user system
       group system
       oneshot
   

3. 常见问题排查：

   • 命令未执行：检查触发器条件是否满足
   • 执行顺序异常：检查action的class设置
   • 权限问题：检查sepolicy配置

在实际项目中，我曾遇到data分区挂载失败的问题，最终发现是由于一个自定义服务的执行阻塞了mount_all操作。通过调整服务触发时机，将挂载操作提前到独立action中，问题得到解决。