Android Q 开机启动流程

https://www.it610.com/article/1304931662924124160.htm

 

Android Q 开机启动流程

---

• 开机启动概述：
• step 1: 上电开机
  • 长按power键后引导芯片开始从固化在ROM的预设代码处执行，加载引导程序(BootLoader)到RAM.
• step 2: BootLoader启动
  • 跳转到BootLoader的入口函数，开始执行BootLoader的代码.
  • 硬件初始化工作(硬件时钟、手机的主板等)
  • 完成初始化uart端口的操作
  • arch_init
  • target_init
  • apps_init
  • aboot_init
  • 跳转到内核入口函数start_kernel，启动内核.
• step 3: kernel 启动
  • 输出Linux版本信息（printk(linux_banner)）
  • 设置与体系结构相关的环境（setup_arch()）
  • 页表结构初始化（paging_init()）
  • 使用"arch/alpha/kernel/entry.S"中的入口点设置系统自陷入口（trap_init()）
  • 使用alpha_mv结构和entry.S入口初始化系统IRQ（init_IRQ()）
  • 核心进程调度器初始化（包括初始化几个缺省的Bottom-half，sched_init()）
  • 时间、定时器初始化（包括读取CMOS时钟、估测主频、初始化定时器中断等，time_init()）
  • 提取并分析核心启动参数（从环境变量中读取参数，设置相应标志位等待处理，（parse_options()）
  • 控制台初始化（为输出信息而先于PCI初始化，console_init()）
  • 剖析器数据结构初始化（prof_buffer和prof_len变量）
  • 核心Cache初始化（描述Cache信息的Cache，kmem_cache_init()）
  • 延迟校准（获得时钟jiffies与CPU主频ticks的延迟，calibrate_delay()）
  • 内存初始化（设置内存上下界和页表项初始值，mem_init()）
  • 创建和设置内部及通用cache（“slab_cache”，kmem_cache_sizes_init()）
  • 创建uid taskcount SLAB cache（“uid_cache”，uidcache_init()）
  • 创建文件cache（“files_cache”，filescache_init()）
  • 创建目录cache（“dentry_cache”，dcache_init()）
  • 创建与虚存相关的cache（“vm_area_struct”，“mm_struct”，vma_init()）
  • 块设备读写缓冲区初始化（同时创建"buffer_head"cache用户加速访问，buffer_init()）
  • 创建页cache（内存页hash表初始化，page_cache_init()）
  • 创建信号队列cache（“signal_queue”，signals_init()）
  • 初始化内存inode表（inode_init()）
  • 创建内存文件描述符表（“filp_cache”，file_table_init()）
  • 检查体系结构漏洞（对于alpha，此函数为空，check_bugs()）
  • SMP机器其余CPU（除当前引导CPU）初始化（对于没有配置SMP的内核，此函数为空，smp_init()）
  • 启动init过程（创建第一个核心线程，调用init()函数，原执行序列调用cpu_idle() 等待调度，init()）
• step4: init 启动
  • 创建文件系统目录并挂载相关的文件系统
  • 初始化log系统
  • 初始化/设置/启动属性相关的资源
  • 完成SELinux相关工作
  • 装载子进程信号处理器
  • 解析init.rc
  • atcion/service管理
  • 执行action和启动service，包括启动zygote
• step5: zygote进程启动
  • app_process64 启动
  • AndroidRuntime 启动
  • art 启动和初始化
  • zygote init 启动
  • 启动system_server
• step 6: system_server启动
  • 初始化和启动framework service
  • 启动常驻进程
  • 启动Home Activity

---

 

文章目录

• 1.bootloader 和kernel 启动概述
• 2.init 概述
• • 2.1 init进程的创建
  • 2.2 init main
  • • 2.2.1 FirstStageMain
    • 2.2.2 SetupSelinux
    • 2.2.3 SecondStageMain
  • 2.4 文件系统挂载
  • • 2.4.1 FirstStageMount
    • 2.4.2 do_mount_all
  • 2.5 init log系统
  • • 2.5.1 Init log输出流程
    • 2.5.2 Init log等级
  • 2.6 Selinux Init
  • 2.7 Start Property Service
  • • 2.7.1 Property初始化
    • 2.7.2 启动property service
  • 2.8 Rc文件语法与解析
  • • 2.8.1 Action
    • 2.8.2 Sevice
    • 2.8.3 Exce Command

 

1.bootloader 和kernel 启动概述

后续补充

2.init 概述

Init作为第一个user space的进程，它是所有Android系统native service的祖先，它的进程号是1。

不过我们会发现还有另外两个init进程号大于1的，这个在Android P以后专门为启动vendor分区的service

而搞出来的vendor init，不过目前高通平台没有使用它去fork vendor 分区进程。

vendor init

Init从最根本上讲，是为了引导/启动用户空间的各项service，而为了确保各个service能正常运行，又会创

建文件系统，设置权限，初始化属性等工作。比较细致的来划分的话，可以分为下面几项：

---

• 创建文件系统目录并挂载相关的文件系统
• 初始化log系统
• 初始化/设置/启动属性相关的资源
• 完成SELinux相关工作
• 装载子进程信号处理器
• 解析init.rc
• atcion/service管理

---

首先看看init是如何启动的。

2.1 init进程的创建

内核在启动初期，会调用跟平台架构相关的汇编代码，在构架相关的汇编代码运行完之后，程序跳入了构架无关的内核C语言代码：

init/main.c中的start_kernel函数，在这个函数中Linux内核开始真正进入初始化阶段。以arm64为例：

kernel/arch/arm64/kernel/head.S b start_kernel

这句汇编代码意思就是跳转到start_kernel函数。这个函数很长，这里截取跟init关系比较大的部分：

kernel/msm-4.19/init/main.c
531asmlinkage __visible void __init start_kernel(void)
532{
    ……  
    //init_task即手动创建的一个PCB（进程控制块）  
536	set_task_stack_end_magic(&init_task);
    ……  
737	/* Do the rest non-__init'ed, we're now alive */
738	rest_init();//剩余的初始化  
} 

这里列举的第一个函数，手动创建了kernel的第一个进程——idle进程。所谓手动，意思是没有调用fork

等系统调用，直接对一个task_struct(进程描述符)进行赋值，指定进程的PID号

继续来看rest_init，init进程的创建也是从这里开始的

397static noinline void __ref rest_init(void)
398{
399	struct task_struct *tsk;
400	int pid;  
    ……  
403	/*
404	 * We need to spawn init first so that it obtains pid 1, however
405	 * the init task will end up wanting to create kthreads, which, if
406	 * we schedule it before we create kthreadd, will OOPS.
407	 */
    //通过kernel_thread创建一个内核进程，进程跑函数是kernel_init；  
408	pid = kernel_thread(kernel_init, NULL, CLONE_FS); 
    ……  
}  

通过调用kernel_thread，1号进程被创建出来，但此时，它运行的还不是init，只有经过如下步骤，init才会

