======================================================== ========================================================
= 【原创文章】：参考部分博客内容，学习之余进行了大量的筛减细化分析 = = 【特殊申明】：避讳抄袭侵权之嫌疑，特此说明，欢迎转载！ =
======================================================== ========================================================
【前言】
Android启动篇 — init原理（一）中讲解分init进程分析init创建系统目录并挂在相应系统文件、初始化属性域、设置系统属性、启动配置属性服务端等一系列复杂工作，很多工作和知识点跟Linux关系很大，所以没有作过多介绍，而本此对于init.rc的解析则是重中之重，所以单独拿出来进行详细分析。
int main(int argc, char** argv) {
/* 01. 创建文件系统目录并挂载相关的文件系统 */
/* 02. 屏蔽标准的输入输出/初始化内核log系统 */
/* 03. 初始化属性域 */
/* 04. 完成SELinux相关工作 */•
/* 05. 重新设置属性 */
/* 06. 创建epoll句柄 */
/* 07. 装载子进程信号处理器 */
/* 08. 设置默认系统属性 */
/* 09. 启动配置属性的服务端 */
/* 10. 匹配命令和函数之间的对应关系 */------------------------------------------------------------------------------------------- // Android启动篇 — init原理（一）中讲解 /* 11. 解析init.rc */
Parser& parser = Parser::GetInstance(); // 构造解析文件用的parser对象
// 增加ServiceParser为一个section，对应name为service
parser.AddSectionParser("service",std::make_unique<ServiceParser>());
// 增加ActionParser为一个section，对应name为action
parser.AddSectionParser("on", std::make_unique<ActionParser>());
// 增加ImportParser为一个section，对应name为service
parser.AddSectionParser("import", std::make_unique<ImportParser>());
parser.ParseConfig("/init.rc"); // 开始实际的解析过程
【正文】
init.rc是一个配置文件，内部由Android初始化语言编写（Android Init Language）编写的脚本，主要包含五种类型语句：Action、Command、Service、Option和Import，在分析代码的过程中我们会详细介绍。
init.rc的配置代码在：system/core/rootdir/init.rc 中
init.rc文件是在init进程启动后执行的启动脚本，文件中记录着init进程需执行的操作。
init.rc文件大致分为两大部分，一部分是以“on”关键字开头的动作列表（action list）：
on early-init // Action类型语句
# Set init and its forked children's oom_adj. // #：注释符号
write /proc//oom_score_adj -
... ...
start ueventd
Action类型语句格式：
on <trigger> [&& <trigger>]* // 设置触发器 <command> <command> // 动作触发之后要执行的命令
另一部分是以“service”关键字开头的服务列表（service list）： 如 Zygote
service ueventd /sbin/ueventd
class core
critical
seclabel u:r:ueventd:s0
Service类型语句格式：
service <name> <pathname> [ <argument> ]* // <service的名字><执行程序路径><传递参数> <option> // option是service的修饰词，影响什么时候、如何启动services <option> ...
借助系统环境变量或Linux命令，动作列表用于创建所需目录，以及为某些特定文件指定权限，而服务列表用来记录init进程需要启动的一些子进程。如上面代码所示，service关键字后的第一个字符串表示服务（子进程）的名称，第二个字符串表示服务的执行路径。
值得一提的是在Android 7.0中对init.rc文件进行了拆分，每个服务一个rc文件。我们要分析的zygote服务的启动脚本则在init.zygoteXX.rc中定义。
在init.rc的import段我们看到如下代码：
import /init.${ro.zygote}.rc // 可以看出init.rc不再直接引入一个固定的文件，而是根据属性ro.zygote的内容来引入不同的文件
说明：
从android5.0开始，android开始支持64位的编译，zygote本身也就有了32位和64位的区别，所以在这里用ro.zygote属性来控制启动不同版本的zygote进程。
init.rc位于/system/core/rootdir下。在这个路径下还包括四个关于zygote的rc文件。分别是Init.zygote32.rc，Init.zygote32_64.rc，Init.zygote64.rc，Init.zygote64_32.rc，由硬件决定调用哪个文件。
这里拿32位处理器为例，init.zygote32.rc的代码如下所示：
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
class main # class是一个option，指定zygote服务的类型为main
socket zygote stream root system # socket关键字表示一个option，创建一个名为dev/socket/zygote，类型为stream，权限为660的socket
onrestart write /sys/android_power/request_state wake # onrestart是一个option，说明在zygote重启时需要执行的command
onrestart write /sys/power/state on
onrestart restart audioserver
onrestart restart cameraserver
onrestart restart media
onrestart restart netd
writepid /dev/cpuset/foreground/tasks
“service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server”
在Init.zygote32.rc中，定义了一个zygote服务：zygote，由关键字service告诉init进程创建一个名为zygote的进程，这个进程要执行的程序是：/system/bin/app_process，给这个进程四个参数：
· -Xzygote：该参数将作为虚拟机启动时所需的参数
· /system/bin：代表虚拟机程序所在目录
· --zygote：指明以ZygoteInit.java类中的main函数作为虚拟机执行入口
· --start-system-server：告诉Zygote进程启动SystemServer进程
接下来，我们回到源码当中，继续分析main函数：
/* 11. 解析init.rc */
Parser& parser = Parser::GetInstance(); // 构造解析文件用的parser对象
// 增加ServiceParser为一个section，对应name为service
parser.AddSectionParser("service",std::make_unique<ServiceParser>());
// 增加ActionParser为一个section，对应name为action
parser.AddSectionParser("on", std::make_unique<ActionParser>());
// 增加ImportParser为一个section，对应name为service
parser.AddSectionParser("import", std::make_unique<ImportParser>());
parser.ParseConfig("/init.rc"); // 开始实际的解析过程
说明：
上面在解析init.rc文件时使用了Parser类（在init目录下的init_parser.h中定义）， 初始化ServiceParser用来解析 “service”块，ActionParser用来解析"on"块，ImportParser用来解析“import”块，“import”是用来引入一个init配置文件，来扩展当前配置的。
/system/core/init/readme.txt 中对init文件中的所有关键字做了介绍，主要包含了Actions, Commands, Services, Options, and Imports等，可自行学习解读。
分析init.rc的解析过程：函数定义于system/core/init/ init_parser.cpp中
bool Parser::ParseConfig(const std::string& path) {
if (is_dir(path.c_str())) { // 判断传入参数是否为目录地址
return ParseConfigDir(path); // 递归目录，最终还是靠ParseConfigFile来解析实际的文件
}
return ParseConfigFile(path); // 传入传输为文件地址
}
继续分析ParseConfigFile()：
bool Parser::ParseConfigFile(const std::string& path) {
... ...
Timer t;
std::string data;
if (!read_file(path.c_str(), &data)) { // 读取路径指定文件中的内容，保存为字符串形式
return false;
}
... ...
ParseData(path, data); // 解析获取的字符串
... ...
}
跟踪ParseData()：
void Parser::ParseData(const std::string& filename, const std::string& data) {
... ...
parse_state state;
... ...
std::vector<std::string> args;
for (;;) {
switch (next_token(&state)) { // next_token以行为单位分割参数传递过来的字符串，最先走到T_TEXT分支
case T_EOF:
if (section_parser) {
section_parser->EndSection(); // 解析结束
}
return;
case T_NEWLINE:
state.line++;
if (args.empty()) {
break;
}
// 在前文创建parser时，我们为service，on，import定义了对应的parser
// 这里就是根据第一个参数，判断是否有对应的parser
])) {
if (section_parser) {
// 结束上一个parser的工作，将构造出的对象加入到对应的service_list与action_list中
section_parser->EndSection();
}
// 获取参数对应的parser
section_parser = section_parsers_[args[]].get();
std::string ret_err;
// 调用实际parser的ParseSection函数
if (!section_parser->ParseSection(args, &ret_err)) {
parse_error(&state, "%s\n", ret_err.c_str());
section_parser = nullptr;
}
} else if (section_parser) {
std::string ret_err;
// 如果第一个参数不是service，on，import
// 则调用前一个parser的ParseLineSection函数
// 这里相当于解析一个参数块的子项
if (!section_parser->ParseLineSection(args, state.filename,
state.line, &ret_err)) {
parse_error(&state, "%s\n", ret_err.c_str());
}
}
args.clear(); // 清空本次解析的数据
break;
case T_TEXT:
args.emplace_back(state.text); //将本次解析的内容写入到args中
break;
}
}
}
至此，init.rc解析完，接下来init会执行几个重要的阶段：
int main(int argc, char** argv) {
/* 01. 创建文件系统目录并挂载相关的文件系统 */
/* 02. 屏蔽标准的输入输出/初始化内核log系统 */
/* 03. 初始化属性域 */
/* 04. 完成SELinux相关工作 */•
/* 05. 重新设置属性 */
/* 06. 创建epoll句柄 */
/* 07. 装载子进程信号处理器 */
/* 08. 设置默认系统属性 */
/* 09. 启动配置属性的服务端 */
/* 10. 匹配命令和函数之间的对应关系 */ /* 11. 解析init.rc*/---------------------------------------------------------------------------- /* 12. 向执行队列中添加其他action */
// 获取ActionManager对象，需要通过am对命令执行顺序进行控制
ActionManager& am = ActionManager::GetInstance();
// init执行命令触发器主要分为early-init，init，late-init，boot等
am.QueueEventTrigger("early-init"); // 添加触发器early-init，执行on early-init内容
// Queue an action that waits for coldboot done so we know ueventd has set up all of /dev...
am.QueueBuiltinAction(wait_for_coldboot_done_action, "wait_for_coldboot_done");
// ... so that we can start queuing up actions that require stuff from /dev.
am.QueueBuiltinAction(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
am.QueueBuiltinAction(keychord_init_action, "keychord_init");
am.QueueBuiltinAction(console_init_action, "console_init");
// Trigger all the boot actions to get us started.
am.QueueEventTrigger("init"); // 添加触发器init，执行on init内容，主要包括创建/挂在一些目录，以及symlink等
// Repeat mix_hwrng_into_linux_rng in case /dev/hw_random or /dev/random
// wasn't ready immediately after wait_for_coldboot_done
am.QueueBuiltinAction(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
// Don't mount filesystems or start core system services in charger mode.
if (bootmode == "charger") {
am.QueueEventTrigger("charger"); // on charger阶段
} ) == ) {
NOTICE("Booting into ffbm mode\n");
am.QueueEventTrigger("ffbm");
} else {
am.QueueEventTrigger("late-init"); // 非充电模式添加触发器last-init
}
// Run all property triggers based on current state of the properties.
am.QueueBuiltinAction(queue_property_triggers_action, "queue_property_triggers");
在last-init最后阶段有如下代码：
# Mount filesystems and start core system services.
on late-init
trigger early-fs
# Mount fstab in init.{$device}.rc by mount_all command. Optional parameter
# '--early' can be specified to skip entries with 'latemount'.
# /system and /vendor must be mounted by the end of the fs stage,
# while /data is optional.
trigger fs
trigger post-fs
# Load properties from /system/ + /factory after fs mount. Place
# this in another action so that the load will be scheduled after the prior
# issued fs triggers have completed.
trigger load_system_props_action
# Mount fstab in init.{$device}.rc by mount_all with '--late' parameter
# to only mount entries with 'latemount'. This is needed if '--early' is
# specified in the previous mount_all command on the fs stage.
# With /system mounted and properties form /system + /factory available,
# some services can be started.
trigger late-fs
# Now we can mount /data. File encryption requires keymaster to decrypt
# /data, which in turn can only be loaded when system properties are present.
trigger post-fs-data
# Load persist properties and override properties (if enabled) from /data.
trigger load_persist_props_action
# Remove a file to wake up anything waiting for firmware.
trigger firmware_mounts_complete
trigger early-boot
trigger boot
可见出发了on early-boot和on boot两个Action。
我们看一下on boot：
on boot
# basic network init
ifup lo
hostname localhost
domainname localdomain
... ...
class_start core
在on boot 的最后class_start core 会启动class为core的服务，这些服务包括ueventd、logd、healthd、adbd（disabled）、lmkd（LowMemoryKiller）、servicemanager、vold、debuggerd、surfaceflinger、bootanim（disabled）等。
回到主题，分析trigger触发器的代码，QueueEventTrigger()：位于system/core/init/action.cpp
void ActionManager::QueueEventTrigger(const std::string& trigger) {
trigger_queue_.push(std::make_unique<EventTrigger>(trigger));
}
此处QueueEventTrigger函数就是利用参数构造EventTrigger，然后加入到trigger_queue_中。后续init进程处理trigger事件时，将会触发相应的操作。
再看一下QueueBuiltinAction()函数：同样位于system/core/init/action.cpp
void ActionManager::QueueBuiltinAction(BuiltinFunction func,
const std::string& name) {
// 创建action
auto action = std::make_unique<Action>(true);
std::vector<std::string> name_vector{name};
// 保证唯一性
if (!action->InitSingleTrigger(name)) {
return;
}
// 创建action的cmd，指定执行函数和参数
action->AddCommand(func, name_vector);
trigger_queue_.push(std::make_unique<BuiltinTrigger>(action.get()));
actions_.emplace_back(std::move(action));
}
QueueBuiltinAction函数中构造新的action加入到actions_中，第一个参数作为新建action携带cmd的执行函数；第二个参数既作为action的trigger name，也作为action携带cmd的参数。
接下来继续分析main函数：
int main(int argc, char** argv) {
/* 01. 创建文件系统目录并挂载相关的文件系统 */
/* 02. 屏蔽标准的输入输出/初始化内核log系统 */
/* 03. 初始化属性域 */
/* 04. 完成SELinux相关工作 */•
/* 05. 重新设置属性 */
/* 06. 创建epoll句柄 */
/* 07. 装载子进程信号处理器 */
/* 08. 设置默认系统属性 */
/* 09. 启动配置属性的服务端 */
/* 10. 匹配命令和函数之间的对应关系 */ /* 11. 解析init.rc*/ /* 12. 向执行队列中添加其他action */------------------------------------------------------------------- /* 13. 处理添加到运行队列的事件 */ while (true) {
// 判断是否有事件需要处理
if (!waiting_for_exec) {
// 依次执行每个action中携带command对应的执行函数
am.ExecuteOneCommand();
// 重启一些挂掉的进程
restart_processes();
}
// 以下决定timeout的时间，将影响while循环的间隔
;
// 有进程需要重启时，等待该进程重启
if (process_needs_restart) {
timeout = (process_needs_restart - gettime()) * ;
)
timeout = ;
}
// 有action待处理，不等待
if (am.HasMoreCommands()) {
timeout = ;
}
// bootchart_sample应该是进行性能数据采样
bootchart_sample(&timeout);
epoll_event ev;
// 没有事件到来的话，最多阻塞timeout时间
, timeout));
) {
ERROR("epoll_wait failed: %s\n", strerror(errno));
} ) {
//有事件到来，执行对应处理函数
//根据上文知道，epoll句柄（即epoll_fd）主要监听子进程结束，及其它进程设置系统属性的请求
((void (*)()) ev.data.ptr)();
}
}
;
} // end main
看一下ExecuteOneComand()函数：同样位于system/core/init/action.cpp
void ActionManager::ExecuteOneCommand() {
// Loop through the trigger queue until we have an action to execute
// 当前的可执行action队列为空, trigger_queue_队列不为空
while (current_executing_actions_.empty() && !trigger_queue_.empty()) {
// 循环遍历action_队列,包含了所有需要执行的命令,解析init.rc获得
for (const auto& action : actions_) {
// 获取队头的trigger, 检查actions_列表中的action的trigger,对比是否相同
if (trigger_queue_.front()->CheckTriggers(*action)) {
// 将所有具有同一trigger的action加入当前可执行action队列
current_executing_actions_.emplace(action.get());
}
}
// 将队头trigger出栈
trigger_queue_.pop();
}
if (current_executing_actions_.empty()) { // 当前可执行的actions队列为空就返回
return;
}
auto action = current_executing_actions_.front(); // 获取当前可执行actions队列的首个action
) {
std::string trigger_name = action->BuildTriggersString();
INFO("processing action (%s)\n", trigger_name.c_str());
}
action->ExecuteOneCommand(current_command_); // 执行当前的命令
// If this was the last command in the current action, then remove
// the action from the executing list.
// If this action was oneshot, then also remove it from actions_.
++current_command_; // 不断叠加,将action_中的所有命令取出
if (current_command_ == action->NumCommands()) {
current_executing_actions_.pop();
current_command_ = ;
if (action->oneshot()) {
auto eraser = [&action] (std::unique_ptr<Action>& a) {
return a.get() == action;
};
actions_.erase(std::remove_if(actions_.begin(), actions_.end(), eraser));
}
}
}
我们来观察一下init.rc的开头部分：
import /init.environ.rc
import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.usb.configfs.rc
import /init.${ro.zygote}.rc // 后面我们即将重点分析zygote进程
通过ro.zygote的属性import对应的zygote的rc文件。
我们查看init.zygote64_32.rc：
service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server --socket-name=zygote
class main
socket zygote stream root system
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
onrestart restart audioserver
onrestart restart cameraserver
onrestart restart media
onrestart restart netd
writepid /dev/cpuset/foreground/tasks
service zygote_secondary /system/bin/app_process32 -Xzygote /system/bin --zygote --socket-name=zygote_secondary
class main
socket zygote_secondary stream root system
onrestart restart zygote
writepid /dev/cpuset/foreground/tasks
可以看到zygote的class是main, 它是在on nonencrypted时被启动的，如下：
on boot
# basic network init
ifup lo
hostname localhost
domainname localdomain
... ...
class_start core
on nonencrypted
# A/B update verifier that marks a successful boot.
exec - root cache -- /system/bin/update_verifier nonencrypted
class_start main
class_start late_start
至此，Init.cpp的main函数分析完毕！init进程已经启动完成，一些重要的服务如core服务和main服务也都启动起来，并启动了zygote（/system/bin/app_process64）进程，zygote初始化时会创建虚拟机，启动systemserver等。