Android 系统启动--03：init进程

作者: DarcyZhou | 来源:发表于2023-10-10 10:04 被阅读0次

本文转载自：Android 10.0系统启动之init进程

本文基于Android 10.0源码分析（kernel/msm-4.19）

1.概述

init进程是linux系统中用户空间的第一个进程，进程号为1。当bootloader启动后再启动kernel，kernel启动完后，在用户空间启动init进程，再通过init进程，来读取init.rc中的相关配置，从而来启动其他相关进程以及其他操作。

init进程被赋予了很多重要工作，init进程启动主要分为两个阶段：

（1）第一个阶段

ueventd/watchdogd跳转及环境变量设置；
挂载文件系统并创建目录；
初始化日志输出、挂载分区设备；
启用SELinux安全策略；
开始第二阶段前的准备。

（2）第二个阶段

初始化属性系统；
执行SELinux第二阶段并恢复一些文件安全上下文；
新建epoll并初始化子进程终止信号处理函数；
设置其他系统属性并开启属性服务。

2.架构

2.1 init进程启动过程

系统启动3-1.PNG

Init进程是在Kernel启动后，启动的第一个用户空间进程，PID为1；
kernel_init启动后，完成一些init的初始化操作，然后去系统根目录下依次找ramdisk_execute_command和execute_command设置的应用程序，如果这两个目录都找不到，就依次去根目录下找 /sbin/init，/etc/init，/bin/init，/bin/sh这四个应用程序进行启动，只要这些应用程序有一个启动了，其他就不启动了；
Android系统一般会在根目录下放一个init的可执行文件，也就是说Linux系统的init进程在内核初始化完成后，就直接执行init这个文件。

2.2 init进程启动后工作

系统启动3-2.PNG

init进程启动后，首先挂载文件系统、再挂载相应的分区，启动SELinux安全策略，启动属性服务，解析rc文件，并启动相应属性服务进程，初始化epoll，依次设置signal、property、keychord这3个fd可读时相对应的回调函数。进入无线循环，用来响应各个进程的变化与重建。

3.kernel启动init进程

3.1 kernel_init

// kernel/msm-4.19/init/main.c
kernel_init()
    |
run_init_process(ramdisk_execute_command)  //运行可执行文件，启动init进程

// kernel/msm-4.19/init/main.c
static int __ref kernel_init(void *unused)
{
        kernel_init_freeable();//进行init进程的一些初始化操作
        /* need to finish all async __init code before freeing the memory */
        async_synchronize_full();//等待所有异步调用执行完成，在释放内存前，必须完成所有的异步 __init代码
        free_initmem();// 释放所有init.* 段中的内存
        mark_rodata_ro(); //arm64空实现
        system_state = SYSTEM_RUNNING;//设置系统状态为运行状态
        numa_default_policy(); //设定NUMA系统的默认内存访问策略

        flush_delayed_fput(); //释放所有延时的struct file结构体

        //ramdisk_execute_command的值为"/init"
        if (ramdisk_execute_command) {
                if (!run_init_process(ramdisk_execute_command)) //运行根目录下的init程序
                        return 0;
                pr_err("Failed to execute %s\n", ramdisk_execute_command);
        }

        /*
         * We try each of these until one succeeds.
         *
         * The Bourne shell can be used instead of init if we are
         * trying to recover a really broken machine.
         */
         //execute_command的值如果有定义就去根目录下找对应的应用程序,然后启动
        if (execute_command) {
                if (!run_init_process(execute_command))
                        return 0;
                pr_err("Failed to execute %s.  Attempting defaults...\n",
                        execute_command);
        }
        //如果ramdisk_execute_command和execute_command定义的应用程序都没有找到，
        //就到根目录下找 /sbin/init，/etc/init，/bin/init,/bin/sh 这四个应用程序进行启动
        if (!run_init_process("/sbin/init") || 
            !run_init_process("/etc/init") ||
            !run_init_process("/bin/init") ||
            !run_init_process("/bin/sh"))
                return 0;

        panic("No init found.  Try passing init= option to kernel. "
              "See Linux Documentation/init.txt for guidance.");
}

3.2 do_basic_setup

kernel_init_freeable（）
      |
do_basic_setup（）

// kernel/msm-4.19/init/main.c
static void __init do_basic_setup(void)
{
        cpuset_init_smp();//针对SMP系统，初始化内核control group的cpuset子系统。
        usermodehelper_init();// 创建khelper单线程工作队列，用于协助新建和运行用户空间程序
        shmem_init();// 初始化共享内存
        driver_init();// 初始化设备驱动
        init_irq_proc();//创建/proc/irq目录, 并初始化系统中所有中断对应的子目录
        do_ctors();// 执行内核的构造函数
        usermodehelper_enable();// 启用usermodehelper
        do_initcalls();//遍历initcall_levels数组，调用里面的initcall函数，这里主要是对设备、驱动、文件系统进行初始化，
        //之所有将函数封装到数组进行遍历，主要是为了好扩展

        random_int_secret_init();//初始化随机数生成池
}

4.init进程启动源码分析

涉及源码文件：

/system/core/init/main.cpp
/system/core/init/init.cpp
/system/core/init/ueventd.cpp
/system/core/init/selinux.cpp
/system/core/init/subcontext.cpp
/system/core/base/logging.cpp
/system/core/init/first_stage_init.cpp
/system/core/init/first_stage_main.cpp
/system/core/init/first_stage_mount.cpp
/system/core/init/keyutils.h
/system/core/init/property_service.cpp
/external/selinux/libselinux/src/label.c
/system/core/init/signal_handler.cpp
/system/core/init/service.cpp

4.1 init进程入口

前面已经通过kernel_init，启动了init进程，init进程属于一个守护进程。准确的说，它是Linux系统中用户控制的第一个进程，它的进程号为1。它的生命周期贯穿整个Linux内核运行的始终。Android中所有其它的进程共同的鼻祖均为init进程。

可以通过"adb shell ps | grep init" 的命令来查看init的进程号。

Android Q(10.0) 的init入口函数由原先的init.cpp调整到了main.cpp，把各个阶段的操作分离开来，使代码更加简洁命令，接下来我们就从main函数开始学习。

// system/core/init/main.cpp
/*
 * 1.第一个参数argc表示参数个数，第二个参数是参数列表，也就是具体的参数
 * 2.main函数有四个参数入口，
 *一是参数中有ueventd，进入ueventd_main
 *二是参数中有subcontext，进入InitLogging 和SubcontextMain
 *三是参数中有selinux_setup，进入SetupSelinux
 *四是参数中有second_stage，进入SecondStageMain
 *3.main的执行顺序如下：
   *  (1)ueventd_main    init进程创建子进程ueventd，
   *      并将创建设备节点文件的工作托付给ueventd，ueventd通过两种方式创建设备节点文件
   *  (2)FirstStageMain  启动第一阶段
   *  (3)SetupSelinux     加载selinux规则，并设置selinux日志,完成SELinux相关工作
   *  (4)SecondStageMain  启动第二阶段
 */