正式启动。中间调用的函数也比较多，还涉及到空间的切换，这里用一个图来表示：

2.2 init main

讲了init进程的创建过程，接下来看下init进程在做些什么。Init进程的入口是main函数，查看init的功能实现，

就从这个函数开始，这里首先来关注下文件系统挂载。
init main函数开头会根据启动参数的差别，根据入参不同分别执行不同的内容。

51int main(int argc, char** argv) {
56    if (!strcmp(basename(argv[0]), "ueventd")) {
57        return ueventd_main(argc, argv);
58    }
59
60    if (argc > 1) {
61        if (!strcmp(argv[1], "subcontext")) {
62            android::base::InitLogging(argv, &android::base::KernelLogger);
63            const BuiltinFunctionMap function_map;
64
65            return SubcontextMain(argc, argv, &function_map);
66        }
67
68        if (!strcmp(argv[1], "selinux_setup")) {
69            return SetupSelinux(argv);
70        }
71
72        if (!strcmp(argv[1], "second_stage")) {
73            return SecondStageMain(argc, argv);
74        }
75    }
76
77    return FirstStageMain(argc, argv);
78}

---

• No argv -> FirstStageMain

  没有参数的情况下是第一次进入init，在内核态执行init初始化

• selinux_setup -> SetupSelinux

  在FirstStageMain 执行结束后，会重新调用execv("/system/bin/init", “selinux_setup”),第二次进入init main 函数，执行SetupSelinux

• second_stage -> SecondStageMain

  执行完SetupSelinux会重新调用execv("/system/bin/init", “second_stage”)

• Ueventd --> ueventd_main

  ueventd.c与init.c被编译成了同一个可执行文件“/init”，并创建了软链接“/system/bin/ueventd”指向“/system/init”,

  所以start uevent的时候会其他init bin文件传入参数ueventd

• Subcontext --> SubcontextMain

  启动vendor_init的时候传入参数Subcontext

---

2.2.1 FirstStageMain

第一阶段主要是挂载分区和创建设备节点，关键目录，我们顺序介绍一些函数的作用，本文暂时先不做深入分析，后续再进行补充。

介绍一些概念

• mknod
• mount
• mkdir
• proc info
• linux sys
• sys介绍
• dup2

int FirstStageMain(int argc, char** argv) {
//清空文件权限
umask(0);

设置环境变量，_PATH_DEFPATH在bionic/libc/include/paths.h中有定义，主要是shell 启动bin文件的查找路径集合

setenv("PATH", _PATH_DEFPATH, 1)

接下来开始创建一些必要目录和进行挂载。
//使用tmpfs文件系统挂载dev目录
mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755") 
// 创建dev/pts目录 ：是远程登陆(telnet,ssh等)后创建的控制台设备文件所在的目录
mkdir("/dev/pts", 0755) 
//创建dev/socket目录，init会为一些native进程创建socket，会在该目录下生产对应的socket节点
mkdir("/dev/socket", 0755) 
//挂载dev/pts
mount("devpts", "/dev/pts", "devpts", 0, NULL) 
//挂载proc/目录
mount("proc", "/proc", "proc", 0, "hidepid=2,gid=" MAKE_STR(AID_READPROC)) 
chmod("/proc/cmdline", 0440)
//挂载sysfs文件系统在sys目录，用来访问内核信息
mount("sysfs", "/sys", "sysfs", 0, NULL)//
//挂载文件系统selinuxfs到目录/sys/fs/selinux ,下面放的都是selinux相关的目录和节点
mount("selinuxfs", "/sys/fs/selinux", "selinuxfs", 0, NULL)
//创建/dev/kmsg文件节点， 存到kenel log
mknod("/dev/kmsg", S_IFCHR | 0600, makedev(1, 11))
//节点/dev/random和/dev/urandom是Linux系统中提供的随机伪设备，这两个设备的任务，是提供永
//不为空的随机字节数据流。很多解密程序与安全应用程序（如SSH Keys,SSL Keys等）需要它们提供的随机数据流。
mknod("/dev/random", S_IFCHR | 0666, makedev(1, 8))
mknod("/dev/urandom", S_IFCHR | 0666, makedev(1, 9))
mknod("/dev/ptmx", S_IFCHR | 0666, makedev(5, 2))
mknod("/dev/null", S_IFCHR | 0666, makedev(1, 3))
//挂载tmpfs文件系统到mnt目录，这个目录正常是挂载光驱，usb设备的
mount("tmpfs", "/mnt", "tmpfs", MS_NOEXEC | MS_NOSUID | MS_NODEV, "mode=0755,uid=0,gid=1000")
mkdir("/mnt/vendor", 0755)
mkdir("/mnt/product", 0755)
mount("tmpfs", "/debug_ramdisk", "tmpfs", MS_NOEXEC | MS_NOSUID | MS_NODEV, "mode=0755,uid=0,gid=0")

//把标准输出，标准输入，标准错误输出重定向到dev/null
SetStdioToDevNull(argv);
//初始化init log并输出定向到dev/kmsg
InitKernelLogging(argv);
// Log 系统初始化结束后，开始输出Log
LOG(INFO) << "init first stage started!";

auto old_root_dir = std::unique_ptr{opendir("/"), closedir};
struct stat old_root_info;
stat("/", &old_root_info)

//根据配置决定是否打开串口
Modprobe m({"/lib/modules"});
//ALLOW_FIRST_STAGE_CONSOLE 在bp配置， 并且cmdline存在androidboot.first_stage_console=1
auto want_console = ALLOW_FIRST_STAGE_CONSOLE && FirstStageConsole(cmdline);
m.LoadListedModules(!want_console)
if (want_console) {
    StartConsole();
}

//对于将恢复用作 ramdisk 的设备，第一阶段 init 位于恢复 ramdisk 中的 /init。这些设备首先将根切换到 
//first_stage_ramdisk，以便从环境中移除恢复组件，然后执行与具有 boot-ramdisk 的设备一样的操作
//（即，将 system.img 作为 /system 进行装载，切换根以将该装载移动到 /，然后在装载完成后释放 ramdisk 内容）。
//如果内核命令行中存在 androidboot.force_normal_boot=1，则设备会正常启动（启动到 Android）而不是启动到恢复模式。
//介绍：https://source.android.google.cn/devices/bootloader/system-as-root?hl=zh-cn#ramdisk
if (ForceNormalBoot(cmdline)) {
	mkdir("/first_stage_ramdisk", 0755);
	// SwitchRoot() must be called with a mount point as the target, so we bind mount the
	// target directory to itself here.
	if (mount("/first_stage_ramdisk", "/first_stage_ramdisk", nullptr, MS_BIND, nullptr) != 0) {
		LOG(FATAL) << "Could not bind mount /first_stage_ramdisk to itself";
	}
	SwitchRoot("/first_stage_ramdisk");
}


// If force_debuggable file is present, the second-stage init will use a userdebug sepolicy
// and load adb_debug.prop to allow adb root, if the device is unlocked.
if (access("/force_debuggable", F_OK) == 0) {
	std::error_code ec;  // to invoke the overloaded copy_file() that won't throw.
	if (!fs::copy_file("/adb_debug.prop", kDebugRamdiskProp, ec) ||
		!fs::copy_file("/userdebug_plat_sepolicy.cil", kDebugRamdiskSEPolicy, ec)) {
		LOG(ERROR) << "Failed to setup debug ramdisk";
	} else {
		// setenv for second-stage init to read above kDebugRamdisk* files.
		setenv("INIT_FORCE_DEBUGGABLE", "true", 1);
	}
}

//第一阶段（即初始化 SElinux 之前）装载 /system、/vendor 或 /odm，这个主要是因为打开了Treble的设备上，为了确保
//init能及时导入SELinux的配置文件（contexts/*.te），需要尽快的将system/vendor等分区挂载上。
//这句话要对比AndroidN来理解：在AndroidN上，selinux的配置文件存放在boot.img中，在内核初始化过程中，boot.img中的文
//件已经挂载到rootfs了，相应的，配置文件也就可以从rootfs读取了。而AndroidO开始，selinux配置文件放到了vendor/system分区，
//如果仍然按照do_mount_all阶段来挂载这两个分区，selinux来不及做初始化。
DoFirstStageMount()
struct stat new_root_info;
stat("/", &new_root_info) != 0

//根目录发生变化，则释放ramdisk
if (old_root_dir && old_root_info.st_dev != new_root_info.st_dev) {
	FreeRamdisk(old_root_dir.get(), old_root_info.st_dev);
}

//Avb即Android Verfied boot,功能包括Secure Boot, verfying boot 和 dm-verity, 
//原理都是对二进制文件进行签名，在系统启动时进行认证，确保系统运行的是合法的二进制镜像文件。
//其中认证的范围涵盖：bootloader，boot.img，system.img
//此处是在recovery模式下初始化avb的版本,不是recovery模式直接跳过
SetInitAvbVersionInRecovery();

//设置环境变量FIRST_STAGE_STARTED_AT 当前时间
setenv(kEnvFirstStageStartedAt, std::to_string(start_time.time_since_epoch().count()).c_str(),1);
//通过execv 重新给该进程装载/system/bin/init，并携带参数selinux_setup 进入第二阶段
const char* path = "/system/bin/init";
const char* args[] = {path, "selinux_setup", nullptr};
auto fd = open("/dev/kmsg", O_WRONLY | O_CLOEXEC);
dup2(fd, STDOUT_FILENO);
dup2(fd, STDERR_FILENO);
close(fd);
execv(path, const_cast(args));
}

