init.rc主配置

上一篇内置命令下回答了单条命令何时生效；本文把视野扩大到整份 init.rc，但不做“从头到尾翻译配置”的清单。教材目标是建立一条可以回到源码验证的主线：这份文件如何被安装和选中，early-init 为什么能使用哪些资源，late-init 如何把阶段变成队列，post-fs-data 的等待点如何形成真正屏障，以及 zygote-start、boot 和 sys.boot_completed 为什么不是同一个完成信号。

过去的资料常把 cgroup 挂载、Zygote 启动和设备配置都归到 root init.rc。当前实现已经把 cgroup 准备放进 C++ 初始队列，根配置还依赖设备 rc、vendor rc、fstab、APEX 和属性服务。因此阅读本文时，要把“根文件中出现的命令”“C++ 在文件之前排队的动作”和“其他分区追加的 Action”分开。

1. 文件入口

1.1 安装位置

源码文件：system/core/rootdir/Android.bp

相关函数/类型：prebuilt_etc { name: "init.rc" }

make

prebuilt_etc {
    name: "init.rc",
    src: "init.rc",
    sub_dir: "init/hw",
    required: [
        "platform-bootclasspath",
        "init.boringssl.zygote64.rc",
        "init.boringssl.zygote64_32.rc",
        "init-perfetto.rc",
    ],
}

这段构建规则证明了两个边界。第一，源码文件的安装目标是 init/hw 子目录，运行时由 init.cpp 读取 /system/etc/init/hw/init.rc；不能因为源文件位于 rootdir/ 就把它写成运行时 /init.rc。第二，zygote、BoringSSL 自检和 Perfetto 的 rc 文件是构建依赖，主文件的 import 还会根据属性选择硬件和 zygote 变体。

1.2 首部导入

源码文件：system/core/rootdir/init.rc

text

import /init.environ.rc
import /system/etc/init/hw/init.usb.rc
import /init.${ro.hardware}.rc
import /vendor/etc/init/hw/init.${ro.hardware}.rc
import /system/etc/init/hw/init.usb.configfs.rc
import /system/etc/init/hw/init.${ro.zygote}.rc

这些 import 是 Parser 的输入，不是 shell 的 source。${ro.hardware} 和 ${ro.zygote} 在命令执行前由 init 的属性展开规则处理；导入失败和目录导入还有各自的 parser 语义。更重要的是，主文件导入的设备 rc 与 LoadBootScripts() 后续扫描的分区目录不是一回事：前者在配置文本中显式出现，后者由 C++ 决定扫描路径。

1.3 C++选择器

源码文件：system/core/init/init.cpp

2. 早期准备

2.1 Cgroup先行

相关源码：

system/core/init/init.cpp
SecondStageMain

cpp

am.QueueBuiltinAction(SetupCgroupsAction, "SetupCgroups");
am.QueueEventTrigger("early-init");
am.QueueBuiltinAction(ConnectEarlyStageSnapuserdAction,
                      "ConnectEarlyStageSnapuserd");
am.QueueBuiltinAction(wait_for_coldboot_done_action,
                      "wait_for_coldboot_done");
am.QueueBuiltinAction(SetMmapRndBitsAction, "SetMmapRndBits");

根配置的注释说 cgroup 会在 early-init 前挂载，对应的 C++ 调用顺序是：SetupCgroupsAction 先排入队列，然后才是 early-init 事件。init.rc 中后续对 /dev/memcg、cpuctl 或服务 class 的操作，依赖的是这个前置动作，而不是由 early-init 自己首次挂载全部 cgroup。

wait_for_coldboot_done_action 也很关键：start ueventd 只发起服务启动，coldboot 完成由独立的等待动作确认。后续需要设备节点的 action 不能只看 start ueventd 的返回值。

2.2 早期事件

源码文件：system/core/rootdir/init.rc

2.3 APEX屏障

源码文件：system/core/rootdir/init.rc

3. 初始化段

3.1 设备接口

源码文件：system/core/rootdir/init.rc

3.2 Binder与存储

源码文件：system/core/rootdir/init.rc

3.3 核心服务

源码文件：system/core/rootdir/init.rc

4. 阶段队列

4.1 late-init配置

源码文件：system/core/rootdir/init.rc

4.2 消费边界

源码文件：system/core/init/action_manager.cpp

相关函数/类型：ExecuteOneCommand

cpp

while (current_executing_actions_.empty() && !event_queue_.empty()) {
    for (const auto& action : actions_) {
        if (std::visit([&action](const auto& event) {
                return action->CheckEvent(event);
            }, event_queue_.front())) {
            current_executing_actions_.emplace(action.get());
        }
    }
    event_queue_.pop();
}

if (current_executing_actions_.empty()) return;

auto action = current_executing_actions_.front();
action->ExecuteOneCommand(current_command_);

匹配发生时，ActionManager 扫描已经解析的 Action；同一事件可匹配多个 Action，随后每轮只执行当前 Action 的一个 command。若某个 Action 在执行中 import 新 rc，新 Action 不会被已经取出的同一个 event 追溯匹配；后续 event 才可能看见它。这个边界由 init_test.cpp 的 lazy-load 测试直接验证。