int main(int argc, char** argv) {
    //当argv[0]的内容为ueventd时，strcmp的值为0,！strcmp为1
    //1表示true，也就执行ueventd_main,ueventd主要是负责设备节点的创建、权限设定等一些列工作
    if (!strcmp(basename(argv[0]), "ueventd")) {
        return ueventd_main(argc, argv);
    }

   //当传入的参数个数大于1时，执行下面的几个操作
    if (argc > 1) {
        //参数为subcontext，初始化日志系统，
        if (!strcmp(argv[1], "subcontext")) {
            android::base::InitLogging(argv, &android::base::KernelLogger);
            const BuiltinFunctionMap function_map;
            return SubcontextMain(argc, argv, &function_map);
        }

      //参数为“selinux_setup”,启动Selinux安全策略
        if (!strcmp(argv[1], "selinux_setup")) {
            return SetupSelinux(argv);
        }
       //参数为“second_stage”,启动init进程第二阶段
        if (!strcmp(argv[1], "second_stage")) {
            return SecondStageMain(argc, argv);
        }
    }
    // 默认启动init进程第一阶段
    return FirstStageMain(argc, argv);
}

4.2 ueventd_main()

Android根文件系统的镜像中不存在“/dev”目录，该目录是init进程启动后动态创建的。因此，建立Android中设备节点文件的重任，也落在了init进程身上。为此，init进程创建子进程ueventd，并将创建设备节点文件的工作托付给ueventd。

ueventd通过两种方式创建设备节点文件。

第一种方式对应“冷插拔”（Cold Plug），即以预先定义的设备信息为基础，当ueventd启动后，统一创建设备节点文件。这一类设备节点文件也被称为静态节点文件。
第二种方式对应“热插拔”（Hot Plug），即在系统运行中，当有设备插入USB端口时，ueventd就会接收到这一事件，为插入的设备动态创建设备节点文件。这一类设备节点文件也被称为动态节点文件。

// system/core/init/ueventd.cpp
int ueventd_main(int argc, char** argv) {
    //设置新建文件的默认值,这个与chmod相反,这里相当于新建文件后的权限为666
    umask(000); 

    //初始化内核日志，位于节点/dev/kmsg, 此时logd、logcat进程还没有起来，
    //采用kernel的log系统，打开的设备节点/dev/kmsg， 那么可通过cat /dev/kmsg来获取内核log。
    android::base::InitLogging(argv, &android::base::KernelLogger);

    //注册selinux相关的用于打印log的回调函数
    SelinuxSetupKernelLogging(); 
    SelabelInitialize();

    //解析xml，根据不同SOC厂商获取不同的hardware rc文件
    auto ueventd_configuration = ParseConfig({"/ueventd.rc", "/vendor/ueventd.rc",
                                              "/odm/ueventd.rc", "/ueventd." + hardware + ".rc"});

    //冷启动
    if (access(COLDBOOT_DONE, F_OK) != 0) {
        ColdBoot cold_boot(uevent_listener, uevent_handlers);
        cold_boot.Run();
    }
    for (auto& uevent_handler : uevent_handlers) {
        uevent_handler->ColdbootDone();
    }

    //忽略子进程终止信号
    signal(SIGCHLD, SIG_IGN);
    // Reap and pending children that exited between the last call to waitpid() and setting SIG_IGN
    // for SIGCHLD above.
    //在最后一次调用waitpid()和为上面的sigchld设置SIG_IGN之间退出的获取和挂起的子级
    while (waitpid(-1, nullptr, WNOHANG) > 0) {
    }

    //监听来自驱动的uevent,进行“热插拔”处理
    uevent_listener.Poll([&uevent_handlers](const Uevent& uevent) {
        for (auto& uevent_handler : uevent_handlers) {
            uevent_handler->HandleUevent(uevent); //热启动，创建设备
        }
        return ListenerAction::kContinue;
    });
    return 0;
}

4.3 init进程启动第一阶段

init进程第一阶段做的主要工作是挂载分区，创建设备节点和一些关键目录，初始化日志输出系统，启用SELinux安全策略。

第一阶段完成以下内容：

创建文件系统目录并挂载相关的文件系统；
屏蔽标准的输入输出/初始化内核log系统。

4.3.1 FirstStageMain()