在第一阶段 init 完成后，它会使用 selinux_setup 参数执行 /system/bin/init，以便编译 SELinux 并将其加载到系统中。
最后，init 会使用 second_stage 参数再次执行 /system/bin/init。此时，init 的主要阶段将会运行，并使用 init.rc 脚本继续执行启动过程。

2.2.2 SetupSelinux

主要是初始化selinux，加载selinux规则配置文件，并设置selinux日志

int SetupSelinux(char** argv) {
	//因为execv会将新的bin文件替换之前进程的内存空间，所以下面操作需要重新做
    SetStdioToDevNull(argv);
    InitKernelLogging(argv);

    if (REBOOT_BOOTLOADER_ON_PANIC) {
        InstallRebootSignalHandlers();
    }

    boot_clock::time_point start_time = boot_clock::now();
	
    // Set up SELinux, loading the SELinux policy.
    //注册回调，用来设置需要写入kmsg的selinux日志
    SelinuxSetupKernelLogging();
    //加载SELinux规则配置文件
    SelinuxInitialize();

    // We're in the kernel domain and want to transition to the init domain.  File systems that
    // store SELabels in their xattrs, such as ext4 do not need an explicit restorecon here,
    // but other file systems do.  In particular, this is needed for ramdisks such as the
    // recovery image for A/B devices.
	//在做完selinux的初始化后，需要切换init进程到用户态。
    if (selinux_android_restorecon("/system/bin/init", 0) == -1) {
        PLOG(FATAL) << "restorecon failed of /system/bin/init failed";
    }
	//设置环境变量FIRST_STAGE_STARTED_AT 当前时间
    setenv(kEnvSelinuxStartedAt, std::to_string(start_time.time_since_epoch().count()).c_str(), 1);
	//通过execv 重新给该进程装载/system/bin/init，并携带参数second_stage 进入第三阶段
    const char* path = "/system/bin/init";
    const char* args[] = {path, "second_stage", nullptr};
    execv(path, const_cast(args));

    // execv() only returns if an error happened, in which case we
    // panic and never return from this function.
    PLOG(FATAL) << "execv(\"" << path << "\") failed";

    return 1;
}

2.2.3 SecondStageMain

这个阶段主要就是注册子进程信号处理器，初始化Property系统，解析rc文件，执行action和启动service操作

