Android的init进程启动过程

0. 前言

Android中的内核启动后，kernel会启动第一个用户级别的进程：init，它是一个由内核启动的第一个用户级进程。
我们可以通过 adb shell ps | grep init 来查看到他的pid 为 1.

接下来从源码的角度看看init进程启动的时候做了什么？

注：本文分析的andorid版本为 remotes/aosp/nougat-release.

init进程的源码在android源码的: /system/core/init 目录中。
我们看到该目录下有一个Android.mk文件，至少看到如下内容，告诉我们会生成一个init的的可执行文件。

LOCAL_MODULE:= init
include $(BUILD_EXECUTABLE)

而init的入口main函数是在init.cpp文件中定义的。

1. 入口

a. 命令行解析

if (!strcmp(basename(argv[0]), "ueventd")) {    
      return ueventd_main(argc, argv);
}
if (!strcmp(basename(argv[0]), "watchdogd")) {    
      return watchdogd_main(argc, argv);
}

watchdog和uevent命令已经集成到了init， 它们在/sbin目录，是一个链接文件，直接链接到/init，所以当执行/sbin/eventd或/sbin/watchdogd时，将会进入对应的ueventd_main或watchdogd_main入口点。
ueventd守护进程负责解析/ueventd.rc文件，并创建相应的设备结点等。
watchdogd守护进程负责定时向 "/dev/watchdog"执行写操作，以判断系统是否正常运行。
这两个进程不是本文讨论的重点，所以先忽略。。。

b. 挂载根文件系统的目录

mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755");
mkdir("/dev/pts", 0755);
mkdir("/dev/socket", 0755);
mount("devpts", "/dev/pts", "devpts", 0, NULL);
mount("proc", "/proc", "proc", 0, "hidepid=2,gid=" MAKE_STR(AID_READPROC));
mount("sysfs", "/sys", "sysfs", 0, NULL);
mount("selinuxfs", "/sys/fs/selinux", "selinuxfs", 0, NULL);
mknod("/dev/kmsg", S_IFCHR | 0600, makedev(1, 11));

分别挂载proc和和sysfs文件系统到/proc 和/sys目录
close(open("/dev/.booting", O_WRONLY | O_CREAT | O_CLOEXEC, 0000)); 在/dev目录创建一个空文件.booting来表示正在执行初始化
InitKernelLogging(argv); 重定向标准输入，标准输出，标准错误输出到 /dev/null
selinux_initialize(is_first_stage) 加载SELinux策略， 后面有一些初始化文件上下文的操作等

3. 解析init.rc文件

Parser& parser Parser::GetInstance();
parser.AddSectionParser("service",std::make_unique());
parser.AddSectionParser("on", std::make_unique());
parser.AddSectionParser("import", std::make_unique());
parser.ParseConfig("/init.rc");

3.1. init.rc文件是以块（section）为单位组织的，一个section包含多行。section分为两大类：分别为“服务（service）”和“行为（action）”。
3.2. “服务”块以关键字“service”开始，表示启动某个进程的方式和参数，“行为”块以关键字“on”开始，表示一堆命令的集合。每个块以关键字“service”或“on”开始，直到下一个“on”或“service”结束，中间所有行都属于这个“块”。
3.3. 上面在解析init.rc文件时使用了Parser类（在init目录下的init_parser.h中定义）， 初始化ServiceParser用来解析 “service”块，ActionParser用来解析"on"块，ImportParser用来解析“import”块，“import”是用来引入一个init配置文件，来扩展当前配置的。
3.4. parser解析init.rc文件，/init.rc文件是/system/core/rootdir/init.rc。
3.5. /system/core/init/readme.txt 中对init文件中的所有关键字做了介绍，主要包含了Actions, Commands, Services, Options, and Imports等
3.6. 在ParseConfig解析完init脚本后，init会依次执行几个重要的阶段：

1. 3.6.1. on early-init阶段
   am.QueueEventTrigger("early-init"); 执行on early-init 内容，主要包括 start ueventd 等

2. 3.6.2. on init 阶段
   am.QueueEventTrigger("init"); 执行on init 内容，主要包括 创建/挂载一些目录，以及symlink等

3. 3.6.3. on charger/late-init阶段
   // Don't mount filesystems or start core system services in charger mode.
   std::string bootmode = property_get("ro.bootmode");
   if (bootmode == "charger") {
   am.QueueEventTrigger("charger");
   } else {
   am.QueueEventTrigger("late-init");
   }
   如果是充电模式下启动 就会执行 on charger内容， 否则执行on late-init内容，在init.rc的on late-init中
   看到很多trigger（触发器），用于执行对应的Action.
   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
   

从最后两行可以看出，late-init 触发了on early-boot和on boot两个Action.

4. 3.6.4. on boot 阶段
   在on boot 的最后class_start core 会启动class为core的服务，这些服务包括ueventd、logd、healthd、adbd（disabled）、lmkd（LowMemoryKiller）、servicemanager、vold、debuggerd、surfaceflinger、bootanim（disabled）等

5. 3.6.5. main服务的启动
   在main函数后面的for循环中，调用execute_one_command依次执行操作队列中的命令
   while (true) {
   if (!waiting_for_exec) {
   am.ExecuteOneCommand();
   restart_processes();
   }
   }
   在/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

   通过ro.zygote的属性import对应的zygote的rc文件，通过adb shell getprop ro.zygote 查看得到zygote64_32， 所以import的是/init.zygote64_32.rc文件，该文件中定义的zygote如下：

    service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server --socket-name=zygote
    class main
    priority -20
    socket zygote stream 660 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 /dev/stune/foreground/tasks
   

   可以看到zygote的class是main, 它是在on nonencrypted时被启动的
   on nonencrypted
   # A/B update verifier that marks a successful boot.
   exec - root -- /system/bin/update_verifier nonencrypted
   class_start main
   class_start late_start

注：但在Android 7.0中，对该机制做了一些改变 。
单一的init＊.rc，被拆分，服务根据其二进制文件的位置（／system，／vendor，／odm）定义到对应分区的etc／init目录中，每个服务一个rc文件。与该服务相关的触发器、操作等也定义在同一rc文件中。
/system/etc/init，包含系统核心服务的定义，如SurfaceFlinger、MediaServer、Logcatd等。
/vendor/etc/init， SOC厂商针对SOC核心功能定义的一些服务。比如高通、MTK某一款SOC的相关的服务。
/odm/etc/init，OEM/ODM厂商如小米、华为、OPP其产品所使用的外设以及差异化功能相关的服务。

查看android 7.0虚拟机的/system/etc/init 如下

15:13:04屏幕截图.png

上面的servicemanager这个服务也从init.rc中拆分出来了。

4. 启动完成

至此，init进程已经启动完成，一些重要的服务如core服务和main服务也都启动起来，并启动了zygote（/system/bin/app_process64）进程，zygote初始化时会创建虚拟机，启动systemserver等，它的启动过程也是非常复杂，等下一篇再说。。

5. 扩展阅读

http://wonview.blog.163.com/blog/static/585013272012111924915229/
http://blog.csdn.net/k_linux_man/article/details/7292746
http://blog.csdn.net/fuyajun01/article/details/22572921
http://blog.csdn.net/windskier/article/details/6416547/