// system/core/init/first_stage_init.cpp
int FirstStageMain(int argc, char** argv) {
    //init crash时重启引导加载程序
    //这个函数主要作用将各种信号量，如SIGABRT,SIGBUS等的行为设置为SA_RESTART,一旦监听到这些信号即执行重启系统
    if (REBOOT_BOOTLOADER_ON_PANIC) {
        InstallRebootSignalHandlers();
    }
    //清空文件权限
    umask(0);

    CHECKCALL(clearenv());
    CHECKCALL(setenv("PATH", _PATH_DEFPATH, 1));

    //在RAM内存上获取基本的文件系统，剩余的被rc文件所用
    CHECKCALL(mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755"));
    CHECKCALL(mkdir("/dev/pts", 0755));
    CHECKCALL(mkdir("/dev/socket", 0755));
    CHECKCALL(mount("devpts", "/dev/pts", "devpts", 0, NULL));
#define MAKE_STR(x) __STRING(x)
    CHECKCALL(mount("proc", "/proc", "proc", 0, "hidepid=2,gid=" MAKE_STR(AID_READPROC)));
#undef MAKE_STR

    // 非特权应用不能使用Andrlid cmdline
    CHECKCALL(chmod("/proc/cmdline", 0440));
    gid_t groups[] = {AID_READPROC};
    CHECKCALL(setgroups(arraysize(groups), groups));
    CHECKCALL(mount("sysfs", "/sys", "sysfs", 0, NULL));
    CHECKCALL(mount("selinuxfs", "/sys/fs/selinux", "selinuxfs", 0, NULL));

    CHECKCALL(mknod("/dev/kmsg", S_IFCHR | 0600, makedev(1, 11)));

    if constexpr (WORLD_WRITABLE_KMSG) {
        CHECKCALL(mknod("/dev/kmsg_debug", S_IFCHR | 0622, makedev(1, 11)));
    }

    CHECKCALL(mknod("/dev/random", S_IFCHR | 0666, makedev(1, 8)));
    CHECKCALL(mknod("/dev/urandom", S_IFCHR | 0666, makedev(1, 9)));

    //这对于日志包装器是必需的，它在ueventd运行之前被调用
    CHECKCALL(mknod("/dev/ptmx", S_IFCHR | 0666, makedev(5, 2)));
    CHECKCALL(mknod("/dev/null", S_IFCHR | 0666, makedev(1, 3)));

    //在第一阶段挂在tmpfs、mnt/vendor、mount/product分区。其他的分区不需要在第一阶段加载，
    //只需要在第二阶段通过rc文件解析来加载。
    CHECKCALL(mount("tmpfs", "/mnt", "tmpfs", MS_NOEXEC | MS_NOSUID | MS_NODEV,
                    "mode=0755,uid=0,gid=1000"));

    //创建可供读写的vendor目录
    CHECKCALL(mkdir("/mnt/vendor", 0755));
    // /mnt/product is used to mount product-specific partitions that can not be
    // part of the product partition, e.g. because they are mounted read-write.
    CHECKCALL(mkdir("/mnt/product", 0755));

    // 挂载APEX，这在Android 10.0中特殊引入，用来解决碎片化问题，类似一种组件方式，对Treble的增强，
    // 不写谷歌特殊更新不需要完整升级整个系统版本，只需要像升级APK一样，进行APEX组件升级
    CHECKCALL(mount("tmpfs", "/apex", "tmpfs", MS_NOEXEC | MS_NOSUID | MS_NODEV,
                    "mode=0755,uid=0,gid=0"));

    // /debug_ramdisk is used to preserve additional files from the debug ramdisk
    CHECKCALL(mount("tmpfs", "/debug_ramdisk", "tmpfs", MS_NOEXEC | MS_NOSUID | MS_NODEV,
                    "mode=0755,uid=0,gid=0"));
#undef CHECKCALL

    //把标准输入、标准输出和标准错误重定向到空设备文件"/dev/null"
    SetStdioToDevNull(argv);
    //在/dev目录下挂载好 tmpfs 以及 kmsg 
    //这样就可以初始化 /kernel Log 系统，供用户打印log
    InitKernelLogging(argv);

    ...

    /* 初始化一些必须的分区
     *主要作用是去解析/proc/device-tree/firmware/android/fstab,
     * 然后得到"/system", "/vendor", "/odm"三个目录的挂载信息
     */
    if (!DoFirstStageMount()) {
        LOG(FATAL) << "Failed to mount required partitions early ...";
    }

    struct stat new_root_info;
    if (stat("/", &new_root_info) != 0) {
        PLOG(ERROR) << "Could not stat(\"/\"), not freeing ramdisk";
        old_root_dir.reset();
    }

    if (old_root_dir && old_root_info.st_dev != new_root_info.st_dev) {
        FreeRamdisk(old_root_dir.get(), old_root_info.st_dev);
    }

    SetInitAvbVersionInRecovery();

    static constexpr uint32_t kNanosecondsPerMillisecond = 1e6;
    uint64_t start_ms = start_time.time_since_epoch().count() / kNanosecondsPerMillisecond;
    setenv("INIT_STARTED_AT", std::to_string(start_ms).c_str(), 1);

    //启动init进程，传入参数selinux_steup
    //执行命令： /system/bin/init selinux_setup
    const char* path = "/system/bin/init";
    const char* args[] = {path, "selinux_setup", nullptr};
    execv(path, const_cast<char**>(args));
    PLOG(FATAL) << "execv(\"" << path << "\") failed";

    return 1;
}

4.4 加载SELinux规则

SELinux是「Security-Enhanced Linux」的简称，是美国国家安全局「NSA=The National Security Agency」和SCC（Secure Computing Corporation）开发的 Linux的一个扩张强制访问控制安全模块。在这种访问控制体系的限制下，进程只能访问那些在他的任务中所需要文件。

selinux有两种工作模式：

permissive：所有的操作都被允许（即没有MAC），但是如果违反权限的话，会记录日志，一般eng模式用；
enforcing：所有操作都会进行权限检查。一般user和user-debug模式用。

不管是security_setenforce还是security_getenforce都是去操作/sys/fs/selinux/enforce 文件，0表示permissive；1表示enforcing。

4.4.1 SetupSelinux()

初始化selinux，加载SELinux规则，配置SELinux相关log输出，并启动第二阶段。

// system/core/init/selinux.cpp
/*此函数初始化selinux，然后执行init以在init selinux中运行*/
int SetupSelinux(char** argv) {
    //初始化Kernel日志
    InitKernelLogging(argv);

    // Debug版本init crash时重启引导加载程序
    if (REBOOT_BOOTLOADER_ON_PANIC) {
        InstallRebootSignalHandlers();
    }

    //注册回调，用来设置需要写入kmsg的selinux日志
    SelinuxSetupKernelLogging();

    //加载SELinux规则
    SelinuxInitialize();

    /*
     *我们在内核域中，希望转换到init域。在其xattrs中存储selabel的文件系统（如ext4）不需要显式restorecon，
     *但其他文件系统需要。尤其是对于ramdisk，如对于a/b设备的恢复映像，这是必需要做的一步。
     *其实就是当前在内核域中，在加载Seliux后，需要重新执行init切换到C空间的用户态
     */
    if (selinux_android_restorecon("/system/bin/init", 0) == -1) {
        PLOG(FATAL) << "restorecon failed of /system/bin/init failed";
    }

    //准备启动init进程，传入参数second_stage
    const char* path = "/system/bin/init";
    const char* args[] = {path, "second_stage", nullptr};
    execv(path, const_cast<char**>(args));

    /*
     *执行 /system/bin/init second_stage, 进入第二阶段
     */
    PLOG(FATAL) << "execv(\"" << path << "\") failed";

    return 1;
}

4.4.2 SelinuxInitialize()

// system/core/init/selinux.cpp
/*加载selinux 规则*/
void SelinuxInitialize() {
    LOG(INFO) << "Loading SELinux policy";
    if (!LoadPolicy()) {
        LOG(FATAL) << "Unable to load SELinux policy";
    }

    //获取当前Kernel的工作模式
    bool kernel_enforcing = (security_getenforce() == 1);

    //获取工作模式的配置
    bool is_enforcing = IsEnforcing();

    //如果当前的工作模式与配置的不同，就将当前的工作模式改掉
    if (kernel_enforcing != is_enforcing) {
        if (security_setenforce(is_enforcing)) {
            PLOG(FATAL) << "security_setenforce(" << (is_enforcing ? "true" : "false")
                        << ") failed";
        }
    }

    if (auto result = WriteFile("/sys/fs/selinux/checkreqprot", "0"); !result) {
        LOG(FATAL) << "Unable to write to /sys/fs/selinux/checkreqprot: " << result.error();
    }
}

// system/core/init/selinux.cpp
/*
 *加载SELinux规则
 *这里区分了两种情况,这两种情况只是区分从哪里加载安全策略文件,
 *第一个是从 /vendor/etc/selinux/precompiled_sepolicy 读取,
 *第二个是从 /sepolicy 读取,他们最终都是调用selinux_android_load_policy_from_fd方法
 */
bool LoadPolicy() {
    return IsSplitPolicyDevice() ? LoadSplitPolicy() : LoadMonolithicPolicy();
}

4.5 init进程启动第二阶段

第二阶段主要内容：

创建进程会话密钥并初始化属性系统；
进行SELinux第二阶段并恢复一些文件安全上下文；
新建epoll并初始化子进程终止信号处理函数，详细看第五节-信号处理；
启动匹配属性的服务端，详细查看第六节-属性服务；
解析init.rc等文件，建立rc文件的action 、service，启动其他进程，详细查看第7节-rc文件解析。

系统启动3-3.png

4.5.1 SecondStageMain()

// system/core/init/init.cpp
int SecondStageMain(int argc, char** argv) {
    /* 
    *init crash时重启引导加载程序
    *这个函数主要作用将各种信号量，如SIGABRT,SIGBUS等的行为设置为SA_RESTART,一旦监听到这些信号即执行重启系统
    */
    if (REBOOT_BOOTLOADER_ON_PANIC) {
        InstallRebootSignalHandlers();
    }

    //把标准输入、标准输出和标准错误重定向到空设备文件"/dev/null"
    SetStdioToDevNull(argv);
    //在/dev目录下挂载好 tmpfs 以及 kmsg 
    //这样就可以初始化 /kernel Log 系统，供用户打印log
    InitKernelLogging(argv);
    LOG(INFO) << "init second stage started!";

    // 01\. 创建进程会话密钥并初始化属性系统
    keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 1);

    //创建 /dev/.booting 文件，就是个标记，表示booting进行中
    close(open("/dev/.booting", O_WRONLY | O_CREAT | O_CLOEXEC, 0000));

    //初始化属性系统，并从指定文件读取属性
    property_init();

    /*
     * 1.如果参数同时从命令行和DT传过来，DT的优先级总是大于命令行的
     * 2.DT即device-tree，中文意思是设备树，这里面记录自己的硬件配置和系统运行参数，
     */
    process_kernel_dt(); //处理DT属性
    process_kernel_cmdline(); //处理命令行属性

    //处理一些其他的属性
    export_kernel_boot_props();

    // Make the time that init started available for bootstat to log.
    property_set("ro.boottime.init", getenv("INIT_STARTED_AT"));
    property_set("ro.boottime.init.selinux", getenv("INIT_SELINUX_TOOK"));

    // Set libavb version for Framework-only OTA match in Treble build.
    const char* avb_version = getenv("INIT_AVB_VERSION");
    if (avb_version) property_set("ro.boot.avb_version", avb_version);

    // See if need to load debug props to allow adb root, when the device is unlocked.
    const char* force_debuggable_env = getenv("INIT_FORCE_DEBUGGABLE");
    if (force_debuggable_env && AvbHandle::IsDeviceUnlocked()) {
        load_debug_prop = "true"s == force_debuggable_env;
    }

    // 基于cmdline设置memcg属性
    bool memcg_enabled = android::base::GetBoolProperty("ro.boot.memcg",false);
    if (memcg_enabled) {
       // root memory control cgroup
       mkdir("/dev/memcg", 0700);
       chown("/dev/memcg",AID_ROOT,AID_SYSTEM);
       mount("none", "/dev/memcg", "cgroup", 0, "memory");
       // app mem cgroups, used by activity manager, lmkd and zygote
       mkdir("/dev/memcg/apps/",0755);
       chown("/dev/memcg/apps/",AID_SYSTEM,AID_SYSTEM);
       mkdir("/dev/memcg/system",0550);
       chown("/dev/memcg/system",AID_SYSTEM,AID_SYSTEM);
    }

    //清空这些环境变量，之前已经存到了系统属性中去了
    unsetenv("INIT_STARTED_AT");
    unsetenv("INIT_SELINUX_TOOK");
    unsetenv("INIT_AVB_VERSION");
    unsetenv("INIT_FORCE_DEBUGGABLE");

    // Now set up SELinux for second stage.
    SelinuxSetupKernelLogging();
    SelabelInitialize();

    /*
     * 02\. 进行SELinux第二阶段并恢复一些文件安全上下文 
     * 恢复相关文件的安全上下文,因为这些文件是在SELinux安全机制初始化前创建的，
     * 所以需要重新恢复上下文
     */
    SelinuxRestoreContext();

   /*
    * 03\. 新建epoll并初始化子进程终止信号处理函数
    *  创建epoll实例，并返回epoll的文件描述符
    */
    Epoll epoll;
    if (auto result = epoll.Open(); !result) {
        PLOG(FATAL) << result.error();
    }

    /* 
     *主要是创建handler处理子进程终止信号，注册一个signal到epoll进行监听
     *进行子继承处理
     */
    InstallSignalFdHandler(&epoll); // 5.1 分析

    // 进行默认属性配置相关的工作
    property_load_boot_defaults(load_debug_prop);
    UmountDebugRamdisk();
    fs_mgr_vendor_overlay_mount_all();
    export_oem_lock_status();

    /*
     *04\. 设置其他系统属性并开启系统属性服务
     */
    StartPropertyService(&epoll);
    MountHandler mount_handler(&epoll);

    //为USB存储设置udc Contorller, sys/class/udc
    set_usb_controller();

    // 匹配命令和函数之间的对应关系
    const BuiltinFunctionMap function_map;
    Action::set_function_map(&function_map);

    if (!SetupMountNamespaces()) {
        PLOG(FATAL) << "SetupMountNamespaces failed";
    }

    // 初始化文件上下文
    subcontexts = InitializeSubcontexts();

   /*
     *05 解析init.rc等文件，建立rc文件的action 、service，启动其他进程
     */
    ActionManager& am = ActionManager::GetInstance();
    ServiceList& sm = ServiceList::GetInstance();

    LoadBootScripts(am, sm); // 解析init.rc 7.6分析

    // Turning this on and letting the INFO logging be discarded adds 0.2s to
    // Nexus 9 boot time, so it's disabled by default.
    if (false) DumpState();

    // 当GSI脚本running时，确保GSI状态可用
    if (android::gsi::IsGsiRunning()) {
        property_set("ro.gsid.image_running", "1");
    } else {
        property_set("ro.gsid.image_running", "0");
    }

    am.QueueBuiltinAction(SetupCgroupsAction, "SetupCgroups");

    // 执行rc文件中触发器为 on early-init 的语句
    am.QueueEventTrigger("early-init");

    // 等冷插拔设备初始化完成
    am.QueueBuiltinAction(wait_for_coldboot_done_action, "wait_for_coldboot_done");

    // 开始查询来自 /dev的 action
    am.QueueBuiltinAction(MixHwrngIntoLinuxRngAction, "MixHwrngIntoLinuxRng");
    am.QueueBuiltinAction(SetMmapRndBitsAction, "SetMmapRndBits");
    am.QueueBuiltinAction(SetKptrRestrictAction, "SetKptrRestrict");

    // 设备组合键的初始化操作
    Keychords keychords;
    am.QueueBuiltinAction(
        [&epoll, &keychords](const BuiltinArguments& args) -> Result<Success> {
            for (const auto& svc : ServiceList::GetInstance()) {
                keychords.Register(svc->keycodes());
            }
            keychords.Start(&epoll, HandleKeychord);
            return Success();
        },
        "KeychordInit");

    //在屏幕上显示Android 静态LOGO
    am.QueueBuiltinAction(console_init_action, "console_init");

    // 执行rc文件中触发器为on init的语句
    am.QueueEventTrigger("init");

    // Starting the BoringSSL self test, for NIAP certification compliance.
    am.QueueBuiltinAction(StartBoringSslSelfTest, "StartBoringSslSelfTest");

    // 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(MixHwrngIntoLinuxRngAction, "MixHwrngIntoLinuxRng");

    // Initialize binder before bringing up other system services
    am.QueueBuiltinAction(InitBinder, "InitBinder");

    // 当设备处于充电模式时，不需要mount文件系统或者启动系统服务
    // 充电模式下，将charger加入执行队列，否则把late-init加入执行队列
    std::string bootmode = GetProperty("ro.bootmode", "");
    if (bootmode == "charger") {
        am.QueueEventTrigger("charger");
    } else {
        am.QueueEventTrigger("late-init");
    }

    // 基于属性当前状态 运行所有的属性触发器.
    am.QueueBuiltinAction(queue_property_triggers_action, "queue_property_triggers");

    while (true) {
        // By default, sleep until something happens.
        auto epoll_timeout = std::optional<std::chrono::milliseconds>{};

        if (do_shutdown && !shutting_down) {
            do_shutdown = false;
            if (HandlePowerctlMessage(shutdown_command)) {
                shutting_down = true;
            }
        }

        //依次执行每个action中携带command对应的执行函数
        if (!(waiting_for_prop || Service::is_exec_service_running())) {
            am.ExecuteOneCommand();
        }
        if (!(waiting_for_prop || Service::is_exec_service_running())) {
            if (!shutting_down) {
                auto next_process_action_time = HandleProcessActions();

                // If there's a process that needs restarting, wake up in time for that.
                if (next_process_action_time) {
                    epoll_timeout = std::chrono::ceil<std::chrono::milliseconds>(
                            *next_process_action_time - boot_clock::now());
                    if (*epoll_timeout < 0ms) epoll_timeout = 0ms;
                }
            }

            // If there's more work to do, wake up again immediately.
            if (am.HasMoreCommands()) epoll_timeout = 0ms;
        }

        // 循环等待事件发生
        if (auto result = epoll.Wait(epoll_timeout); !result) {
            LOG(ERROR) << result.error();
        }
    }

    return 0;
}