int SecondStageMain(int argc, char** argv) {
    if (REBOOT_BOOTLOADER_ON_PANIC) {
        InstallRebootSignalHandlers();
    }

    boot_clock::time_point start_time = boot_clock::now();

    trigger_shutdown = TriggerShutdown;

    SetStdioToDevNull(argv);
    InitKernelLogging(argv);
    LOG(INFO) << "init second stage started!";

    // Will handle EPIPE at the time of write by checking the errno
	//SIG_IGN作用是忽略对应信号的处理，这里是为了忽略SIGPIPE信号异常
    signal(SIGPIPE, SIG_IGN);

    // Set init and its forked children's oom_adj.
	//设置init 进程自己的oomadj值-1000
    if (auto result =
                WriteFile("/proc/1/oom_score_adj", StringPrintf("%d", DEFAULT_OOM_SCORE_ADJUST));
        !result.ok()) {
        LOG(ERROR) << "Unable to write " << DEFAULT_OOM_SCORE_ADJUST
                   << " to /proc/1/oom_score_adj: " << result.error();
    }

    // Set up a session keyring that all processes will have access to. It
    // will hold things like FBE encryption keys. No process should override
    // its session keyring.
	//初始化进程会话密钥
    keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 1);

    // Indicate that booting is in progress to background fw loaders, etc.
	//创建 /dev/.booting 文件，就是个标记，表示booting进行中
    close(open("/dev/.booting", O_WRONLY | O_CREAT | O_CLOEXEC, 0000));

    // See if need to load debug props to allow adb root, when the device is unlocked.
	//读取INIT_FORCE_DEBUGGABLE，这个是在第一阶段设置的，也就是debug ramdisk setup成功。
    const char* force_debuggable_env = getenv("INIT_FORCE_DEBUGGABLE");
    bool load_debug_prop = false;
    if (force_debuggable_env && AvbHandle::IsDeviceUnlocked()) {
        load_debug_prop = "true"s == force_debuggable_env;
    }
    unsetenv("INIT_FORCE_DEBUGGABLE");

    // Umount the debug ramdisk so property service doesn't read .prop files from there, when it
    // is not meant to.
	//如果force_debuggable没有开启，需要先ummount ramdisk，避免property初始话的时候读取.prop文件
    if (!load_debug_prop) {
        UmountDebugRamdisk();
    }
	//Property子系统初始化，这个管理存储和获取Property 属性
    PropertyInit();

    // Umount the debug ramdisk after property service has read the .prop files when it means to.
	//再ummount ramdisk
    if (load_debug_prop) {
        UmountDebugRamdisk();
    }

    // Mount extra filesystems required during second stage init
	//这里面主要挂载apex和linkerconfig
    MountExtraFilesystems();

    // Now set up SELinux for second stage.
	//注册回调，用来设置需要写入kmsg的selinux日志
    SelinuxSetupKernelLogging();
	设置sehandle为selinux_android_set_sehandle
    SelabelInitialize();
	//进行SELinux第二阶段并恢复一些文件安全上下文 
    //恢复相关文件的安全上下文,因为这些文件是在SELinux安全机制初始化前创建的，
    //所以需要重新恢复上下文
    SelinuxRestoreContext();
	
	//创建epoll实例，并返回epoll的文件描述符，实现init的一些事件监控
    Epoll epoll;
    if (auto result = epoll.Open(); !result.ok()) {
        PLOG(FATAL) << result.error();
    }
	
	//监控子进程的SIGCHLD和SIGTERM信号，并在收到信号后通过HandleSignalFd函数处理
    InstallSignalFdHandler(&epoll);
	
    //主要创建property_set_fd socket并通过pool监控它，当来设置property的请求后，通过handle_property_set_fd去处理。
    StartPropertyService(&property_fd);
    if (auto result = epoll.RegisterHandler(property_fd, HandlePropertyFd); !result.ok()) {
        LOG(FATAL) << "Could not register epoll handler for property fd: " << result.error();
    }

    // Make the time that init stages started available for bootstat to log.
    RecordStageBoottimes(start_time);

    // Set libavb version for Framework-only OTA match in Treble build.
	// INIT_AVB_VERSION 设置给ro.boot.avb_version
    if (const char* avb_version = getenv("INIT_AVB_VERSION"); avb_version != nullptr) {
        SetProperty("ro.boot.avb_version", avb_version);
    }
    unsetenv("INIT_AVB_VERSION");
	// 主要是根据ro.vndk.version 版本号，将/system/vendor_overlay/"和/product/vendor_overlay/挂载在vendor上
    fs_mgr_vendor_overlay_mount_all();
	//ro.oem_unlock_supported 属性应在编译时根据设备是否支持刷写解锁来设置。 如果设备不支持刷写解锁，应将 ro.oem_unlock_supported 设置为“0”；如果支持刷写解锁，应将其设置为“1”。
    //如果设备支持刷写解锁（即 ro.oem_unlock_supported = 1），则引导加载程序应通过将内核命令行变量 androidboot.flash.locked（或 /firmware/android/flash.locked DT 属性）设置为“1”（如果已锁定）或“0”（如果已解锁）来指示锁定状态。
    export_oem_lock_status();
	//监控/proc/mounts 节点，发生变化也就是有新分区mount的时候执行MountHandlerFunction函数
    MountHandler mount_handler(&epoll);
	//读取/sys/class/udc目录的文件也就是USB设备控制器的节点，设置给属性sys.usb.controller，从而使得USB主机端可以正常枚举到该USB设备
    set_usb_controller();
	//获取函数的BuiltinFunctionMap表,BuiltinFunctionMap 对象是一个KeywordMap数据结构
    //在BuiltinFunctionMap初始化的时候，创建一个pair表，存储字符串和对应的MapValue数据结果，MapValue 里面存储函数最大参数，最小参数，
    //以及BuiltinFunctionMapValue 数据结果，这样我们通过传入字符串，然后调用function_map的Find函数返回BuiltinFunctionMapValue
    //BuiltinFunctionMapValue 则保存了对应的函数 function对象，以便调用该函数。总结下：就是可以根据函数的字符串简称，找到对应函数入口，去调用该函数
    const BuiltinFunctionMap& function_map = GetBuiltinFunctionMap();
	初始化Action的function_map_ 为刚才的函数表，以便于后续执行Aciton 调用对应函数
    Action::set_function_map(&function_map);

	//这个主要设置./ apex 这些分区的挂载信息权限的。这块可以参考资料：https://cizixs.com/2017/08/29/linux-namespace/
    if (!SetupMountNamespaces()) {
        PLOG(FATAL) << "SetupMountNamespaces failed";
    }
	//android P版本以上，给vendor oem增加u:r:vendor_init:s0权限
    subcontext = InitializeSubcontext();

	//下面主要是解析RC文件操作了，LoadBootScripts中主要依靠ActionManager和ServiceList 解析RC文件的Action和Service，这个后边单独章节去讲
    ActionManager& am = ActionManager::GetInstance();//构造解析action对象
    ServiceList& sm = ServiceList::GetInstance();//构造管理服务对象  
	
    LoadBootScripts(am, sm);

    // Turning this on and letting the INFO logging be discarded adds 0.2s to
    // Nexus 9 boot time, so it's disabled by default.
	//把解析并维护起来的Action service dump出来用去debug
    if (false) DumpState();

    // Make the GSI status available before scripts start running.
	//GSI 是google 原生代码的镜像，一般用于VTS测试
    if (android::gsi::IsGsiRunning()) {
        SetProperty("ro.gsid.image_running", "1");
    } else {
        SetProperty("ro.gsid.image_running", "0");
    }
	
	//在ActionManager的队列中依次加入Action和Trigger
    am.QueueBuiltinAction(SetupCgroupsAction, "SetupCgroups");
    am.QueueBuiltinAction(SetKptrRestrictAction, "SetKptrRestrict");
    am.QueueBuiltinAction(TestPerfEventSelinuxAction, "TestPerfEventSelinux");
    am.QueueEventTrigger("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(MixHwrngIntoLinuxRngAction, "MixHwrngIntoLinuxRng");
    am.QueueBuiltinAction(SetMmapRndBitsAction, "SetMmapRndBits");
    Keychords keychords;
    am.QueueBuiltinAction(
            [&epoll, &keychords](const BuiltinArguments& args) -> Result {
                for (const auto& svc : ServiceList::GetInstance()) {
                    keychords.Register(svc->keycodes());
                }
                keychords.Start(&epoll, HandleKeychord);
                return {};
            },
            "KeychordInit");

    // Trigger all the boot actions to get us started.
    am.QueueEventTrigger("init");

    // 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");

    // Don't mount filesystems or start core system services in charger mode.
    std::string bootmode = GetProperty("ro.bootmode", "");
    if (bootmode == "charger") {
        am.QueueEventTrigger("charger");
    } else {
        am.QueueEventTrigger("late-init");
    }

    // Run all property triggers based on current state of the properties.
    am.QueueBuiltinAction(queue_property_triggers_action, "queue_property_triggers");

    while (true) {
        // By default, sleep until something happens.
        auto epoll_timeout = std::optional{};
		//发起重启，sys.powerctl 发生变化会do_shutdown置为true
        if (do_shutdown && !IsShuttingDown()) {
            do_shutdown = false;
            HandlePowerctlMessage(shutdown_command);
        }
		
        //当前没有事件需要处理时  
        if (!(waiting_for_prop || Service::is_exec_service_running())) {
			//am 队列中依次执行每个action中携带command对应的执行函数  
            am.ExecuteOneCommand();
        }
        if (!IsShuttingDown()) {
			//重启死掉的子进程
            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) {
                //决定timeout的时间，将影响while循环的间隔  
                epoll_timeout = std::chrono::ceil(
                        *next_process_action_time - boot_clock::now());
                if (*epoll_timeout < 0ms) epoll_timeout = 0ms;
            }
        }

        if (!(waiting_for_prop || Service::is_exec_service_running())) {
            // If there's more work to do, wake up again immediately.
			//有command等着处理的话，不等待
            if (am.HasMoreCommands()) epoll_timeout = 0ms;
        }
		//没有事件到来的话，最多阻塞epoll_timeout_ms时间  
        auto pending_functions = epoll.Wait(epoll_timeout);
        if (!pending_functions.ok()) {
            LOG(ERROR) << pending_functions.error();
        } else if (!pending_functions->empty()) {
            // We always reap children before responding to the other pending functions. This is to
            // prevent a race where other daemons see that a service has exited and ask init to
            // start it again via ctl.start before init has reaped it.
			//1.  //有事件到来，执行对应处理函数  
            //根据上文知道，epoll句柄（即epoll_fd）主要监听子进程结束，及其它进程设置系统属性的请求。  
            ReapAnyOutstandingChildren();
            for (const auto& function : *pending_functions) {
                (*function)();
            }
        }
    }

    return 0;
}

