本次系列的内容如下：
Android启动流程——1 序言、bootloader引导与Linux启动
Android系统启动——2 init进程
Android系统启动——3 init.rc解析
Android系统启动——4 zyogte进程
Android系统启动——5 zyogte进程(Java篇)
Android系统启动——6 SystemServer启动
Android系统启动——7 附录1：Android属性系统
Android系统启动——8 附录2：相关守护进程简介
本篇文章的主要内容如下：
- 1、init进程简介
- 2、Init.cpp的main()方法解析
一、init进程简介
通过上篇文章我们知道，Android设备启动要经过3个阶段，BootLoader、Linux Kernel和Android系统服务，一般情况下，他们都会相应的启动对动画对应。前面我们已经知道Andorid系统是如何启动的BootLoader和Linux Kernel的。
严格上讲，Android系统实际上是运行于Linux内核之上的一系列"服务进程"，并不算一个完成意义上的"操作系统"；而这一系列进程是维持Android设备正常工作的关键，所以它们肯定有一个"根进程"，这个"根进程"衍生出了这一系列进程。这个"根进程"就是init进程。
init进程是Android系统启动的第一个进程。它通过解析init.rc脚本来构建出系统的初始形态。其他的"一系列"Android系统进程大部分也是通过"init.rc"来启动的。因为要兼容不同的开发商，所以init.rc脚本的语法很简单，并且采用的是纯文本编辑的，这样导致它可读性就会很高。
二、Init.cpp
init是Linux系统中用户空间的第一个进程(pid=1)，Linux Kernel启动后，会调用/system/core/init/Init.cpp的main()方法
那我们就来看下init.cpp的main()里面的具体实现
代码在init.cpp989行
int main(int argc, char** argv) {
// ****************** 第一部分 ******************
// 检查启动程序的文件名
if (!strcmp(basename(argv[0]), "ueventd")) {
return ueventd_main(argc, argv);
}
if (!strcmp(basename(argv[0]), "watchdogd")) {
return watchdogd_main(argc, argv);
}
// ****************** 第二部分 ******************
// 设置文件属性为0777
// Clear the umask.
umask(0);
// ****************** 第三部分 ******************
// 设置环境变量
add_environment("PATH", _PATH_DEFPATH);
// ****************** 第四部分 ******************
// 创建一些基本目录，并挂载
//判断是否是第一次
bool is_first_stage = (argc == 1) || (strcmp(argv[1], "--second-stage") != 0);
// Get the basic filesystem setup we need put together in the initramdisk
// on / and then we'll let the rc file figure out the rest
//如果是第一次.
if (is_first_stage) {
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, NULL);
mount("sysfs", "/sys", "sysfs", 0, NULL);
}
// ****************** 第五部分 ******************
// 把标准输入、标准输出和标准错误重定向到空设备文件"/dev/_null_"
// We must have some place other than / to create the device nodes for
// kmsg and null, otherwise we won't be able to remount / read-only
// later on. Now that tmpfs is mounted on /dev, we can actually talk
// to the outside world.
open_devnull_stdio();
// ****************** 第六部分 ******************
// 启动kernel log
klog_init();
klog_set_level(KLOG_NOTICE_LEVEL);
// 输出init启动阶段的log
NOTICE("init%s started!\n", is_first_stage ? "" : " second stage");
// ****************** 第七部分 ******************
// 设置系统属性
if (!is_first_stage) {
// Indicate that booting is in progress to background fw loaders, etc.
// 7.1 创建初始化标志
close(open("/dev/.booting", O_WRONLY | O_CREAT | O_CLOEXEC, 0000));
//7.2 初始化Android的属性系统
property_init();
// If arguments are passed both on the command line and in DT,
// properties set in DT always have priority over the command-line ones.
//7.3 解析DT和命令行中的kernel启动参数
process_kernel_dt();
process_kernel_cmdline();
// Propogate the kernel variables to internal variables
// used by init as well as the current required properties.
//7.4 设置系统属性
export_kernel_boot_props();
}
// ****************** 第八部分 ******************
// Set up SELinux, including loading the SELinux policy if we're in the kernel domain.
// 调用selinux_initialize函数启动SELinux
selinux_initialize(is_first_stage);
// If we're in the kernel domain, re-exec init to transition to the init domain now
// that the SELinux policy has been loaded.
if (is_first_stage) {
// 按照selinux policy要求，重新设置init文件属性
if (restorecon("/init") == -1) {
ERROR("restorecon failed: %s\n", strerror(errno));
security_failure();
}
char* path = argv[0];
// 设置参数 --second-stage
char* args[] = { path, const_cast("--second-stage"), nullptr };
// 执行init进程，重新进入main函数
if (execv(path, args) == -1) {
ERROR("execv(\"%s\") failed: %s\n", path, strerror(errno));
security_failure();
}
}
// These directories were necessarily created before initial policy load
// and therefore need their security context restored to the proper value.
// This must happen before /dev is populated by ueventd.
INFO("Running restorecon...\n");
restorecon("/dev");
restorecon("/dev/socket");
restorecon("/dev/__properties__");
restorecon_recursive("/sys");
// ****************** 第九部分 ******************
epoll_fd = epoll_create1(EPOLL_CLOEXEC);
if (epoll_fd == -1) {
ERROR("epoll_create1 failed: %s\n", strerror(errno));
exit(1);
}
signal_handler_init();
// ****************** 第十部分 ******************
property_load_boot_defaults();
start_property_service();
// ****************** 第十一部分 ******************
// 重点部分，我们后面用专门用一篇文章讲解
init_parse_config_file("/init.rc");
// ****************** 第十二部分 ******************
action_for_each_trigger("early-init", action_add_queue_tail);
// Queue an action that waits for coldboot done so we know ueventd has set up all of /dev...
queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done");
// ... so that we can start queuing up actions that require stuff from /dev.
queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
queue_builtin_action(keychord_init_action, "keychord_init");
queue_builtin_action(console_init_action, "console_init");
// Trigger all the boot actions to get us started.
action_for_each_trigger("init", action_add_queue_tail);
// Repeat mix_hwrng_into_linux_rng in case /dev/hw_random or /dev/random
// wasn't ready immediately after wait_for_coldboot_done
queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
// Don't mount filesystems or start core system services in charger mode.
char bootmode[PROP_VALUE_MAX];
if (property_get("ro.bootmode", bootmode) > 0 && strcmp(bootmode, "charger") == 0) {
action_for_each_trigger("charger", action_add_queue_tail);
} else {
action_for_each_trigger("late-init", action_add_queue_tail);
}
// Run all property triggers based on current state of the properties.
queue_builtin_action(queue_property_triggers_action, "queue_property_triggers");
// ****************** 第十三部分 ******************
while (true) {
if (!waiting_for_exec) {
execute_one_command();
restart_processes();
}
int timeout = -1;
if (process_needs_restart) {
timeout = (process_needs_restart - gettime()) * 1000;
if (timeout < 0)
timeout = 0;
}
if (!action_queue_empty() || cur_action) {
timeout = 0;
}
bootchart_sample(&timeout);
epoll_event ev;
int nr = TEMP_FAILURE_RETRY(epoll_wait(epoll_fd, &ev, 1, timeout));
if (nr == -1) {
ERROR("epoll_wait failed: %s\n", strerror(errno));
} else if (nr == 1) {
((void (*)()) ev.data.ptr)();
}
}
return 0;
}
由于main()函数比较长，整个init进程的启动流程都在这个函数中，我们把main()切割成，然后我们就来挨个解释下
1、第一部分
主要是检查启动程序的文件名，这里面分成三种情况
- 1 如果文件名是"ueventd"，则执行守护进程ueventd的主函数ueventd_main()
- 2 如果文件名是"watchdogd"，则执行看门狗守护进程的主函数watchdogd_main()
- 如果文件名既不是"ueventd"也不是"watchdogd"，则往下执行
2、第二部分
umask(0);
缺省情况下，一个进程创建出来的文件和文件夹的属性是022，使用umask()函数能设置文件属性的掩码。参数为0意味着进程创建的文件属性是0777
3、第3部分
设置环境变量地址
4、第4部分
创建一些基本的目录，包括/dev、/porc、/sysfc等。同时把一些文件系统，如tmpfs、devpt、proc、sysfs等mount到项目的目录。我们把上面的文件目录简单说一下
- tmpfs
是一种基于内存的文件系统,mount后就可以使用。tmpfs文件系统下的文件都存放在内存中，访问速度快，但是关机后所有内容偶读会丢失，因此tmpfs文件系统比较合适存放一些临时性的文件。tmpfs文件系统的大小是动态变化的，刚开始占用空间很小，随着文件的增多会随之变大，很节省空间。Android将tmpfs文件mount到/dev目录，dev目录用来存放系统创建的设备节点，正好符合tmpfsw文件系统的特点。
-devpts
是虚拟终端文件系统，它通常mount在目录dev/pts下- proc
是一种基于内存的虚拟文件系统，它可以看作是内核内部数据结构的接口，通过它可以获得系统的信息，同时能够在运行时修改特定的内核参数- sysfs
文件系统和proc文件系统类似，它是Linux2.6内核引入的，作用是把系统的设备和总线按层次组织起来，使得它们可以在用户空间存取，用来向用户空间导出内核的数据结构及它们的属性。
5、第5部分
调用open_devnull_stdio()函数把标准输入、标准输出和标准错误重定向到空设备文件"/dev/null"，这是创建守护进程常用的手段
6、第6部分
调用klog_init()函数创建节点/dev/kmsg，这样init进程可以使用kernel的log系统来出书log了，同时调用klog_set_level函数来设置输出log的级别。
PS：
- 1 这里补充下，为什么要使用kernel的log系统，因为此时Android系统的log还没有启动，所以需要使用kernel的log系统。
- 2 log的输出级别是KLOG_NOTICE_LEVEL(5)，当log级别小于5时，这回输出kernel log，默认值是3，关于log级别如下：
define KLOG_ERROR_LEVEL 3
define KLOG_WARNING_LEVEL 4
define KLOG_NOTICE_LEVEL 5
define KLOG_INFO_LEVEL 6
define KLOG_DEBUG_LEVEL 7
define KLOG_DEFUALT_LEVEL 3
默认为3
7、第7部分
如果不是第一次，则进行一些设置，我又将这里具体划分为4个部分
- 7.1 创建初始化标志
- 7.2 初始化Android的属性系统
- 7.3 解析DT和命令行中的kernel启动参数
- 7.4 设置系统属性
7.1 创建初始化标志
close(open("/dev/.booting", O_WRONLY | O_CREAT | O_CLOEXEC, 0000));
在/dev目录下创建一个空文件".booting"表示初始化正在进行
is_booting()函数会依靠空文件".booting"来判断是否进程处于初始化中，初始化结束后，这个文件会被删除
7.2 初始化Android的属性系统
主要是调用property_init()函数来初始化Android的属性系统，property_init()函数主要作用是创建一个共享区域来存储属性值
7.3 解析DT和命令行中的kernel启动参数
这里里面又分两个，由于DT的优先级高于cmdline，所以先调用process_kernel_dt()函数解析启动参数，然后调用process_kernel_cmdline解析启动参数。
为了让大家更好的理解这个两个方法，下面我们来看下这两个方法的具体实现
- process_kernel_dt函数解析
代码在init.cpp816行
static void process_kernel_dt(void)
{
static const char android_dir[] = "/proc/device-tree/firmware/android";
std::string file_name = android::base::StringPrintf("%s/compatible", android_dir);
std::string dt_file;
android::base::ReadFileToString(file_name, &dt_file);
// 判断compatible文件内容是否是android,firmware
if (!dt_file.compare("android,firmware")) {
ERROR("firmware/android is not compatible with 'android,firmware'\n");
return;
}
std::unique_ptrdir(opendir(android_dir), closedir);
if (!dir)
return;
struct dirent *dp;
// 读取目录的每个文件
while ((dp = readdir(dir.get())) != NULL) {
if (dp->d_type != DT_REG || !strcmp(dp->d_name, "compatible"))
continue;
file_name = android::base::StringPrintf("%s/%s", android_dir, dp->d_name);
android::base::ReadFileToString(file_name, &dt_file);
std::replace(dt_file.begin(), dt_file.end(), ',', '.');
// 每个文件名作为属性名，里面的内容作为属性值
std::string property_name = android::base::StringPrintf("ro.boot.%s", dp->d_name);
property_set(property_name.c_str(), dt_file.c_str());
}
}
上面这个函数主要是在/proc/device-tree/firmware/android 这个目录下，先看compatiable文件内容是否是android,firmware。然后这个目录下每个文件名作为属性，文件里面的内容作为属性值。这里的话就是ro.boot.hareware ro.boot.name这两个属性值。
我们知道内核通常由bootloader(启动引导程序)加载启动，前面说过了，目前使用最广泛的是bootloader大都基于u-boot定制。内核允许bootloader启动自己时传递参数。在内核内核启动完毕后，启动参数可以通过/proc/cmdline查看。
例如android 4.4模拟器启动后，查看其内核启动参数，如下：
root@generic:/ # cat /proc/cmdline
qemu.gles=0 qemu=1 console=ttyS0 android.qemud=ttyS1 android.checkjni=1 ndns=1
- process_kernel_cmdline函数解析
代码在init.cpp848行
static void process_kernel_cmdline(void)
{
/* don't expose the raw commandline to nonpriv processes */
// 第一步
chmod("/proc/cmdline", 0440);
/* first pass does the common stuff, and finds if we are in qemu.
* second pass is only necessary for qemu to export all kernel params
* as props.
*/
// 第二步
import_kernel_cmdline(false, import_kernel_nv);
if (qemu[0])
import_kernel_cmdline(true, import_kernel_nv);
}
这个函数内部有点小复杂，我将其分为2个步骤，解析如下：
- 第一步：修改/proc/cmdline文件权限，0440即表明只有root用户或root组用户可以续写该文件，其他用户无法访问。
- 第二步：调用import_kernel_cmdline函数，就是读取proc/cmdline中的内容。这个函数有两个有两个参数，第一个采纳数标识当前Android十倍是否是模拟器。第二个参数是一个函数指针；主要指的是通过调用import_kernel_nv函数来设置系统属性。
import_kernel_cmdline函数将/proc/cmdline内容读入到内存缓冲区中，并将cmdline内容以空格拆分为小段字符串，依次传递给import_kernel_nv函数处理。以上面的/proc/cmdline的输出为例子，该字符串可以拆分为以下几段：
qemu.gles=0
qemu=1
console=ttyS0
android.qemud=ttyS1
android.checkjni=1
ndns=1
因此，在import_kernel_nv将会连续调用6次，依次传入上述字符串。函数实现如下：
代码在init.cpp763行
static void import_kernel_nv(char *name, bool for_emulator)
{
char *value = strchr(name, '=');
int name_len = strlen(name);
if (value == 0) return;
*value++ = 0;
if (name_len == 0) return;
if (for_emulator) {
/* in the emulator, export any kernel option with the
* ro.kernel. prefix */
char buff[PROP_NAME_MAX];
int len = snprintf( buff, sizeof(buff), "ro.kernel.%s", name );
if (len < (int)sizeof(buff))
property_set( buff, value );
return;
}
if (!strcmp(name,"qemu")) {
strlcpy(qemu, value, sizeof(qemu));
} else if (!strncmp(name, "androidboot.", 12) && name_len > 12) {
const char *boot_prop_name = name + 12;
char prop[PROP_NAME_MAX];
int cnt;
cnt = snprintf(prop, sizeof(prop), "ro.boot.%s", boot_prop_name);
if (cnt < PROP_NAME_MAX)
property_set(prop, value);
}
}
import_kernel_cmdline第一次执行时，传入import_kernel_nv的形参为for_emulator为0，因此将匹配name是否为qemu，如果是，将其值保存在qemu全局静态缓冲区中。对于android模拟器，存在/proc/cmdline中存在"qemu=1"字段。如果for_emulator为1，则将生成ro.kernel.{name}={value}属性写入Android属性系统中。
此时回到process_kernel_cmdline函数，继续执行
if (qemu[0])
import_kernel_cmdline(1, import_kernel_nv);
当系统为模拟器时，qemu[0]其值为"1"，第二次执行import_kernel_cmdline函数，将再次调用6次import_kernel_nv函数，并且for_emulator为1，因此将生成6个属性。我们来确定下我们的分析
root@generic:/ # getprop | grep ro.kernel.
[ro.kernel.android.checkjni]: [1]
[ro.kernel.android.qemud]: [ttyS1]
[ro.kernel.console]: [ttyS0]
[ro.kernel.ndns]: [1]
[ro.kernel.qemu.gles]: [0]
[ro.kernel.qemu]: [1]
可验证我们的分析是正确的。
7.4 设置系统属性
代码在init.cpp796行
static void export_kernel_boot_props() {
struct {
const char *src_prop;
const char *dst_prop;
const char *default_value;
} prop_map[] = {
{ "ro.boot.serialno", "ro.serialno", "", },
{ "ro.boot.mode", "ro.bootmode", "unknown", },
{ "ro.boot.baseband", "ro.baseband", "unknown", },
{ "ro.boot.bootloader", "ro.bootloader", "unknown", },
{ "ro.boot.hardware", "ro.hardware", "unknown", },
{ "ro.boot.revision", "ro.revision", "0", },
};
// 通过内核的属性设置应用层配置文件的属性
for (size_t i = 0; i < ARRAY_SIZE(prop_map); i++) {
char value[PROP_VALUE_MAX];
int rc = property_get(prop_map[i].src_prop, value);
property_set(prop_map[i].dst_prop, (rc > 0) ? value : prop_map[i].default_value);
}
}
所以export_kernel_boot_props这个函数，它就是设置一些属性，设置ro属性根据之前的ro.boot这类的属性值，如果没有设置成unknown，像之前我们有ro.boot.hardware，那我们就可以设置root.hardware这样的属性。这样描述很有朋友看不懂，我把上面的语言转化为最直观的语言如下：
export_kernel_boot_props用户设置几个系统属性，如下：
- 读取ro.boot.serialno，若存在其值写入ro.serialno，否则ro.serialno写入空
- 读取ro.boot.mode，若存在其值写入ro.bootmode，否则ro.bootmode写入"unkown"
- 读取ro.boot.baseband，若存在其值写入ro.baseband，否则ro.baseband写入"unkown"
- 读取ro.boot.bootloader，若存在其值写入ro.bootloader，否则ro.bootloader写入"unkown"
- 读取ro.boot.revision，若存在，若存在其值写入revision中，否则ro.revision写入"unkown"。
- 读取ro.boot.hardware，若存在其值写入ro.hardware，否则ro.hardware写入"unkown"。
8、第8部分
这部分主要是selinux相关的，这部分代码是Android4.3之后添加的安全内核，随后伴随着Android系统更新不断迭代，这段代码主要是设计SELinux初始化。后面有时间咱们开个专题讲解SELinux。
SELinux带给Linux的主要价值是：提供了一个灵活的，可配置的MAC机制。同时SELinux是一个安全体系结构，它通过LSM(Linux Security Modules)框架被集成到Linux Kernel 2.6.x。它是NSA(United States National Security Agency)和SELinux社区的联合项目。
这里重点分析下selinux_initialize函数
代码在init.cpp955行
static void selinux_initialize(bool in_kernel_domain) {
// 使用Timer计时，计算selinux初始化耗时
Timer t;
selinux_callback cb;
// 用于打印Log的回调函数
cb.func_log = selinux_klog_callback;
selinux_set_callback(SELINUX_CB_LOG, cb);
// 用于检查权限的回调函数
cb.func_audit = audit_callback;
selinux_set_callback(SELINUX_CB_AUDIT, cb);
// 如果不支持，则直接返回
if (selinux_is_disabled()) {
return;
}
// 内核态处理流程，第一阶段in_kernel_domain为true
if (in_kernel_domain) {
// 这个log打印不出，因为是INFO级别
INFO("Loading SELinux policy...\n");
// 用于加载sepolicy文件，该函数最终将sepolicy文件传递给kernel，这样kernel就有了安全策略的配置文件
if (selinux_android_load_policy() < 0) {
ERROR("failed to load policy: %s\n", strerror(errno));
security_failure();
}
// 命令行中得到的信息
bool is_enforcing = selinux_is_enforcing();
// 这里补充下 用于设置selinux工作模式。selinux有两种工作模式：
// 1、"permissive"，所有的操作都被允许(即没有MAC)，但是如果违反权限的话，会记录日志。
// 2、"enforcing"，所有操作都会进行权限检查。在一般的中断中，应有工作于enforcing模式
security_setenforce(is_enforcing);
if (write_file("/sys/fs/selinux/checkreqprot", "0") == -1) {
security_failure();
}
//输出selinux的模式，与初始化耗时
NOTICE("(Initializing SELinux %s took %.2fs.)\n",
is_enforcing ? "enforcing" : "non-enforcing", t.duration());
} else {
// 如果启动第二阶段，调用该函数
selinux_init_all_handles();
}
}
9、第9部分
这部分分为上下按两个阶段
第一阶段主要是调用epoll_create1创建epoll句柄，如果创建失败，则退出。
第二阶段是调用signal_handler_init()函数，主要是装载进程信号处理器。
signal_handler_init()函数主要是当子进程被kill之后，会在父进程接受一个信号。处理这个信号的时候往sockpair一段写数据，而另一端的fd是加入epoll中
init是一个守护进程，为了防止init的子进程称为僵尸进程(zombie process)，需要init在子进程结束时获取子进程的结束码，通过结束码将程序表中的子进程移除，防止称为僵尸进程的子进程占用程序表的空间(程序表的空间达到上线时，系统就不能再启动新的进城了，会引起严重的系统问题)。
现在我们来看下signal_handler_init()函数的内容
signal_handler.cpp955行
void signal_handler_init() {
// 在Linux中，父进程是通过捕捉SIGCHILD信号来得知子进程运行结束的情况
// Create a signalling mechanism for SIGCHLD.
int s[2];
// 利用socketpair创建出已经连接的两个socket，分别作为信号的读、写端
if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK | SOCK_CLOEXEC, 0, s) == -1) {
ERROR("socketpair failed: %s\n", strerror(errno));
exit(1);
}
signal_write_fd = s[0];
signal_read_fd = s[1];
// Write to signal_write_fd if we catch SIGCHLD.
struct sigaction act;
memset(&act, 0, sizeof(act));
// 信号处理器为SIGCHLD_handler，其被存在sigaction结构体重，负责处理SIGCHLD消息
// 信号处理器
act.sa_handler = SIGCHLD_handler;
// 仅当进程终止时才接受
act.sa_flags = SA_NOCLDSTOP;
// 调用信号安装函数sigaction，将监听的信号及对应的信号处理器注册到内核中
sigaction(SIGCHLD, &act, 0);
reap_any_outstanding_children();
// 定义在system/core/init/init.cpp中，注册epoll handler，当signal_read_fd 有数据可读时，调用handle_signal
register_epoll_handler(signal_read_fd, handle_signal);
}
9.1信号
这里我们简单介绍下信号：
Linux进程通过相互发送接收消息来实现进程间通信，这些消息被称为"信号"。每个进程在处理它进程发送的信号时，都要注册处理者，处理者被称为信号处理器。
每个进程在处理其他进程发送的signal信号时都需要先注册，当进程的运行状态改变或终止时会产生某种signal信号，init进程是所有用户空间进程的父进程，当其子进程终止时产生SIGCHLD信号，init进程调用信号安装函数sigaction()，传递参数给sigaction结构体，便完成信号处理的过程。
这里有两个重要的函数：SIGCHLD_handler和handle_signal，他俩是对应的
代码在signal_handler.cpp 158行
static void SIGCHLD_handler(int) {
//向signal_write_fd写入1，知道成功为止
if (TEMP_FAILURE_RETRY(write(signal_write_fd, "1", 1)) == -1) {
ERROR("write(signal_write_fd) failed: %s\n", strerror(errno));
}
}
SIGCHLD_handler()函数负责写入
代码在signal_handler.cpp 150行
static void handle_signal() {
// Clear outstanding requests.
char buf[32];
// 读取signal_read_fd数据，放入buf
read(signal_read_fd, buf, sizeof(buf));
reap_any_outstanding_children();
}
handle_signal()函数负责读取数据，上面调用了reap_any_outstanding_children()函数，我们来看下
代码在signal_handler.cpp 145行
static void reap_any_outstanding_children() {
while (wait_for_one_process()) {
}
}
我们看到reap_any_outstanding_children函数就是调用while循环来调用wait_for_one_process()函数，下面我们来看下wait_for_one_process()函数的具体执行
代码在signal_handler.cpp 53行
static bool wait_for_one_process() {
int status;
// 等待任意子进程，如果子进程没有退出则返回0，否则则返回该子进程的pid
pid_t pid = TEMP_FAILURE_RETRY(waitpid(-1, &status, WNOHANG));
if (pid == 0) {
return false;
} else if (pid == -1) {
ERROR("waitpid failed: %s\n", strerror(errno));
return false;
}
// 根据pid 查找相应的service
service* svc = service_find_by_pid(pid);
std::string name;
if (svc) {
name = android::base::StringPrintf("Service '%s' (pid %d)", svc->name, pid);
} else {
name = android::base::StringPrintf("Untracked pid %d", pid);
}
NOTICE("%s %s\n", name.c_str(), DescribeStatus(status).c_str());
if (!svc) {
return true;
}
// TODO: all the code from here down should be a member function on service.
// 当flag为RESTART，且不是ONESHOT时，先kill进程组内所有子进程或子线程
if (!(svc->flags & SVC_ONESHOT) || (svc->flags & SVC_RESTART)) {
NOTICE("Service '%s' (pid %d) killing any children in process group\n", svc->name, pid);
kill(-pid, SIGKILL);
}
// Remove any sockets we may have created.
// 移除当前服务svc中所有创建过的socket
for (socketinfo* si = svc->sockets; si; si = si->next) {
char tmp[128];
snprintf(tmp, sizeof(tmp), ANDROID_SOCKET_DIR"/%s", si->name);
unlink(tmp);
}
// 当flags为EXEC时，释放相应的服务
if (svc->flags & SVC_EXEC) {
INFO("SVC_EXEC pid %d finished...\n", svc->pid);
waiting_for_exec = false;
list_remove(&svc->slist);
free(svc->name);
free(svc);
return true;
}
svc->pid = 0;
svc->flags &= (~SVC_RUNNING);
// Oneshot processes go into the disabled state on exit,
// except when manually restarted.
// 对于ONESHOT服务，使其进入disabled状态
if ((svc->flags & SVC_ONESHOT) && !(svc->flags & SVC_RESTART)) {
svc->flags |= SVC_DISABLED;
}
// Disabled and reset processes do not get restarted automatically.
// 禁用和重置的服务，都不再自动重启
if (svc->flags & (SVC_DISABLED | SVC_RESET)) {
// 设置相应的service状态为stopped
svc->NotifyStateChange("stopped");
return true;
}
// 服务在4分钟内重启次数超过4次，则重启手机进入recovery模式
time_t now = gettime();
if ((svc->flags & SVC_CRITICAL) && !(svc->flags & SVC_RESTART)) {
if (svc->time_crashed + CRITICAL_CRASH_WINDOW >= now) {
if (++svc->nr_crashed > CRITICAL_CRASH_THRESHOLD) {
ERROR("critical process '%s' exited %d times in %d minutes; "
"rebooting into recovery mode\n", svc->name,
CRITICAL_CRASH_THRESHOLD, CRITICAL_CRASH_WINDOW / 60);
android_reboot(ANDROID_RB_RESTART2, 0, "recovery");
return true;
}
} else {
svc->time_crashed = now;
svc->nr_crashed = 1;
}
}
svc->flags &= (~SVC_RESTART);
svc->flags |= SVC_RESTARTING;
// Execute all onrestart commands for this service.
// 执行当前service中所有onrestart命令
struct listnode* node;
list_for_each(node, &svc->onrestart.commands) {
command* cmd = node_to_item(node, struct command, clist);
cmd->func(cmd->nargs, cmd->args);
}
// 设置相应的service状态未restarting
svc->NotifyStateChange("restarting");
return true;
}
总结一下：
当init进程调用signal_handler_init后，一旦受到子进程终止带来的SIGCHLD消息后，将利用信号处理者SIGCHLD_handler向signal_write_fd写入信息；epoll句柄监听到signal_read_fd收到消息后，将调用handle_signal进行处理。如下图
10、第10部分
这部分主要分为两部分，上半部分是调用property_load_boot_defaults()函数解析根目录的default.prop的属性，设置默认属性配置的相关工作。下半部分是调用start_prperty_service()函数，启动属性服务，并接受属性的socket的fd加入到epoll中，也定义了处理函数。那我们依次来看下
10.1、property_load_boot_defaults()函数解析
代码在property_service.cpp 494行
void property_load_boot_defaults() {
load_properties_from_file(PROP_PATH_RAMDISK_DEFAULT, NULL);
}
我们看到他调用load_properties_from_file函数，那我们来看下load_properties_from_file函数。
代码在property_service.cpp 426行
/*
* Filter is used to decide which properties to load: NULL loads all keys,
* "ro.foo.*" is a prefix match, and "ro.foo.bar" is an exact match.
*/
static void load_properties_from_file(const char* filename, const char* filter) {
Timer t;
std::string data;
if (read_file(filename, &data)) {
data.push_back('\n');
load_properties(&data[0], filter);
}
NOTICE("(Loading properties from %s took %.2fs.)\n", filename, t.duration());
}
PS：所谓充电模式是指充电器开机时设备进入的状态。这是kernel和init进程会启动，但是大部分服务都不会启动
10.2、start_property_service()函数解析
代码在property_service.cpp 570行
void start_property_service() {
property_set_fd = create_socket(PROP_SERVICE_NAME, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
0666, 0, 0, NULL);
if (property_set_fd == -1) {
ERROR("start_property_service socket creation failed: %s\n", strerror(errno));
exit(1);
}
listen(property_set_fd, 8);
register_epoll_handler(property_set_fd, handle_property_set_fd);
}
start_property_service()函数创建了socket，然后监听，并且调用register_epoll_handler()函数把socket的fd放入epoll中
函数创建了socket，然后监听，并且调用register_epoll_handler函数把socket的fd放入了epoll中
11、第11部分
这部分主要是解析init.rc文件，我们将会用单独一篇文章来讲解。这里先略过
12、第12部分
本部分是将把Action加入执行队列中
代码在init.cpp 570行
// 执行init.rc中触发器为 on early-init的语句，即将early-init的Action添加到链表action_queue中
action_for_each_trigger("early-init", action_add_queue_tail);
// Queue an action that waits for coldboot done so we know ueventd has set up all of /dev...
// 等冷插拔设备初始化完成，即创建wait_for_coldboot_done Action并添加到action_queue和action_list中
queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done");
// ... so that we can start queuing up actions that require stuff from /dev.
queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
// 设备组合键的初始化操作，创建keychord_init Action 并添加到链表action_queue和action_list中
queue_builtin_action(keychord_init_action, "keychord_init");
// 创建console_init动作并添加到链表action_queue和action_list中
queue_builtin_action(console_init_action, "console_init");
// Trigger all the boot actions to get us started.
// 执行init.rc文件中触发器为 on init 的语句，将init动作添加到链表action_queue中
action_for_each_trigger("init", action_add_queue_tail);
// Repeat mix_hwrng_into_linux_rng in case /dev/hw_random or /dev/random
// wasn't ready immediately after wait_for_coldboot_done
queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
// Don't mount filesystems or start core system services in charger mode.
char bootmode[PROP_VALUE_MAX];
// 当处于充电模式，则charger加入执行队列；否则late-init加入队列。
if (property_get("ro.bootmode", bootmode) > 0 && strcmp(bootmode, "charger") == 0) {
action_for_each_trigger("charger", action_add_queue_tail);
} else {
action_for_each_trigger("late-init", action_add_queue_tail);
}
// Run all property triggers based on current state of the properties.
// 触发器为属性是否设置
queue_builtin_action(queue_property_triggers_action, "queue_property_triggers");
上面大量的调用了action_for_each_trigger函数、action_add_queue_tai函数和queue_builtin_action，那我们就依次研究下这两个函数
12.1 action_for_each_trigger()函数解析
代码在init_parser.cpp 546行
void action_for_each_trigger(const char *trigger,
void (*func)(struct action *act))
{
struct listnode *node, *node2;
struct action *act;
struct trigger *cur_trigger;
list_for_each(node, &action_list) {
// 遍历每个action
act = node_to_item(node, struct action, alist);
list_for_each(node2, &act->triggers) {
// 遍历每个action的triggers
cur_trigger = node_to_item(node2, struct trigger, nlist);
// 判断是否与传入的trigger名字匹配
if (!strcmp(cur_trigger->name, trigger)) {
// 调用回调函数
func(act);
}
}
}
}
12.2 action_add_queue_tail()函数解析
代码在init_parser.cpp 643行
void action_add_queue_tail(struct action *act)
{
if (list_empty(&act->qlist)) {
list_add_tail(&action_queue, &act->qlist);
}
}
这个函数就是把action加入到执行列表中
12.3 queue_builtin_action()函数解析
代码在init_parser.cpp 623行
void queue_builtin_action(int (*func)(int nargs, char **args), const char *name)
{
action* act = (action*) calloc(1, sizeof(*act));
trigger* cur_trigger = (trigger*) calloc(1, sizeof(*cur_trigger));
cur_trigger->name = name;
list_init(&act->triggers);
list_add_tail(&act->triggers, &cur_trigger->nlist);
list_init(&act->commands);
list_init(&act->qlist);
command* cmd = (command*) calloc(1, sizeof(*cmd));
cmd->func = func;
cmd->args[0] = const_cast(name);
cmd->nargs = 1;
list_add_tail(&act->commands, &cmd->clist);
list_add_tail(&action_list, &act->alist);
action_add_queue_tail(act);
}
这个函数的话，就是直接创建一个action，然后新建command，关键是func会调用函数设置好，最后把action加入执行队列中。
queue_builtin_action函数用来动态生成一个Action并插入到执行列表"action_queue中"。插入的Action由一个函数指针和一个表示名字的字符串组成。Android在以前版本中直接调用这些函数来完成某些初始化的工作，但是，这些函数可能会依赖init.rc里面定义的一些命令和服务的执行情况。现在把这些初始化函数也通过Action的形式插入到执行列表中，这样就能控制他们的执行顺序了。
插入的函数有：
- wait_for_coldboot_done_action()函数，等待冷插拔设备初始化完成
- mix_hwrng_into_linux_rng_action()函数，从硬件PNG的设备文件/dev/hw_random中读取512字节并写到Linux RNG的设备文件/dev/urandom中
- keychord_init_action()函数：初始化组合键监听模块
- console_init_action()函数：在屏幕个上显示Android字样的Logo
- property_service_init_action()函数：初始化属性服务，读取系统预制的属性值
- singal_init_action()函数：初始化信号处理模块。
- check_startup_action()函数：检查是否已经完成init进程初始化，如果完成则删除.booting文件。
- queue_property_triggers_action()函数：检查Action列表中通过修改属性来触发的Action，查看相关属性值是否已经设置，如果已经设置，则将Action加入到执行列表中。
执行流程如下图：
13、第13部分
代码在init.cp 1109行
while (true) {
// 判断是否还有事件需要处理
if (!waiting_for_exec) {
//依次执行每个action中携带的command对应的执行函数
execute_one_command();
// 重启一些挂掉的进程
restart_processes();
}
// 决定timeout的时间，将影响while循环的间隔
int timeout = -1;
// 有进程需要重启是，等待进程重启
if (process_needs_restart) {
timeout = (process_needs_restart - gettime()) * 1000;
if (timeout < 0)
timeout = 0;
}
if (!action_queue_empty() || cur_action) {
timeout = 0;
}
// 进行性能数据采样
bootchart_sample(&timeout);
epoll_event ev;
// 没有事件来的话，最多阻塞timeout时间
int nr = TEMP_FAILURE_RETRY(epoll_wait(epoll_fd, &ev, 1, timeout));
if (nr == -1) {
ERROR("epoll_wait failed: %s\n", strerror(errno));
} else if (nr == 1) {
// 根据上下文知道，epoll句柄(即epoll_fd)主要监听子进程结束，及其他进程设置系统属性的请求 ，根据事件的到来，执行对应处理函数
((void (*)()) ev.data.ptr)();
}
}
最后init进程会进入到一个无线循环中去，在这个无线循环中，init进程会做以下五件事：
第一件事：调用函数execute_one_command来检查action_queue列表是否为空。如果不为空的话，那么init进程就将保存在列表头部中的action移除，并且执行这个被移除的action。由于前面我们将一个名称为"console_init"的action添加到action_queue列表中，因此，在这个无线循环中，这个action就会被执行，即console_init_action函数会被调用。
第二件事：调用函数restart_processes来检查系统中是否有进程需要重启。在启动脚本init.rc中，我们可以指定一个进程在退出之后会自动重启。在这种情况下，函数restart_processes就会检查是否存在需要重新启动的进程，如果存在的话，那么就将它重新启动起来。
第三件事：处理系统属性变化事件。当我们调用函数property_set来改变一个系统属性时，系统就会通过一个socket(通过调用函数get_property_set_fd可以获得它的文件描述符)来向init进程发送一个属性值改变事件通知。init进程接受到这个属性值改变事件之后，就会调用函数handle_property_set_fd来进行相应的处理。后面在分析第三个开机画面显示过程时，我们就会看到，SurfaceFlinger服务就是通过修改“ctl.start”和“ctl.stop”属性来启动和停止三个开机画面的。
第四件事：处理一种被称为"chorded keyboard"的键盘输入时间。这种类型为"chorded keyboard"的键盘设备通过不同的按键组合来描述不同的命令或者操作，它对应的设备为/dev/keychord。我们可以通过调用函数get_keychord_fd()来获的这个设备的文件描述符，以便可以监控它的输入事件，并且调用函数handle_keychord来对这些输入事件进行处理。
第五件事：回收僵尸进程。我们知道，在Linux内核中，如果父进程不等待子进程结束就退出，那么当子进程结束的时候，就会变成一个僵尸进程，从而占用系统的资源。为了回收这些僵尸进程，init进程会安装一个SIGCHLD信号接收器。当这些父进程已经退出了子进程退出的时候，内核就会发出一个SIGCHLD信号，给init进程，init进程就可以通过一个socket(通过调用函数get_signal_fd可以获得它的文件描述符)来将接受到的SIGCHLD信号读取回来，并且调用函数handle_signal来对接收到的SIGCHLD信号来进行处理，即回收哪些已经变成僵尸进程的子进程。
PS：后面三件事都是可以通过文件描述符来描述的，因此，initJ进程的入口函数main使用poll机制来同时轮训它们，以便可以提高效率。
下面 这里我们来看一下execute_one_command()函数和restart_processes()函数的具体执行
13.1 execute_one_command函数的执行
代码在init.cpp 584行
void execute_one_command() {
Timer t;
char cmd_str[256] = "";
char name_str[256] = "";
//如果是第一次启动，所以都是NULL，所以肯定可以进入这个判断
//如果不是第一次启动，因为得到cur_action或者cur_command都是null，并且如果这个command是当前action的最后一个command的话，会进入下面的这个判断
if (!cur_action || !cur_command || is_last_command(cur_action, cur_command)) {
// 依次从action_queue获取action
cur_action = action_remove_queue_head();
cur_command = NULL;
if (!cur_action) {
// 如果没有action了，则返回
return;
}
build_triggers_string(name_str, sizeof(name_str), cur_action);
INFO("processing action %p (%s)\n", cur_action, name_str);
// 如果是一个新的action的话，会执行到这一步去获得first command
cur_command = get_first_command(cur_action);
} else {
// 如果还在action的内部链表中，如果仍然存在没有获取到的command的话，则会去获取一下一个command
cur_command = get_next_command(cur_action, cur_command);
}
if (!cur_command) {
//如果可以获取到command为空的话，会返回，反之，继续
return;
}
// 会调用这个command的func去执行，执行的参数个数为nargs，命令为args
int result = cur_command->func(cur_command->nargs, cur_command->args);
if (klog_get_level() >= KLOG_INFO_LEVEL) {
for (int i = 0; i < cur_command->nargs; i++) {
strlcat(cmd_str, cur_command->args[i], sizeof(cmd_str));
if (i < cur_command->nargs - 1) {
strlcat(cmd_str, " ", sizeof(cmd_str));
}
}
char source[256];
if (cur_command->filename) {
snprintf(source, sizeof(source), " (%s:%d)", cur_command->filename, cur_command->line);
} else {
*source = '\0';
}
INFO("Command '%s' action=%s%s returned %d took %.2fs\n",
cmd_str, cur_action ? name_str : "", source, result, t.duration());
}
}
其实这个函数就是执行一个command。大体流程如下：
- 首选从action_queue取下struct action *act赋值给cur_action
- 其次从cur_action获得struct command * 赋值给curcommand
- 最后执行cur_command->func(cur_command->nargs, cur_command->args)
13.1.1 action_remove_queue_head函数的执行
上面调用了action_remove_queue_head()函数，我们来看下
代码在init_parser.cpp 650行
struct action *action_remove_queue_head(void)
{
// 先做非空判断
if (list_empty(&action_queue)) {
return 0;
} else {
// 如果还有未被执行的队列的话，就将node指向现在的action_queue的头指针
struct listnode *node = list_head(&action_queue);
// 取出action
struct action *act = node_to_item(node, struct action, qlist);
// 删将这个节点从整个action_queue的列表中删除
list_remove(node);
// 删除节点后，为了安全起见，将node自己指向自己，以避免出现野指针。
list_init(node);
// 返回 已经找到的action
return act;
}
}
我们知道，其实是从action_queue中拿每一个结构体的，拿到action之后，就从action里面去取对应的command了。
13.1.2 action_remove_queue_head函数的执行
代码在init.cpp 543行
// 由于这个函数主要是从一个action里面找到一个command，所以在传递的时候只传递action即可
static struct command *get_first_command(struct action *act)
{
struct listnode *node;
// 将node 指向action的commands结构体
node = list_head(&act->commands);
if (!node || list_empty(&act->commands))
// 如果这话节点不存在，或者这个action的commands结构体为空，则返回null
return NULL;
// 返回 第一个节点
return node_to_item(node, struct command, clist);
}
13.1.3 get_next_command函数的执行
{
static struct command *get_next_command(struct action *act, struct command *cmd)
{
struct listnode *node;
node = cmd->clist.next;
// 如果不存在，则返回null
if (!node)
return NULL;
// 如果这个节点已经是头节点了，则返回null
if (node == &act->commands)
return NULL;
// 返回 next节点
return node_to_item(node, struct command, clist);
}
这个函数 主要是返回当前commands的下一个command
13.2 restart_processes()函数的执行
当内存不足时，Android系统会自动杀死一些进程来释放空间，所以当某些重要服务被杀，同时该服务进程并未设置为oneshot，则必须重新启动该服务进程。
代码在init.cpp 473行
static void restart_processes()
{
process_needs_restart = 0;
service_for_each_flags(SVC_RESTARTING,
restart_service_if_needed);
}
我们看到这个函数什么都做，就是调用了service_for_each_flags函数，那我们再来研究下这个函数
代码在init_parser.cpp 533行
void service_for_each_flags(unsigned matchflags,
void (*func)(struct service *svc))
{
struct listnode *node;
struct service *svc;
list_for_each(node, &service_list) {
svc = node_to_item(node, struct service, slist);
if (svc->flags & matchflags) {
func(svc);
}
}
}
通过代码我们知道 函数service_for_each_flags主要是循环遍历服务链表，查找标志位为SVC_RESTARTING的服务，当该服务进程死亡的时候，init进程监控进程死亡事件，在处理该事件的时候会为该进程设置SVC_RESTARTING标志，并调用restart_service_if_needed函数重启服务。
我们来看下restart_service_if_needed函数
代码在init.cpp 457行
static void restart_service_if_needed(struct service *svc)
{
time_t next_start_time = svc->time_started + 5;
if (next_start_time <= gettime()) {
svc->flags &= (~SVC_RESTARTING);
service_start(svc, NULL);
return;
}
if ((next_start_time < process_needs_restart) ||
(process_needs_restart == 0)) {
process_needs_restart = next_start_time;
}
}
只有当前时间大于服务启动时间时，清除服务重启标志并启动该服务，
上一篇文章 1序言、bootloader引导与Linux启动
下一篇文章 Android系统启动——3init.rc解析