5.信号处理

init是一个守护进程，为了防止init的子进程成为僵尸进程(zombie process)，需要init在子进程在结束时获取子进程的结束码，通过结束码将程序表中的子进程移除，防止成为僵尸进程的子进程占用程序表的空间（程序表的空间达到上限时，系统就不能再启动新的进程了，会引起严重的系统问题）。

（1）子进程重启流程

系统启动3-4.png

（2）信号处理主要工作

初始化信号signal句柄；
循环处理子进程；
注册epoll句柄；
处理子进程终止。

注：EPOLL类似于POLL，是Linux中用来做事件触发的，跟EventBus功能差不多。linux很长的时间都在使用select来做事件触发，它是通过轮询来处理的，轮询的fd数目越多，自然耗时越多，对于大量的描述符处理，EPOLL更有优势。

5.1 InstallSignalFdHandler()

继续[4.5.1 SecondStageMain()]中的InstallSignalFdHandler()方法。在linux当中，父进程是通过捕捉SIGCHLD信号来得知子进程运行结束的情况，SIGCHLD信号会在子进程终止的时候发出，了解这些背景后，我们来看看init进程如何处理这个信号。

首先，新建一个sigaction结构体，sa_handler是信号处理函数，指向内核指定的函数指针SIG_DFL和Android 9.0及之前的版本不同，这里不再通过socket的读写句柄进行接收信号，改成了内核的信号处理函数SIG_DFL；
然后，sigaction(SIGCHLD, &act, nullptr) 这个是建立信号绑定关系，也就是说当监听到SIGCHLD信号时，由act这个sigaction结构体处理；
最后，RegisterHandler的作用就是signal_read_fd（之前的s[1]）收到信号，触发handle_signal。