2.4 文件系统挂载

2.4.1 FirstStageMount

android有很多分区，如"syste",“userdata”,“cache”，AndroidO 之后还新增了vendor/odm等新的分区，它们是何时挂载的？如何挂载的？
在Android8.0以前，挂载是通过触发do_mount_all来做的。从Andriod8.0开始，以前由do_mount_all来做的事情现在分成了两部分，新增了FirstStageMount，将system/vendor/odm分区挂载放在FSM阶段来做；而其它分区的挂载，仍然在do_mount_all阶段。之所以提前挂载system和vendor我们前文也有说明是为了在打开了Treble的设备上，确保init能及时导入SELinux的配置文件（contexts/*.te），需要尽快的将system/vendor等分区挂载上。
主要是对比AndroidN来理解：在AndroidN上，selinux的配置文件存放在boot.img中，在内核初始化过程中，boot.img中的文件已经挂载到rootfs了，相应的，配置文件也就可以从rootfs读取了。而AndroidO开始，selinux配置文件放到了vendor/system分区，如果仍然按照do_mount_all阶段来挂载这两个分区，selinux来不及做初始化。

这块流程暂时没有重新整理，先附上android O的流程，比较相近

2.4.2 do_mount_all

在文件系统挂载的第一阶段，system/vendor分区已经成功挂载，而其它分区的挂载则通过do_mount_all来实现。看下这个流程：

common/rootdir/root/init.common.rc中就有如下规则：
1. on fs  
2.     ubiattach 0 ubipac  
3.     # exec /sbin/resize2fs -ef /fstab.${ro.hardware}  
4.     mount_all /fstab.${ro.hardware}  
5.     mount pstore pstore /sys/fs/pstore  

mount_all是一条命令，fstab.${ro.hardware}是传入的参数。

接着通过ActionManager来解析“mount_all指令“，找到指令所对应的解析函数。

这个指令解析函数的对应关系，定义在system/core/init/builtins.cpp:

1. static const Map builtin_functions = {  
2. .....  
3. {  
4.     "mount_all",               {1,     kMax, do_mount_all}},  
5.     .....  
6. }  

从上面可以看出，mount_all命令对应的是do_mount_all函数，xxxx是do_mount_all函数的传入参数。

2.5 init log系统

熟悉init模块的话，会知道Android系统中，init的log会出现在kernel log中。

理论上，init是属于user space的，为何log出现在kernel log系统中？顺带的还有其他几个问题：

1、 kernel log与init log都有log等级，两者有对应关系吗？

2、 Kernel log可以调整loglevel来控制log输出，init可以吗？

下面带着这些问题，来了解init log系统。

2.5.1 Init log输出流程

要了解init log，最好的方法莫过于分析log输出的流程。例如下面这句log：

1. LOG(INFO) << “init first stage started!”;

函数中传递的参数是log level。

最后一步调用logger的中做了说明：LogLine调用logger来实现最后一步，而logger在初始化阶段已经被赋值为KernelLogger。来看下这个函数的一部分：

1. void KernelLogger(android::base::LogId, android::base::LogSeverity severity,  
2.      const char* tag, const char*, unsigned int, const char* msg) {  
3.     ……  
4.     static int klog_fd = TEMP_FAILURE_RETRY(open("/dev/kmsg", O_WRONLY | O_CLOEXEC));//打开kmsg节点  
5.     ……  
6.     TEMP_FAILURE_RETRY(writev(klog_fd, iov, 1));//将log写入到kmsg中  
7. }  

看到这里，前面提到问题就可以解答了：通过将init log写入到kmsg，实现了init log从kernel log输出。

2.5.2 Init log等级

WOULD_LOG会判断loglevel是否小于gMinimumLogServerity，以此决定是否输出log。gMinimumLogServerity就是init默认的loglevel，它的设定很简单，只需修改它的赋值即可：

system/core/base/logging.cpp：

static LogSeverity gMinimumLogSeverity = INFO;

至于gMinimumLogServerity可以被设定的值，依然可以从KernelLogger找到答案。

164void KernelLogger(android::base::LogId, android::base::LogSeverity severity,
165                  const char* tag, const char*, unsigned int, const char* msg) {
166  // clang-format off
167  static constexpr int kLogSeverityToKernelLogLevel[] = {
168      [android::base::VERBOSE] = 7,              // KERN_DEBUG (there is no verbose kernel log
169                                                 //             level)
170      [android::base::DEBUG] = 7,                // KERN_DEBUG
171      [android::base::INFO] = 6,                 // KERN_INFO
172      [android::base::WARNING] = 4,              // KERN_WARNING
173      [android::base::ERROR] = 3,                // KERN_ERROR
174      [android::base::FATAL_WITHOUT_ABORT] = 2,  // KERN_CRIT
175      [android::base::FATAL] = 2,                // KERN_CRIT
176  };

从后面的注释来看，这些级别跟kernel中log level是一一对应的。init的loglevel最小为2，这也是为何kernel loglevel设定为1的时候，init的log就不会再输出了。

通过init loglevel与kernel log对应关系的介绍以及init loglevel的设定，可以得出一个结论：

如果想要确保添加在init中的log输出到kernel log中，需要保证两条

• 1、 kernel loglevel >= gMinimumLogServerity；

• 2、 LOG(loglevel) <= gMinimumLogServerity

到这里2.3章节开头提出的两个问题就有答案了。了解init log系统，有利于手机开发过程中debug，某些时候可能默认的loglevel太低， log出不来，这个时候就可以根据

上面提到的方法，来修改kernel loglevel和gMinimumLogServerity，从而获取更多的log信息。在BringUP阶段和项目初始阶段，建议调整log等级调为DEBUG，即 gMinimumLogServerity= DEBUG。

2.6 Selinux Init

Selinux是从Android4.4开始导入，Android5.0开始全面启用的安全相关模块，它同样是在init中开始初始化的。Selinux初始化入口是system\core\init\selinux.cpp main 函数：

void SelinuxInitialize() {
    LOG(INFO) << "Loading SELinux policy";
    if (!LoadPolicy()) {//加载sepolicy文件  
        LOG(FATAL) << "Unable to load SELinux policy";
    }


    bool kernel_enforcing = (security_getenforce() == 1);
    bool is_enforcing = IsEnforcing();//获取selinux模式  
    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.ok()) {
        LOG(FATAL) << "Unable to write to /sys/fs/selinux/checkreqprot: " << result.error();
    }
}

Load SeLinux Policy 文件：从AndroidO开始，sepolicy相关的文件已经拆分到system和vendor分区了，所以这里加载policy文件的过程会不一样。

最终是通过LoadSplitPolicy来分别导入system/etc/selinux和vendor/etc/selinux下的policy文件。

然后在第三阶段调用通过调用SelabelInitialize 设置handler 并且调用SelinuxRestoreContext来装载文件和属性的安全上下文 。

还有一个值得注意的点是调用selinux_is_enforcing设置Selinux 模式。首先检测kernel cmdline 是否设置了androidboot.selinux = permissive；

当cmdline设置了permissive时会设置Selinux 模式为permissive；否则设置为enforing 模式。所以在调试开机流程时可以通过修改cmdline或者直接修改上面的函数修改Selinux 模式。

在手机开机的情况下还可以通过setenforce的方式改变Selinux模式，但这种方式重启后就不再起效。

Selinux 模式有两种：

• enforcing：强制模式，SELinux 运作中，且已经正确的开始限制domain/type

• permissive：宽容模式，SELinux 运作中，不过仅会有警告讯息并不会实际限制 domain/type 的存取

selinux是一个很复杂的系统，而AndroidO通过Treble架构，将selinux做了split，使得它的规则更加繁琐。在这里就不再做更多的介绍了，只需了解selinux是在哪个阶段启动、如何修改selinux的模式即可。

2.7 Start Property Service

在第三阶段我们调用PropertyInit 进行初始化/修改/加载property。调用StartPropertyService 初始化property的socket，等待其他进程调用设置获取属性

Android property系统其实可以理解为键值对:属性名字和属性值。

大部分property是记录在某些文件中的, init进程启动的时候，会加载这些文件，完成property系统初始化。

2.7.1 Property初始化

上面提到PropertyInit进行的初始化，大概流程如下：

在Property初始化的最后阶段，会通过mmap一个128K的内存，property以链表的形式存放于其中。

而这个内存的首地址会保存在__system_property_area__中。

2.7.2 启动property service

这个实在StartPropertyService 函数实现的

void StartPropertyService(int* epoll_socket) {
    InitPropertySet("ro.property_service.version", "2");


    int sockets[2];
    if (socketpair(AF_UNIX, SOCK_SEQPACKET | SOCK_CLOEXEC, 0, sockets) != 0) {
        PLOG(FATAL) << "Failed to socketpair() between property_service and init";
    }
    *epoll_socket = sockets[0];
    init_socket = sockets[1];
    accept_messages = true;

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

    listen(property_set_fd, 8);

    std::thread{PropertyServiceThread}.detach();
}

创建property_service socket用于监听进程修改property请求，通过handle_property_set_fd来处理请求，set property msg分为两类处理，

msg name以“ctl.”为起始的msg 通过handle_control_message处理，主要是启动、停止、重启服务。修改其它prop时会调用property_get，

然后通过bionic的__system_property_set函数来实现，而这个函数会通过socket与init的property service取得联系。

整个property访问的过程可以用下图来表述：

2.8 Rc文件语法与解析

---

rc文件主要包含Action、Service、Command、Options 、Import等5类声明：

• 1）Action

• 2）Command

• 3）Service

• 4）Option

• 5）Import

---

Action和Service是以Section的形式出现的，其中每个Action Section可以含有若干Command，而每个ServiceSection可以含有若干Option。Section只有起始标记，

却没有明确的结束标记，也就是说，是用“后一个Section”的起始来结束“前一个Section”。Service不能出现重名, Action可以重复，但最后会合并到一起。

而import则是导入其它init.*.rc用的，如import /init.${ro.hardware}.rc。从init main函数的代码可以看出来，根路径中只解析了init.rc，

其它的init.*.rc就是通过import导入进来的。

Action需要有一个触发器（trigger）来触发它，一旦满足了触发条件，这个Action就会被加到执行队列的末尾。Action的结构如下：

• on

Service表示一个服务程序，会通过start command执行。并根据option参数判断服务在退出时是否需要自动重启。Service的结构如下：

---

service [] *

---

看下init.rc解析的代码：

    //下面主要是解析RC文件操作了，LoadBootScripts中主要依靠ActionManager和ServiceList 解析RC文件的Action和Service，这个后边单独章节去讲
    ActionManager& am = ActionManager::GetInstance();//构造解析action对象
    ServiceList& sm = ServiceList::GetInstance();//构造管理服务对象  
	
    LoadBootScripts(am, sm);

static void LoadBootScripts(ActionManager& action_manager, ServiceList& service_list) {
    Parser parser = CreateParser(action_manager, service_list);//构造解析文件用的parser对象


    std::string bootscript = GetProperty("ro.boot.init_rc", "");
	//依次解析 如下目录的rc文件
    // /system/etc/init/hw/init.rc
    // /system/etc/init
    // /system_ext/etc/ini
    // /product/etc/init
    // /odm/etc/init
    // /vendor/etc/init
    if (bootscript.empty()) {
        parser.ParseConfig("/system/etc/init/hw/init.rc");
        if (!parser.ParseConfig("/system/etc/init")) {
            late_import_paths.emplace_back("/system/etc/init");
        }
        // late_import is available only in Q and earlier release. As we don't
        // have system_ext in those versions, skip late_import for system_ext.
        parser.ParseConfig("/system_ext/etc/init");
        if (!parser.ParseConfig("/product/etc/init")) {
            late_import_paths.emplace_back("/product/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);
    }
}

解析init.rc文件时使用了Parser类（在init目录下的init_parser.h中定义）， 并初始化ServiceParser用来解析init.rc中的“service”块，

ActionParser用来解析init.rc中的"on"块，ImportParser用来解析init.rc中的“import”块。首先来看下parser解析init.rc的过程：

函数定义于system/core/init/parser.cpp中。

bool Parser::ParseConfig(const std::string& path) {
    if (is_dir(path.c_str())) {\\判断传入参数是否为目录地址
        return ParseConfigDir(path);\\递归目录，最终还是靠ParseConfigFile来解析实际的文件 
    }
    return ParseConfigFile(path);\\传入传输为文件地址
}

bool Parser::ParseConfigFile(const std::string& path) {
    LOG(INFO) << "Parsing file " << path << "...";
    android::base::Timer t;
    auto config_contents = ReadFile(path);//读取路径指定文件中的内容
    if (!config_contents.ok()) {
        LOG(INFO) << "Unable to read config file '" << path << "': " << config_contents.error();
        return false;
    }


    ParseData(path, &config_contents.value());// 解析获取的字符串  

    LOG(VERBOSE) << "(Parsing " << path << " took " << t << ".)";
    return true;
}

ParseData比较长，它的作用是将构造出的对象加入到对应的service_、actions_、imports_中，这里的“service_/action_/improts_”其实是vector（也就是动态数组），

它们负责存放从init.rc中解析出来的service或者action(imports_有点特殊，只记录文件名和行数)。

经过上面这一步，init.rc文件就彻底被解析为一个个的section，而每个section又会调用对应的SectionParser来进一步处理：

service就会被ServiceParser解析，而action则会被ActionParser解析，improt会被ImportParser解析。

整个过程可以用类图来表示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gg2IrXqq-1587557245588)(http://q90i1nb0e.bkt.clouddn.com/Parser.png?e=1587554869&token=3MlMKkn-A4Uh5WwacM29RnvfqAOa4LZOLUth31kb:jgIAJuv34C9-5TYXkrWVgWQaohU=&attname=)]

2.8.1 Action

ActionParser定义于system/core/init/action.cpp中。

不同启动模式下触发的Action是不一样的，下面是之前8.0的charge 和normal启动模式下Trigger的Action和执行顺序，最新的待后续完成补上。

    static const BuiltinFunctionMap builtin_functions = {
        {"bootchart",               {1,     1,    {false,  do_bootchart}}},
        {"chmod",                   {2,     2,    {true,   do_chmod}}},
        {"chown",                   {2,     3,    {true,   do_chown}}},
        {"class_reset",             {1,     1,    {false,  do_class_reset}}},
        {"class_reset_post_data",   {1,     1,    {false,  do_class_reset_post_data}}},
        {"class_restart",           {1,     1,    {false,  do_class_restart}}},
        {"class_start",             {1,     1,    {false,  do_class_start}}},
        {"class_start_post_data",   {1,     1,    {false,  do_class_start_post_data}}},
        {"class_stop",              {1,     1,    {false,  do_class_stop}}},
        {"copy",                    {2,     2,    {true,   do_copy}}},
        {"domainname",              {1,     1,    {true,   do_domainname}}},
        {"enable",                  {1,     1,    {false,  do_enable}}},
        {"exec",                    {1,     kMax, {false,  do_exec}}},
        {"exec_background",         {1,     kMax, {false,  do_exec_background}}},
        {"exec_start",              {1,     1,    {false,  do_exec_start}}},
        {"export",                  {2,     2,    {false,  do_export}}},
        {"hostname",                {1,     1,    {true,   do_hostname}}},
        {"ifup",                    {1,     1,    {true,   do_ifup}}},
        {"init_user0",              {0,     0,    {false,  do_init_user0}}},
        {"insmod",                  {1,     kMax, {true,   do_insmod}}},
        {"installkey",              {1,     1,    {false,  do_installkey}}},
        {"interface_restart",       {1,     1,    {false,  do_interface_restart}}},
        {"interface_start",         {1,     1,    {false,  do_interface_start}}},
        {"interface_stop",          {1,     1,    {false,  do_interface_stop}}},
        {"load_persist_props",      {0,     0,    {false,  do_load_persist_props}}},
        {"load_system_props",       {0,     0,    {false,  do_load_system_props}}},
        {"loglevel",                {1,     1,    {false,  do_loglevel}}},
        {"mark_post_data",          {0,     0,    {false,  do_mark_post_data}}},
        {"mkdir",                   {1,     6,    {true,   do_mkdir}}},
        // TODO: Do mount operations in vendor_init.
        // mount_all is currently too complex to run in vendor_init as it queues action triggers,
        // imports rc scripts, etc.  It should be simplified and run in vendor_init context.
        // mount and umount are run in the same context as mount_all for symmetry.
        {"mount_all",               {1,     kMax, {false,  do_mount_all}}},
        {"mount",                   {3,     kMax, {false,  do_mount}}},
        {"perform_apex_config",     {0,     0,    {false,  do_perform_apex_config}}},
        {"umount",                  {1,     1,    {false,  do_umount}}},
        {"umount_all",              {1,     1,    {false,  do_umount_all}}},
        {"update_linker_config",    {0,     0,    {false,  do_update_linker_config}}},
        {"readahead",               {1,     2,    {true,   do_readahead}}},
        {"remount_userdata",        {0,     0,    {false,  do_remount_userdata}}},
        {"restart",                 {1,     1,    {false,  do_restart}}},
        {"restorecon",              {1,     kMax, {true,   do_restorecon}}},
        {"restorecon_recursive",    {1,     kMax, {true,   do_restorecon_recursive}}},
        {"rm",                      {1,     1,    {true,   do_rm}}},
        {"rmdir",                   {1,     1,    {true,   do_rmdir}}},
        {"setprop",                 {2,     2,    {true,   do_setprop}}},
        {"setrlimit",               {3,     3,    {false,  do_setrlimit}}},
        {"start",                   {1,     1,    {false,  do_start}}},
        {"stop",                    {1,     1,    {false,  do_stop}}},
        {"swapon_all",              {1,     1,    {false,  do_swapon_all}}},
        {"enter_default_mount_ns",  {0,     0,    {false,  do_enter_default_mount_ns}}},
        {"symlink",                 {2,     2,    {true,   do_symlink}}},
        {"sysclktz",                {1,     1,    {false,  do_sysclktz}}},
        {"trigger",                 {1,     1,    {false,  do_trigger}}},
        {"verity_update_state",     {0,     0,    {false,  do_verity_update_state}}},
        {"wait",                    {1,     2,    {true,   do_wait}}},
        {"wait_for_prop",           {2,     2,    {false,  do_wait_for_prop}}},
        {"write",                   {2,     2,    {true,   do_write}}},
    };

---

由于Action对应的Command太多无法一一说明，下面会简单的概括每个action完成的任务:

• Early-Init ：设置init 进程 score adj值，重置安全上下文，启动uevent服务。

• Wait-for-coldboot-done：wait uevent_main – device_init完成coldboot_done目录创建，Timeout 1s

• mix_hwrng_into_linux_rng：读取512 bytes 硬件随机数，写入linux RNG，不支持HWrandom 直接返回，不影响init启动。

• keychord_init：keychord是组合按键，keychord为每个服务配置组合键，在服务解析时为指定服务设置相应的键码值。

• console-init：如果ro.boot.console指定了控制台终端，那么优先使用这个控制台，如果没有指定，那么将使用默认控制台终端/dev/console。

• late-init: trigger early-fs fs post-fs load_system_props_action post-fs load_persist_props_action firmware_mounts_complete early-boot boot

• early-fs：设置外部存储环境变量

• fs：挂载mtd分区，创建adb设备目录，修改adf设备文件权限

• post-fs：修改productinfo用户群组，改变系统目录访问权限（kmsg、vmallcoinfo、cache等）

• Load_system_props_action：load property file，"/system/build.prop" “/vendor/build.prop” “/factory/factory.prop”

• Post-fs-data：创建、改变/data目录以及它的子目录的访问权限，启动vold、debuggerd服务，bootchart_init.

• Load_presist_props_action：启动logd服务，load property file /data/property，"/data/local.prop"

• Firmware_mounts_complete：删除dev/.booting目录

• Early-boot：修改proc、sys/class子目录访问权限

• Boot：设置usb厂商参数、CPU参数，修改sensorhub、 bluetooth、gnss、thermal目录访问权限，网络参数设置。启动Core class service。

• Nonencrypted：启动 main、late_start class service.

---

2.8.2 Sevice

Service的解析，就是对option解析的过程，AndroidO上支持的Option 列表如下：

system/core/init/service_parser.cpp
   static const KeywordMap parser_map = {
        {"capabilities",            {0,     kMax, &ServiceParser::ParseCapabilities}},
        {"class",                   {1,     kMax, &ServiceParser::ParseClass}},//设置service所属的类名，当所属类启动/退出时，服务也启动/停止，默认为default；常见的类名有：main、core、charge
        {"console",                 {0,     1,    &ServiceParser::ParseConsole}},
        {"critical",                {0,     0,    &ServiceParser::ParseCritical}},//设备关键服务，4分钟内重启超过4次会进入recovery模式  
        {"disabled",                {0,     0,    &ServiceParser::ParseDisabled}},//不跟随class启动  
        {"enter_namespace",         {2,     2,    &ServiceParser::ParseEnterNamespace}},
        {"file",                    {2,     2,    &ServiceParser::ParseFile}},
        {"group",                   {1,     NR_SVC_SUPP_GIDS + 1, &ServiceParser::ParseGroup}},//服务用户组设置  
        {"interface",               {2,     2,    &ServiceParser::ParseInterface}},
        {"ioprio",                  {2,     2,    &ServiceParser::ParseIoprio}},//io 操作优先级设置  
        {"keycodes",                {1,     kMax, &ServiceParser::ParseKeycodes}},
        {"memcg.limit_in_bytes",    {1,     1,    &ServiceParser::ParseMemcgLimitInBytes}},
        {"memcg.limit_percent",     {1,     1,    &ServiceParser::ParseMemcgLimitPercent}},
        {"memcg.limit_property",    {1,     1,    &ServiceParser::ParseMemcgLimitProperty}},
        {"memcg.soft_limit_in_bytes",
                                    {1,     1,    &ServiceParser::ParseMemcgSoftLimitInBytes}},
        {"memcg.swappiness",        {1,     1,    &ServiceParser::ParseMemcgSwappiness}},
        {"namespace",               {1,     2,    &ServiceParser::ParseNamespace}},
        {"oneshot",                 {0,     0,    &ServiceParser::ParseOneshot}},//sevice退出后不再重启  
        {"onrestart",               {1,     kMax, &ServiceParser::ParseOnrestart}},,//当服务重启时执行相关的command  
        {"oom_score_adjust",        {1,     1,    &ServiceParser::ParseOomScoreAdjust}},
        {"override",                {0,     0,    &ServiceParser::ParseOverride}},
        {"priority",                {1,     1,    &ServiceParser::ParsePriority}},
        {"reboot_on_failure",       {1,     1,    &ServiceParser::ParseRebootOnFailure}},
        {"restart_period",          {1,     1,    &ServiceParser::ParseRestartPeriod}},
        {"rlimit",                  {3,     3,    &ServiceParser::ParseProcessRlimit}},
        {"seclabel",                {1,     1,    &ServiceParser::ParseSeclabel}},
        {"setenv",                  {2,     2,    &ServiceParser::ParseSetenv}},//设置service环境变量  
        {"shutdown",                {1,     1,    &ServiceParser::ParseShutdown}},
        {"sigstop",                 {0,     0,    &ServiceParser::ParseSigstop}},
        {"socket",                  {3,     6,    &ServiceParser::ParseSocket}},创建socket  
        {"stdio_to_kmsg",           {0,     0,    &ServiceParser::ParseStdioToKmsg}},
        {"timeout_period",          {1,     1,    &ServiceParser::ParseTimeoutPeriod}},
        {"updatable",               {0,     0,    &ServiceParser::ParseUpdatable}},
        {"user",                    {1,     1,    &ServiceParser::ParseUser}},//设置service的用户
        {"writepid",                {1,     kMax, &ServiceParser::ParseWritepid}},
    };

2.8.3 Exce Command

通过介绍init.rc的解析，将action和service加载到数组中，接下去就是执行action，启动service了。

执行的过程是通过调用QueueBuiltinAction和QueueEventTrigger来实现的。

QueueBuiltinAction的第一个参数作为新建action携带cmd的执行函数；

第二个参数既作为action的trigger name，也作为action携带cmd的参数。

QueueEventTrigger函数就是利用参数构造EventTrigger，然后加入到trigger_queue_中。

后续init进程处理trigger事件时，将会触发相应的操作。

通过上述两步，将需要处理的trigger添加到trigger_queue_中，而trigger_queue_本身就是一个队列，所以先加进去的，先执行，后加入的，后执行。

也就是通过这种方式，init.rc中所列action的执行顺序得到的确认。 从2.2.3 我们知道

当while循环不断调用ExecuteOneCommand函数时，将按照trigger表的顺序，依次取出action链表中与trigger匹配的action。

每次仅仅执行一个action中的一个command对应函数（一个action可能携带多个command）。

当一个action所有的command均执行完毕后，再执行下一个action。

当一个trigger对应的action均执行完毕后，再执行下一个trigger对应action。