4.3 属性触发

源码文件：system/core/init/init.cpp

相关函数/类型：queue_property_triggers_action

cpp

static Result<void> queue_property_triggers_action(const BuiltinArguments&) {
    ActionManager::GetInstance().QueueBuiltinAction(
            property_enable_triggers_action,
            "enable_property_trigger");
    ActionManager::GetInstance().QueueAllPropertyActions();
    return {};
}

初始队列还会安排这个 builtin action。它先追加“启用 property trigger”的一次性动作，再追加空的 PropertyChange，用于按当前属性状态检查 property actions。因此 on property:... 并不是从 init 进程启动瞬间就无条件生效；它有一个由 C++ 显式安排的启用与全量检查边界。

5. 文件阶段

5.1 early-fs

源码文件：system/core/rootdir/init.rc

5.2 post-fs

源码文件：system/core/rootdir/init.rc

5.3 late-fs

源码文件：system/core/rootdir/init.rc

5.4 设备扩展

标准根文件没有固定的 on fs 段，设备 rc 才是 fstab 的常见 owner。比如设备配置可以提供：

相关源码：

device/generic/goldfish/init/init.ranchu.rc
on fs
on late-fs

text

on fs
    mount_all /vendor/etc/fstab.ranchu --early

on late-fs
    mount_all /vendor/etc/fstab.ranchu --late

这是 goldfish 设备树中的真实配置，不是 system/core/rootdir/init.rc 的内容。分析真实设备时必须同时检查 init.${ro.hardware}.rc、/vendor/etc/init 和 fstab；只读 root init.rc 不能说明设备实际挂载了哪些分区，也不能把 ranchu 的 fstab 路径外推到实体设备。

6. Data屏障

6.1 前段动作

源码文件：system/core/rootdir/init.rc

6.2 等待点

源码文件：system/core/rootdir/init.rc

6.3 无回滚

源码文件：system/core/init/action.cpp

相关函数/类型：Action::ExecuteCommand

cpp

void Action::ExecuteCommand(const Command& command) const {
    android::base::Timer t;
    auto result = command.InvokeFunc(subcontext_);
    auto duration = t.duration();

    if (!result.has_value() || duration > 50ms ||
        android::base::GetMinimumLogSeverity() <= android::base::DEBUG) {
        LOG(INFO) << "Command '" << command.BuildCommandString()
                  << "' action=" << BuildTriggersString() << " ("
                  << filename_ << ":" << command.line() << ") took "
                  << duration.count() << "ms and "
                  << (result.ok() ? "succeeded"
                                  : "failed: " + result.error().message());
    }
}

Action::ExecuteCommand() 记录错误和耗时，但不会因为 Result<void> 失败而回滚前面已执行的命令，也不会自动跳过 Action 的下一条 command。只有 builtin 自己实现的清理（例如 loop mount 失败时 detach）或更高层 fatal/recovery 路径，才有局部恢复语义。

图中的循环是等待状态，不是 rc 语法循环。属性变化由 PropertyChanged() 同时送入属性 Action 队列并检查 waiter；满足条件后才唤醒主线程。

7. Zygote启动

7.1 独立事件

源码文件：system/core/rootdir/init.rc

7.2 Boot阶段

源码文件：system/core/rootdir/init.rc

7.3 主服务

源码文件：system/core/rootdir/init.rc

8. 分支路径

8.1 充电模式

相关源码：

system/core/init/init.cpp
SecondStageMain
system/core/rootdir/init.rc
on charger

cpp

if (bootmode == BootMode::CHARGER_MODE) {
    am.QueueEventTrigger("charger");
} else {
    am.QueueEventTrigger("late-init");
}

C++ 先决定进入哪个事件；rc 再为该事件提供匹配的 Action。下面的 on charger 是事件消费者，sys.boot_from_charger_mode 则是从充电模式回到正常启动时的第二个入口。

text

on charger
    class_start charger

on property:sys.boot_from_charger_mode=1
    class_stop charger
    trigger late-init

charger 模式初始不进入完整文件系统启动链。healthd 后续通过 property 触发 late-init，恢复路径是从 late-init 继续，而不是重新执行整个 SecondStageMain。这个区别决定了 charger 阶段已创建资源能否被复用，也决定了排障时不能把“没有 early-init 日志”直接判为 init 崩溃。

8.2 GSI边界

GSI 状态在脚本运行前由 C++ 写入属性，mount_all 的 recovery 分支还会拒绝在 GSI 中执行 wipe。标准 root init.rc 的 Action 不能外推为所有 GSI/vendor 行为；真实设备需要同时核对 GSI 属性、设备 fstab 和 vendor rc。

8.3 设备差异

LoadBootScripts() 会根据 ro.boot.init_rc 选择脚本，也会记录尚未可读分区的 late_import_paths。因此缺少某个 on fs、zygote 变体或 vendor service 时，优先检查“哪个脚本被选中、哪个目录在当时可读”，不要先假设 root init.rc 缺少命令。