综上所述，InstallSignalFdHandler函数的作用就是，接收到SIGCHLD信号时触发HandleSignalFd进行信号处理。

系统启动3-5.png

说明：该函数主要的作用是初始化子进程终止信号处理过程。

// system/core/init.cpp
static void InstallSignalFdHandler(Epoll* epoll) {

    // SA_NOCLDSTOP使init进程只有在其子进程终止时才会受到SIGCHLD信号
    const struct sigaction act { .sa_handler = SIG_DFL, .sa_flags = SA_NOCLDSTOP };
    sigaction(SIGCHLD, &act, nullptr);

    sigset_t mask;
    sigemptyset(&mask);
    sigaddset(&mask, SIGCHLD); 

    if (!IsRebootCapable()) {
        // 如果init不具有CAP_SYS_BOOT的能力，则它此时正值容器中运行
        // 在这种场景下，接收SIGTERM将会导致系统关闭
        sigaddset(&mask, SIGTERM);
    }

    if (sigprocmask(SIG_BLOCK, &mask, nullptr) == -1) {
        PLOG(FATAL) << "failed to block signals";
    }

    // 注册处理程序以解除对子进程中的信号的阻止
    const int result = pthread_atfork(nullptr, nullptr, &UnblockSignals);
    if (result != 0) {
        LOG(FATAL) << "Failed to register a fork handler: " << strerror(result);
    }

    //创建信号句柄
    signal_fd = signalfd(-1, &mask, SFD_CLOEXEC);
    if (signal_fd == -1) {
        PLOG(FATAL) << "failed to create signalfd";
    }

    //信号注册，当signal_fd收到信号时，触发HandleSignalFd
    if (auto result = epoll->RegisterHandler(signal_fd, HandleSignalFd); !result) {
        LOG(FATAL) << result.error();
    }
}

5.2 RegisterHandler()

信号注册，把fd句柄加入到epoll_fd_的监听队列中。

// system/core/epoll.cpp
Result<void> Epoll::RegisterHandler(int fd, std::function<void()> handler, uint32_t events) {
    if (!events) {
        return Error() << "Must specify events";
    }
    auto [it, inserted] = epoll_handlers_.emplace(fd, std::move(handler));
    if (!inserted) {
        return Error() << "Cannot specify two epoll handlers for a given FD";
    }
    epoll_event ev;
    ev.events = events;
    // std::map's iterators do not get invalidated until erased, so we use the
    // pointer to the std::function in the map directly for epoll_ctl.
    ev.data.ptr = reinterpret_cast<void*>(&it->second);
    // 将fd的可读事件加入到epoll_fd_的监听队列中
    if (epoll_ctl(epoll_fd_, EPOLL_CTL_ADD, fd, &ev) == -1) {
        Result<void> result = ErrnoError() << "epoll_ctl failed to add fd";
        epoll_handlers_.erase(fd);
        return result;
    }
    return {};
}

