Android启动篇 — init原理（二）

========================================================          ========================================================

=              【原创文章】：参考部分博客内容，学习之余进行了大量的筛减细化分析                        =          =                          【特殊申明】：避讳抄袭侵权之嫌疑，特此说明，欢迎转载！                           =   
========================================================          ========================================================

【前言】

　　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等。