9. 测试验证

9.1 Action顺序

源码文件：system/core/init/init_test.cpp

相关函数/类型：EventTriggerOrder

测试输入是一段临时 rc：两个无条件 on boot，中间一个带 property:ro.hardware=*；三个替代 builtin 按执行序号断言 0、1、2。它证明同一事件匹配 Action 后保持解析顺序，不证明设备分区最终 import 顺序。

9.2 Import顺序

源码文件：system/core/init/init_test.cpp

相关函数/类型：EventTriggerOrderMultipleFiles

测试构造一个直接 import 文件、一个目录 import 文件、目录内 a.rc 对另一个文件的递归 import 和 b.rc，最终断言六个 command 的执行顺序。它证明目录排序与递归导入会进入同一 Parser/ActionManager 体系；它不覆盖真实 /system_ext、/vendor 的权限和挂载时机。

9.3 延迟导入

相关源码：

system/core/init/init_test.cpp
LazilyLoadedActionsCantBeTriggeredByTheSameTrigger
LazilyLoadedActionsCanBeTriggeredByTheNextTrigger

一个测试在 on boot 中加载新的 on boot，断言当前 boot 不追溯执行；另一个加载 on next 后执行 trigger next，断言新 Action 在下一个事件执行。这正是 mount_all --late、APEX rc 和分区 late import 需要明确触发时机的原因。

9.4 现场检查

在 userdebug/eng 设备上可以只读观察：

bash

adb shell 'logcat -b all -d -s init:I | grep "processing action"'
adb shell getprop init.svc.ueventd
adb shell getprop init.svc.zygote
adb shell getprop init.svc.servicemanager
adb shell getprop ro.crypto.state
adb shell getprop sys.boot_completed
adb shell mount

processing action 的文件和行号能告诉你实际命中的 Action；init.svc.* 只表示 Service 状态；mount 只观察内核挂载表；sys.boot_completed 只证明 framework 写入了该属性。它们不能单独证明所有 init.rc 命令成功，也不能证明 system_server 业务 ready。

10. 触发追踪

建议用一次“Zygote 没有启动”的问题完成闭环：

从 init.cpp::SecondStageMain() 判断当前是否走 charger 或 late-init；
从 LoadBootScripts() 判断实际 root script 和 zygote rc 路径；
在 init.rc 追踪 late-init → post-fs-data → zygote-start；
检查 wait_for_prop odsign.verification.done 1 的 producer，而不是只重复 start zygote；
查看 init.svc.zygote、processing action 和 property 日志；
对照 init_test.cpp，明确 host 测试覆盖的调用顺序，以及仍需结合设备配置和运行状态判断的部分。

最终要保留三条边界：root init.rc 是配置输入，不是完整设备启动图；event 名称是调度标签，不是消费者完成信号；普通 command error 没有全局 rollback。沿着 owner、consumer 和生效时机阅读，才能把一份很长的 rc 文件变成可验证的源码教材。

init.rc主配置 ​

1. 文件入口 ​

1.1 安装位置 ​

1.2 首部导入 ​

1.3 C++选择器 ​

2. 早期准备 ​

2.1 Cgroup先行 ​

2.2 早期事件 ​

2.3 APEX屏障 ​

3. 初始化段 ​

3.1 设备接口 ​

3.2 Binder与存储 ​

3.3 核心服务 ​

4. 阶段队列 ​

4.1 late-init配置 ​

4.2 消费边界 ​

4.3 属性触发 ​

5. 文件阶段 ​

5.1 early-fs ​

5.2 post-fs ​

5.3 late-fs ​

5.4 设备扩展 ​

6. Data屏障 ​

6.1 前段动作 ​

6.2 等待点 ​

6.3 无回滚 ​

7. Zygote启动 ​

7.1 独立事件 ​

7.2 Boot阶段 ​

7.3 主服务 ​

8. 分支路径 ​

8.1 充电模式 ​

8.2 GSI边界 ​

8.3 设备差异 ​

9. 测试验证 ​

9.1 Action顺序 ​

9.2 Import顺序 ​

9.3 延迟导入 ​

9.4 现场检查 ​

10. 触发追踪 ​

init.rc主配置

1. 文件入口

1.1 安装位置

1.2 首部导入

1.3 C++选择器

2. 早期准备

2.1 Cgroup先行

2.2 早期事件

2.3 APEX屏障

3. 初始化段

3.1 设备接口

3.2 Binder与存储

3.3 核心服务

4. 阶段队列

4.1 late-init配置

4.2 消费边界

4.3 属性触发

5. 文件阶段

5.1 early-fs

5.2 post-fs

5.3 late-fs

5.4 设备扩展

6. Data屏障

6.1 前段动作

6.2 等待点

6.3 无回滚

7. Zygote启动

7.1 独立事件

7.2 Boot阶段

7.3 主服务

8. 分支路径

8.1 充电模式

8.2 GSI边界

8.3 设备差异

9. 测试验证

9.1 Action顺序

9.2 Import顺序

9.3 延迟导入

9.4 现场检查

10. 触发追踪