5.3 HandleSignalFd()

监控SIGCHLD信号，调用 ReapAnyOutstandingChildren来终止出现问题的子进程。

// system/core/init.cpp
static void HandleSignalFd() {
    signalfd_siginfo siginfo;
    ssize_t bytes_read = TEMP_FAILURE_RETRY(read(signal_fd, &siginfo, sizeof(siginfo)));
    if (bytes_read != sizeof(siginfo)) {
        PLOG(ERROR) << "Failed to read siginfo from signal_fd";
        return;
    }

   //监控SIGCHLD信号
    switch (siginfo.ssi_signo) {
        case SIGCHLD:
            ReapAnyOutstandingChildren(); // 终止出现问题的子进程
            break;
        case SIGTERM:
            HandleSigtermSignal(siginfo);
            break;
        default:
            PLOG(ERROR) << "signal_fd: received unexpected signal " << siginfo.ssi_signo;
            break;
    }
}

5.4 ReapOneProcess()

ReapOneProcess是最终的处理函数了，这个函数先用waitpid找出挂掉进程的pid，然后根据pid找到对应Service，最后调用Service的Reap方法清除资源，根据进程对应的类型，决定是否重启机器或重启进程。

// system/core/sigchld_handle.cpp
void ReapAnyOutstandingChildren() {
    while (ReapOneProcess()) {
    }
}
//-------------------------------------------------
static bool ReapOneProcess() {
    siginfo_t siginfo = {};
    //用waitpid函数获取状态发生变化的子进程pid
    //waitpid的标记为WNOHANG，即非阻塞，返回为正值就说明有进程挂掉了
    if (TEMP_FAILURE_RETRY(waitid(P_ALL, 0, &siginfo, WEXITED | WNOHANG | WNOWAIT)) != 0) {
        PLOG(ERROR) << "waitid failed";
        return false;
    }

    auto pid = siginfo.si_pid;
    if (pid == 0) return false;

    // 当我们知道当前有一个僵尸pid，我们使用scopeguard来清除该pid
    auto reaper = make_scope_guard([pid] { TEMP_FAILURE_RETRY(waitpid(pid, nullptr, WNOHANG)); });

    std::string name;
    std::string wait_string;
    Service* service = nullptr;

    if (SubcontextChildReap(pid)) {
        name = "Subcontext";
    } else {
        //通过pid找到对应的service
        service = ServiceList::GetInstance().FindService(pid, &Service::pid);

        if (service) {
            name = StringPrintf("Service '%s' (pid %d)", service->name().c_str(), pid);
            if (service->flags() & SVC_EXEC) {
                auto exec_duration = boot_clock::now() - service->time_started();
                auto exec_duration_ms =
                    std::chrono::duration_cast<std::chrono::milliseconds>(exec_duration).count();
                wait_string = StringPrintf(" waiting took %f seconds", exec_duration_ms / 1000.0f);
            } else if (service->flags() & SVC_ONESHOT) {
                auto exec_duration = boot_clock::now() - service->time_started();
                auto exec_duration_ms =
                        std::chrono::duration_cast<std::chrono::milliseconds>(exec_duration)
                                .count();
                wait_string = StringPrintf(" oneshot service took %f seconds in background",exec_duration_ms / 1000.0f);
            }
        } else {
            name = StringPrintf("Untracked pid %d", pid);
        }
    }

    if (siginfo.si_code == CLD_EXITED) {
        LOG(INFO) << name << " exited with status " << siginfo.si_status << wait_string;
    } else {
        LOG(INFO) << name << " received signal " << siginfo.si_status << wait_string;
    }

    //没有找到service，说明已经结束了，退出
    if (!service) return true;

    service->Reap(siginfo);//清除子进程相关的资源

    if (service->flags() & SVC_TEMPORARY) {
        ServiceList::GetInstance().RemoveService(*service); //移除该service
    }

    return true;
}

6.属性服务

我们在开发和调试过程中看到通过property_set可以轻松设置系统属性，那为什么这里还要启动一个属性服务呢？这里其实涉及到一些权限的问题，不是所有进程都可以随意修改任何的系统属性，Android将属性的设置统一交由init进程管理，其他进程不能直接修改属性，而只能通知init进程来修改，而在这过程中，init进程可以进行权限控制，我们来看看具体的流程。

6.1 property_init()

初始化属性系统，并从指定文件读取属性，并进行SELinux注册，进行属性权限控制清除缓存，这里主要是清除几个链表以及在内存中的映射，新建property_filename目录，这个目录的值为/dev/properties，然后就是调用CreateSerializedPropertyInfo加载一些系统属性的类别信息，最后将加载的链表写入文件并映射到内存。

// system/core/property_service.cpp
void property_init() {

    //设置SELinux回调，进行权限控制
    selinux_callback cb;
    cb.func_audit = PropertyAuditCallback;
    selinux_set_callback(SELINUX_CB_AUDIT, cb);

    mkdir("/dev/__properties__", S_IRWXU | S_IXGRP | S_IXOTH);
    CreateSerializedPropertyInfo();
    if (__system_property_area_init()) {
        LOG(FATAL) << "Failed to initialize property area";
    }
    if (!property_info_area.LoadDefaultPath()) {
        LOG(FATAL) << "Failed to load serialized property info file";
    }
}

通过CreateSerializedPropertyInfo来加载以下目录的contexts：

（1）与SELinux相关

/system/etc/selinux/plat_property_contexts

/vendor/etc/selinux/vendor_property_contexts

/vendor/etc/selinux/nonplat_property_contexts

/product/etc/selinux/product_property_contexts

/odm/etc/selinux/odm_property_contexts

（2）与SELinux无关

/plat_property_contexts

/vendor_property_contexts

/nonplat_property_contexts

/product_property_contexts

/odm_property_contexts

6.2 StartPropertyService()

该方法用于启动属性服务，首先创建一个socket并返回文件描述符，然后设置最大并发数为8，其他进程可以通过这个socket通知init进程修改系统属性，最后注册epoll事件，也就是当监听到property_set_fd改变时调用handle_property_set_fd。

// system/core/init.cpp
void StartPropertyService(Epoll* epoll) {
    property_set("ro.property_service.version", "2");

    //建立socket连接
    if (auto result = CreateSocket(PROP_SERVICE_NAME, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
                                   false, 0666, 0, 0, {})) {
        property_set_fd = *result;
    } else {
        PLOG(FATAL) << "start_property_service socket creation failed: " << result.error();
    }

    // 最大监听8个并发
    listen(property_set_fd, 8);

    // 注册property_set_fd，当收到句柄改变时，通过handle_property_set_fd来处理
    if (auto result = epoll->RegisterHandler(property_set_fd, handle_property_set_fd); !result) {
        PLOG(FATAL) << result.error();
    }
}

6.3 handle_property_set_fd()

建立socket连接，然后从socket中读取操作信息，根据不同的操作类型，调用HandlePropertySet做具体的操作。

// system/core/property_service.cpp
static void handle_property_set_fd() {
    static constexpr uint32_t kDefaultSocketTimeout = 2000; /* ms */

    // 等待客户端连接
    int s = accept4(property_set_fd, nullptr, nullptr, SOCK_CLOEXEC);
    if (s == -1) {
        return;
    }

    ucred cr;
    socklen_t cr_size = sizeof(cr);
    // 获取连接到此socket的进程的凭据
    if (getsockopt(s, SOL_SOCKET, SO_PEERCRED, &cr, &cr_size) < 0) {
        close(s);
        PLOG(ERROR) << "sys_prop: unable to get SO_PEERCRED";
        return;
    }

    // 建立socket连接
    SocketConnection socket(s, cr);
    uint32_t timeout_ms = kDefaultSocketTimeout;

    uint32_t cmd = 0;
    // 读取socket中的操作信息
    if (!socket.RecvUint32(&cmd, &timeout_ms)) {
        PLOG(ERROR) << "sys_prop: error while reading command from the socket";
        socket.SendUint32(PROP_ERROR_READ_CMD);
        return;
    }

    // 根据操作信息，执行对应处理,两者区别一个是以char形式读取，一个以String形式读取
    switch (cmd) {
    case PROP_MSG_SETPROP: {
        char prop_name[PROP_NAME_MAX];
        char prop_value[PROP_VALUE_MAX];

        if (!socket.RecvChars(prop_name, PROP_NAME_MAX, &timeout_ms) ||
            !socket.RecvChars(prop_value, PROP_VALUE_MAX, &timeout_ms)) {
          PLOG(ERROR) << "sys_prop(PROP_MSG_SETPROP): error while reading name/value from the socket";
          return;
        }

        prop_name[PROP_NAME_MAX-1] = 0;
        prop_value[PROP_VALUE_MAX-1] = 0;

        std::string source_context;
        if (!socket.GetSourceContext(&source_context)) {
            PLOG(ERROR) << "Unable to set property '" << prop_name << "': getpeercon() failed";
            return;
        }

        const auto& cr = socket.cred();
        std::string error;
        uint32_t result = HandlePropertySet(prop_name, prop_value, source_context, cr, &error);
        if (result != PROP_SUCCESS) {
            LOG(ERROR) << "Unable to set property '" << prop_name << "' from uid:" << cr.uid
                       << " gid:" << cr.gid << " pid:" << cr.pid << ": " << error;
        }

        break;
      }

    case PROP_MSG_SETPROP2: {
        std::string name;
        std::string value;
        if (!socket.RecvString(&name, &timeout_ms) ||
            !socket.RecvString(&value, &timeout_ms)) {
          PLOG(ERROR) << "sys_prop(PROP_MSG_SETPROP2): error while reading name/value from the socket";
          socket.SendUint32(PROP_ERROR_READ_DATA);
          return;
        }

        std::string source_context;
        if (!socket.GetSourceContext(&source_context)) {
            PLOG(ERROR) << "Unable to set property '" << name << "': getpeercon() failed";
            socket.SendUint32(PROP_ERROR_PERMISSION_DENIED);
            return;
        }

        const auto& cr = socket.cred();
        std::string error;
        uint32_t result = HandlePropertySet(name, value, source_context, cr, &error);
        if (result != PROP_SUCCESS) {
            LOG(ERROR) << "Unable to set property '" << name << "' from uid:" << cr.uid
                       << " gid:" << cr.gid << " pid:" << cr.pid << ": " << error;
        }
        socket.SendUint32(result);
        break;
      }

    default:
        LOG(ERROR) << "sys_prop: invalid command " << cmd;
        socket.SendUint32(PROP_ERROR_INVALID_CMD);
        break;
    }
}

6.4 HandlePropertySet()

HandlePropertySet是最终的处理函数，以"ctl"开头的key就做一些Service的Start，Stop，Restart操作，其他的就是调用property_set进行属性设置，不管是前者还是后者，都要进行SELinux安全性检查，只有该进程有操作权限才能执行相应操作。

// system/core/init/property_service.cpp
uint32_t HandlePropertySet(const std::string& name, const std::string& value,
                           const std::string& source_context, const ucred& cr, std::string* error) {
    // 检查权限
    if (auto ret = CheckPermissions(name, value, source_context, cr, error); ret != PROP_SUCCESS) {
        return ret;
    }

    // 以"ctl"开头的key就做一些Service的Start，Stop，Restart操作
    if (StartsWith(name, "ctl.")) {
        HandleControlMessage(name.c_str() + 4, value, cr.pid);
        return PROP_SUCCESS;
    }

    // sys.powerctl is a special property that is used to make the device reboot.  We want to log
    // any process that sets this property to be able to accurately blame the cause of a shutdown.
    if (name == "sys.powerctl") {
        std::string cmdline_path = StringPrintf("proc/%d/cmdline", cr.pid);
        std::string process_cmdline;
        std::string process_log_string;
        if (ReadFileToString(cmdline_path, &process_cmdline)) {
            // Since cmdline is null deliminated, .c_str() conveniently gives us just the process
            // path.
            process_log_string = StringPrintf(" (%s)", process_cmdline.c_str());
        }
        LOG(INFO) << "Received sys.powerctl='" << value << "' from pid: " << cr.pid
                  << process_log_string;
    }

    if (name == "selinux.restorecon_recursive") {
        return PropertySetAsync(name, value, RestoreconRecursiveAsync, error);
    }

    // 调用property_set进行属性设置    
    return PropertySet(name, value, error);
}

7.第三阶段init.rc

当属性服务建立完成后，init的自身功能基本就告一段落，接下来需要来启动其他的进程。但是init进程如何其他其他进程呢？其他进程都是一个二进制文件，我们可以直接通过exec的命令方式来启动，例如 ./system/bin/init second_stage，来启动init进程的第二阶段。但是Android系统有那么多的Native进程，如果都通过传exec在代码中一个个的来执行进程，那无疑是一个灾难性的设计。

在这个基础上Android推出了一个init.rc的机制，即类似通过读取配置文件的方式，来启动不同的进程。接下来我们就来看看init.rc是如何工作的。

init.rc是一个配置文件，内部由Android初始化语言编写（Android Init Language）编写的脚本；
init.rc在手机的目录：./init.rc；
init.rc主要包含五种类型语句：Action，Command，Service，Option，Import。

系统启动3-6.png

7.1 Action

动作表示了一组命令(commands)组成。动作包括一个触发器，决定了何时运行这个动作Action：通过触发器trigger，即以on开头的语句来决定执行相应的service的时机，具体有如下时机：

on early-init：在初始化早期阶段触发；
on init：在初始化阶段触发；
on late-init：在初始化晚期阶段触发；
on boot/charger：当系统启动/充电时触发；
on property:<key>=<value>：当属性值满足条件时触发。

7.2 Command

command是action的命令列表中的命令，或者是service中的选项onrestart的参数命令，命令将在所属事件发生时被一个个地执行。下面列举常用的命令：

class_start <service_class_name>：启动属于同一个class的所有服务；
class_stop <service_class_name> ：停止指定类的服务；
start <service_name>：启动指定的服务，若已启动则跳过；
stop <service_name>：停止正在运行的服务；
setprop <name> <value>：设置属性值；
mkdir <path>：创建指定目录；
symlink <target> <sym_link>：创建连接到<target>的<sym_link>符号链接；
write <path> <string>：向文件path中写入字符串；
exec： fork并执行，会阻塞init进程直到程序完毕；
exprot <name> <name>：设定环境变量；
loglevel <level>：设置log级别；
hostname <name> ：设置主机名；
import <filename> ：导入一个额外的init配置文件。

7.3 Service

服务Service，以 service开头，由init进程启动，一般运行在init的一个子进程，所以启动service前需要判断对应的可执行文件是否存在。命令：

service <name><pathname> [ <argument> ]* <option> <option>

参数	含义
<name>	表示此服务的名称
<pathname>	此服务所在路径因为是可执行文件，所以一定有存储路径。
<argument>	启动服务所带的参数
<option>	对此服务的约束选项

init生成的子进程，定义在rc文件，其中每一个service在启动时会通过fork方式生成子进程。例如：

service servicemanager /system/bin/servicemanager

代表的是服务名为servicemanager，服务执行的路径为/system/bin/servicemanager。

7.4 Options

Options是Service的可选项，与service配合使用。

disabled：不随class自动启动，只有根据service名才启动；
oneshot：service退出后不再重启；
user/group：设置执行服务的用户/用户组，默认都是root；
class：设置所属的类名，当所属类启动/退出时，服务也启动/停止，默认为default；
onrestart：当服务重启时执行相应命令；
socket：创建名为/dev/socket/<name>的socket；
critical：在规定时间内该service不断重启，则系统会重启并进入恢复模式。

注：default意味着disabled=false，oneshot=false，critical=false。

7.5 import

用来导入其他的rc文件，命令：

import <filename>

7.6 init.rc解析过程

回到[4.5.1 SecondStageMain()]中的LoadBootScripts()方法，开始对init.rc文件进行解析。

7.6.1 LoadBootScripts

如果没有特殊配置ro.boot.init_rc，则解析./init.rc把/system/etc/init，/product/etc/init，/product_services/etc/init，/odm/etc/init，/vendor/etc/init这几个路径加入init.rc之后解析的路径，在init.rc解析完成后，解析这些目录里的rc文件。

// system/core/init/init.cpp
static void LoadBootScripts(ActionManager& action_manager, ServiceList& service_list) {
    Parser parser = CreateParser(action_manager, service_list);

    std::string bootscript = GetProperty("ro.boot.init_rc", "");
    if (bootscript.empty()) {
        parser.ParseConfig("/init.rc");
        if (!parser.ParseConfig("/system/etc/init")) {
            late_import_paths.emplace_back("/system/etc/init");
        }
        if (!parser.ParseConfig("/product/etc/init")) {
            late_import_paths.emplace_back("/product/etc/init");
        }
        if (!parser.ParseConfig("/product_services/etc/init")) {
            late_import_paths.emplace_back("/product_services/etc/init");
        }
        if (!parser.ParseConfig("/odm/etc/init")) {
            late_import_paths.emplace_back("/odm/etc/init");
        }
        if (!parser.ParseConfig("/vendor/etc/init")) {
            late_import_paths.emplace_back("/vendor/etc/init");
        }
    } else {
        parser.ParseConfig(bootscript);
    }
}

Android7.0后，init.rc进行了拆分，每个服务都有自己的rc文件，它们基本上都被加载到/system/etc/init，/vendor/etc/init，/odm/etc/init等目录，等init.rc解析完成后，会来解析这些目录中的rc文件，用来执行相关的动作。

CreateParser()方法用于创建Parser解析对象，例如service、on、import对象。

// system/core/init/init.cpp
Parser CreateParser(ActionManager& action_manager, ServiceList& service_list) {
    Parser parser;

    parser.AddSectionParser(
            "service", std::make_unique<ServiceParser>(&service_list, subcontexts, std::nullopt));
    parser.AddSectionParser("on", std::make_unique<ActionParser>(&action_manager, subcontexts));
    parser.AddSectionParser("import", std::make_unique<ImportParser>(&parser));

    return parser;
}

7.6.2 执行Action动作

按顺序把相关Action加入触发器队列，按顺序为early-init -> init -> late-init。然后在循环中，执行所有触发器队列中Action带Command的执行函数。

am.QueueEventTrigger("early-init");
am.QueueEventTrigger("init");
am.QueueEventTrigger("late-init");
...
    while (true) {
        if (!(waiting_for_prop || Service::is_exec_service_running())) {
            am.ExecuteOneCommand();
        }
}

7.6.3 Zygote启动

从Android 5.0的版本开始，Android支持64位的编译，因此zygote本身也支持32位和64位。通过属性ro.zygote来控制不同版本的zygote进程启动。在init.rc的import段我们看到如下代码：

// system/core/rootdir/init.rc
import /init.${ro.zygote}.rc // 可以看出init.rc不再直接引入一个固定的文件，而是根据属性ro.zygote的内容来引入不同的文件

init.rc位于/system/core/rootdir下。在这个路径下还包括四个关于zygote的rc文件。分别是init.zygote32.rc，init.zygote32_64.rc，init.zygote64.rc，init.zygote64_32.rc，由硬件决定调用哪个文件。这里拿64位处理器为例，init.zygote64.rc的代码如下所示：

// system/core/rootdir/init.zygote64.rc
service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server
    # class是一个option，指定zygote服务的类型为main
    class main
    priority -20
    user root
    group root readproc reserved_disk
    # socket关键字表示一个option，创建一个名为dev/socket/zygote，类型为stream，权限为660的socket
    socket zygote stream 660 root system
    socket usap_pool_primary stream 660 root system
    # onrestart是一个option，说明在zygote重启时需要执行的command
    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
    onrestart restart wificond
    writepid /dev/cpuset/foreground/tasks

service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server 解析：

service zygote：init.zygote64.rc 中定义了一个zygote服务。init进程就是通过这个service名称来创建zygote进程。
/system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server解析：zygote这个服务，通过执行进行/system/bin/app_process64并传入4个参数进行运行：

参数1：-Xzygote 该参数将作为虚拟机启动时所需的参数；

参数2：/system/bin 代表虚拟机程序所在目录；

参数3：--zygote 指明以ZygoteInit.java类中的main函数作为虚拟机执行入口；

参数4：--start-system-server 告诉Zygote进程启动systemServer进程。

8.总结