Android 8.1 启动篇（一） -- 深入研究 init
前言
init进程，它是一个由内核启动的用户级进程，当Linux内核启动之后，运行的第一个进程是init，这个进程是一个守护进程，确切的说，它是Linux系统中用户控件的第一个进程，所以它的进程号是1。它的生命周期贯穿整个linux 内核运行的始终， linux中所有其它的进程的共同始祖均为init进程。
开篇
核心源码
Android 版本 | 关键类 | 路径
- | - | -
8.1 | init.rc | system/core/rootdir/init.rc
8.1 | init.cpp | system/core/init/init.cpp
8.1 | property_service.cpp | system/core/init/property_service.cpp
8.1 | init_parser.h | system/core/init/init_parser.h
8.1 | init_parser.cpp | system/core/init/init_parser.cpp
8.1 | log.cpp | system/core/init/log.cpp
8.1 | logging.cpp | system/core/base/logging.cpp
8.1 | property_service.cpp | system/core/init/property_service.cpp
8.1 | signal_handler.cpp | system/core/init/signal_handler.cpp
8.1 | service.cpp | system/core/init/service.cpp
8.1 | Action.cpp | system/core/init/Action.cpp
8.1 | builtins.cpp | system/core/init/builtins.cpp
Android系统启动过程
1. 按下电源系统启动
当电源按下时引导芯片代码开始从预定义的地方（固化在ROM）开始执行，加载引导程序Bootloader到RAM，然后执行。
2. 引导程序Bootloader
引导程序是在Android操作系统开始运行前的一个小程序，它的主要作用是把系统OS拉起来并运行。
3. linux内核启动
内核启动时，设置缓存、被保护存储器、计划列表，加载驱动。当内核完成系统设置，它首先在系统文件中寻找”init”文件，然后启动root进程或者系统的第一个进程。
4. init进程启动
✨ 这就是我们接下来要讨论的内容 ✨
Read The Fucking Code
Android init进程的入口文件在system/core/init/init.cpp中，由于init是命令行程序，所以分析init.cpp首先应从main函数开始：
第一阶段（内核态）
判断及增加环境变量
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
//根据参数，判断是否需要启动ueventd和watchdogd
if (!strcmp(basename(argv[0]), "ueventd")) { // 启动ueventd
return ueventd_main(argc, argv);
}
if (!strcmp(basename(argv[0]), "watchdogd")) { // 启动watchdogd
return watchdogd_main(argc, argv);
}
if (REBOOT_BOOTLOADER_ON_PANIC) {
InstallRebootSignalHandlers(); // 若紧急重启，则安装对应的消息处理器
}
add_environment("PATH", _PATH_DEFPATH); // 添加环境变量
... ...
}
创建并挂载相关的文件系统
int main(int argc, char** argv) {
/* 01. 判断及增加环境变量 */
bool is_first_stage = (getenv("INIT_SECOND_STAGE") == nullptr);
if (is_first_stage) { // 判断是否是系统启动的第一阶段（第一次进入：true）
boot_clock::time_point start_time = boot_clock::now(); // 用于记录启动时间
// Clear the umask.
umask(0); // 清除屏蔽字(file mode creation mask)，保证新建的目录的访问权限不受屏蔽字影响
// 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.
mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755"); // 挂载tmpfs文件系统
mkdir("/dev/pts", 0755);
mkdir("/dev/socket", 0755);
mount("devpts", "/dev/pts", "devpts", 0, NULL); // 挂载devpts文件系统
#define MAKE_STR(x) __STRING(x)
mount("proc", "/proc", "proc", 0, "hidepid=2,gid=" MAKE_STR(AID_READPROC)); // 挂载proc文件系统
// Don't expose the raw commandline to unprivileged processes.
chmod("/proc/cmdline", 0440); // 8.0新增, 收紧了cmdline目录的权限
gid_t groups[] = { AID_READPROC }; // 8.0新增，增加了个用户组
setgroups(arraysize(groups), groups);
mount("sysfs", "/sys", "sysfs", 0, NULL); // 挂载sysfs文件系统
mount("selinuxfs", "/sys/fs/selinux", "selinuxfs", 0, NULL); // 8.0新增
mknod("/dev/kmsg", S_IFCHR | 0600, makedev(1, 11)); // 提前创建了kmsg设备节点文件，用于输出log信息
mknod("/dev/random", S_IFCHR | 0666, makedev(1, 8));
mknod("/dev/urandom", S_IFCHR | 0666, makedev(1, 9));
... ...
}
如上所示，该部分主要用于创建和挂载启动所需的文件目录。需要注意的是，在编译Android系统源码时，在生成的根文件系统中， 并不存在这些目录，它们是系统运行时的目录，即当系统终止时，就会消失。
四类文件系统：
tmpfs：一种虚拟内存文件系统，它会将所有的文件存储在虚拟内存中，如果你将tmpfs文件系统卸载后，那么其下的所有的内容将不复存在。tmpfs既可以使用RAM，也可以使用交换分区，会根据你的实际需要而改变大小。tmpfs的速度非常惊人，毕竟它是驻留在RAM中的，即使用了交换分区，性能仍然非常卓越。由于tmpfs是驻留在RAM的，因此它的内容是不持久的。断电后，tmpfs的内容就消失了，这也是被称作tmpfs的根本原因。
devpts：为伪终端提供了一个标准接口，它的标准挂接点是/dev/ pts。只要pty的主复合设备/dev/ptmx被打开，就会在/dev/pts下动态的创建一个新的pty设备文件。
proc：一个非常重要的虚拟文件系统，它可以看作是内核内部数据结构的接口，通过它我们可以获得系统的信息，同时也能够在运行时修改特定的内核参数。
sysfs：与proc文件系统类似，也是一个不占有任何磁盘空间的虚拟文件系统。它通常被挂接在/sys目录下。sysfs文件系统是Linux2.6内核引入的，它把连接在系统上的设备和总线组织成为一个分级的文件，使得它们可以在用户空间存取。
重定向输入输出/内核Log系统
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建并挂载相关的文件系统 */
if (is_first_stage) {
... ...
// Now that tmpfs is mounted on /dev and we have /dev/kmsg, we can actually
// talk to the outside world...
InitKernelLogging(argv);
... ...
}
... ...
屏蔽标准的输入输出
跟踪InitKernelLogging()： system/core/init/log.cpp
void InitKernelLogging(char* argv[]) {
// Make stdin/stdout/stderr all point to /dev/null.
int fd = open("/sys/fs/selinux/null", O_RDWR);
if (fd == -1) { // 若开启失败，则记录log
int saved_errno = errno;
android::base::InitLogging(argv, &android::base::KernelLogger);
errno = saved_errno;
PLOG(FATAL) << "Couldn't open /sys/fs/selinux/null";
}
dup2(fd, 0); // dup2函数的作用是用来复制一个文件的描述符， 通常用来重定向进程的stdin、stdout和stderr
dup2(fd, 1); // 它的函数原形是：int dup2(int oldfd, int targetfd)，该函数执行后，targetfd将变成oldfd的复制品
dup2(fd, 2); // 因此这边的过程其实就是：创建出__null__设备后，将0、1、2绑定到__null__设备上
if (fd > 2) close(fd); // 所以init进程调用InitKernelLogging函数后，通过标准的输入输出无法输出信息
android::base::InitLogging(argv, &android::base::KernelLogger);
}
设置kernel logger
跟踪InitLogging()：system/core/base/logging.cpp
// 设置KernelLogger
void InitLogging(char* argv[], LogFunction&& logger, AbortFunction&& aborter) {
//设置logger
SetLogger(std::forward<LogFunction>(logger));
SetAborter(std::forward<AbortFunction>(aborter));
if (gInitialized) {
return;
}
gInitialized = true;
// Stash the command line for later use. We can use /proc/self/cmdline on
// Linux to recover this, but we don't have that luxury on the Mac/Windows,
// and there are a couple of argv[0] variants that are commonly used.
if (argv != nullptr) {
std::lock_guard<std::mutex> lock(LoggingLock());
ProgramInvocationName() = basename(argv[0]);
}
const char* tags = getenv("ANDROID_LOG_TAGS");
if (tags == nullptr) {
return;
}
// 根据TAG决定最小记录等级
std::vector<std::string> specs = Split(tags, " ");
for (size_t i = 0; i < specs.size(); ++i) {
// "tag-pattern:[vdiwefs]"
std::string spec(specs[i]);
if (spec.size() == 3 && StartsWith(spec, "*:")) {
switch (spec[2]) {
case 'v':
gMinimumLogSeverity = VERBOSE;
continue;
... ...
}
}
LOG(FATAL) << "unsupported '" << spec << "' in ANDROID_LOG_TAGS (" << tags
<< ")";
}
}
当需要输出日志时，KernelLogger函数就会被调用：
#if defined(__linux__)
void KernelLogger(android::base::LogId, android::base::LogSeverity severity,
const char* tag, const char*, unsigned int, const char* msg) {
... ...
// 打开log节点
static int klog_fd = TEMP_FAILURE_RETRY(open("/dev/kmsg", O_WRONLY | O_CLOEXEC));
if (klog_fd == -1) return;
// 决定log等级
int level = kLogSeverityToKernelLogLevel[severity];
// The kernel's printk buffer is only 1024 bytes.
// TODO: should we automatically break up long lines into multiple lines?
// Or we could log but with something like "..." at the end?
char buf[1024];
size_t size = snprintf(buf, sizeof(buf), "<%d>%s: %s\n", level, tag, msg);
if (size > sizeof(buf)) {
size = snprintf(buf, sizeof(buf), "<%d>%s: %zu-byte message too long for printk\n",
level, tag, size);
}
iovec iov[1];
iov[0].iov_base = buf;
iov[0].iov_len = size;
// 通过iovec将log发送到dev/kmsg
TEMP_FAILURE_RETRY(writev(klog_fd, iov, 1));
}
#endif
挂在一些分区设备
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建文件系统目录并挂载相关的文件系统 */
/* 03. 重定向输入输出/内核Log系统 */
if (is_first_stage) {
... ...
// 挂载特定的分区设备
if (!DoFirstStageMount()) {
LOG(ERROR) << "Failed to mount required partitions early ...";
panic(); // panic会尝试reboot
}
}
... ...
跟踪DoFirstStageMount()：system/core/init/init_first_stage.cpp
// Mounts partitions specified by fstab in device tree.
bool DoFirstStageMount() {
// Skips first stage mount if we're in recovery mode.
if (IsRecoveryMode()) {
LOG(INFO) << "First stage mount skipped (recovery mode)";
return true;
}
// Firstly checks if device tree fstab entries are compatible.
if (!is_android_dt_value_expected("fstab/compatible", "android,fstab")) {
LOG(INFO) << "First stage mount skipped (missing/incompatible fstab in device tree)";
return true;
}
// 满足上述条件时，就会调用FirstStageMount的DoFirstStageMount函数
std::unique_ptr<FirstStageMount> handle = FirstStageMount::Create();
if (!handle) {
LOG(ERROR) << "Failed to create FirstStageMount";
return false;
}
// 主要是初始化特定设备并挂载
return handle->DoFirstStageMount();
}
完成SELinux相关工作
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建文件系统目录并挂载相关的文件系统 */
/* 03. 重定向输入输出/内核Log系统 */
/* 04. 挂在一些分区设备 */
if (is_first_stage) {
... ...
// 此处应该是初始化安全框架：Android Verified Boot
// AVB主要用于防止系统文件本身被篡改，还包含了防止系统回滚的功能，
// 以免有人试图回滚系统并利用以前的漏洞
SetInitAvbVersionInRecovery();
// Set up SELinux, loading the SELinux policy.
selinux_initialize(true); // 调用selinux_initialize启动SELinux
... ...
}
... ...
跟踪selinux_initialize()：
static void selinux_initialize(bool in_kernel_domain) {
Timer t;
selinux_callback cb;
cb.func_log = selinux_klog_callback; // 用于打印log的回调函数
selinux_set_callback(SELINUX_CB_LOG, cb);
cb.func_audit = audit_callback; // 用于检查权限的回调函数
selinux_set_callback(SELINUX_CB_AUDIT, cb);
// init进程的运行是区分用户态和内核态的，first_stage运行在内核态
if (in_kernel_domain) {
LOG(INFO) << "Loading SELinux policy";
// 用于加载sepolicy文件
// 该函数最终将sepolicy文件传递给kernel，这样kernel就有了安全策略配置文件，后续的MAC才能开展起来。
if (!selinux_load_policy()) {
panic();
}
bool kernel_enforcing = (security_getenforce() == 1); // 内核中读取的信息
bool is_enforcing = selinux_is_enforcing(); // 命令行中得到的数据
// 用于设置selinux的工作模式。selinux有两种工作模式：
// 1、”permissive”，所有的操作都被允许（即没有MAC），但是如果违反权限的话，会记录日志
// 2、”enforcing”，所有操作都会进行权限检查。在一般的终端中，应该工作于enforing模式
if (kernel_enforcing != is_enforcing) {
if (security_setenforce(is_enforcing)) {
PLOG(ERROR) << "security_setenforce(%s) failed" << (is_enforcing ? "true" : "false");
security_failure(); // 将重启进入recovery mode
}
}
std::string err;
if (!WriteFile("/sys/fs/selinux/checkreqprot", "0", &err)) {
LOG(ERROR) << err;
security_failure();
}
// init's first stage can't set properties, so pass the time to the second stage.
setenv("INIT_SELINUX_TOOK", std::to_string(t.duration().count()).c_str(), 1);
} else {
selinux_init_all_handles(); // 在second stage调用时，初始化所有的handle
}
}
is_first_stage 收尾
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建文件系统目录并挂载相关的文件系统 */
/* 03. 重定向输入输出/内核Log系统 */
/* 04. 挂在一些分区设备 */
/* 05. 完成SELinux相关工作 */
if (is_first_stage) {
... ...
// We're in the kernel domain, so re-exec init to transition to the init domain now
// that the SELinux policy has been loaded.
if (selinux_android_restorecon("/init", 0) == -1) { // 按selinux policy要求，重新设置init文件属性
PLOG(ERROR) << "restorecon failed";
security_failure(); // 失败的话会reboot
}
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); // 记录初始化时的时间
char* path = argv[0];
char* args[] = { path, nullptr };
execv(path, args); // 再次调用init的main函数，启动用户态的init进程
// execv() only returns if an error happened, in which case we
// panic and never fall through this conditional.
PLOG(ERROR) << "execv(\"" << path << "\") failed";
security_failure(); // 内核态的进程不应该退出，若退出则会重启
}
/* 06. is_first_stage 收尾 */
/* ------------ 第一阶段 ------------- END ------------ */
... ...
}
上面所有的源码我们都是围绕第一阶段分析（is_first_stage），自此第一阶段结束，会复位一些信息，并设置一些环境变量，最后启动用户态的init进程，进入init第二阶段。
第二阶段（用户态）
init进程的第二阶段仍然从main函数开始入手（继续分析main函数剩余源码）
初始化属性域
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建文件系统目录并挂载相关的文件系统 */
/* 03. 重定向输入输出/内核Log系统 */
/* 04. 挂在一些分区设备 */
/* 05. 完成SELinux相关工作 */
/* 06. is_first_stage 收尾 */
/* ------------ 第一阶段 ------------- END ------------ */
/* ------------ 第二阶段 ------------ BEGIN------------ */
// 同样进行一些判断及环境变量设置的工作
... ...
// 现在 is_first_stage 为 false 了
bool is_first_stage = (getenv("INIT_SECOND_STAGE") == nullptr);
// 这部分工作不再执行了
if (is_first_stage) {
...........
}
// At this point we're in the second stage of init.
InitKernelLogging(argv); // 同样屏蔽标准输入输出及定义Kernel logger
LOG(INFO) << "init second stage started!";
// 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); // 最后调用syscall，设置安全相关的值
// Indicate that booting is in progress to background fw loaders, etc.
close(open("/dev/.booting", O_WRONLY | O_CREAT | O_CLOEXEC, 0000)); // 这里的功能类似于“锁”
... ...
property_init(); // 初始化属性域 --> 定义于system/core/init/property_service.cpp
// If arguments are passed both on the command line and in DT,
// properties set in DT always have priority over the command-line ones.
process_kernel_dt();
process_kernel_cmdline(); // 处理内核命令
// Propagate the kernel variables to internal variables
// used by init as well as the current required properties.
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);
... ...
}
这部分代码主要的工作应该就是调用 property_init 初始化属性域，然后设置各种属性。
在Android平台中，为了让运行中的所有进程共享系统运行时所需要的各种设置值，系统开辟了属性存储区域，并提供了访问该区域的API。
跟踪property_init()：system/core/init/property_service.cpp
void property_init() {
if (__system_property_area_init()) { // 最终调用_system_property_area_init函数初始化属性域
LOG(ERROR) << "Failed to initialize property area";
exit(1);
}
}
清空环境变量
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建文件系统目录并挂载相关的文件系统 */
/* 03. 重定向输入输出/内核Log系统 */
/* 04. 挂在一些分区设备 */
/* 05. 完成SELinux相关工作 */
/* 06. is_first_stage 收尾 */
/* ------------ 第一阶段 ------------- END ------------ */
/* ------------ 第二阶段 ------------ BEGIN------------ */
/* 01. 初始化属性域 */
// Clean up our environment.
unsetenv("INIT_SECOND_STAGE");
unsetenv("INIT_STARTED_AT"); // 清除掉之前使用过的环境变量
unsetenv("INIT_SELINUX_TOOK");
unsetenv("INIT_AVB_VERSION");
... ...
}
完成SELinux相关工作
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建文件系统目录并挂载相关的文件系统 */
/* 03. 重定向输入输出/内核Log系统 */
/* 04. 挂在一些分区设备 */
/* 05. 完成SELinux相关工作 */
/* 06. is_first_stage 收尾 */
/* ------------ 第一阶段 ------------- END ------------ */
/* ------------ 第二阶段 ------------ BEGIN------------ */
/* 01. 初始化属性域 */
/* 02. 清空环境变量 */
// Now set up SELinux for second stage.
selinux_initialize(false);
selinux_restore_context(); // 再次完成selinux相关的工作
我们发现在init进程的第一阶段，也调用了selinux_initialize函数，那么两者有什么区别？
init进程第一阶段主要加载selinux相关的策略，而第二阶段调用selinux_initialize仅仅注册一些处理器。
我们跟下selinux_initialize()：
static void selinux_initialize(bool in_kernel_domain) {
Timer t;
selinux_callback cb;
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 (in_kernel_domain) {
... ... // 这边就是第一阶段的工作
} else {
selinux_init_all_handles(); // 这边就是第二阶段的工作：注册处理器
}
}
再来看一下selinux_restore_context()：主要是按 selinux policy 要求，重新设置一些文件的属性。
// The files and directories that were created before initial sepolicy load or
// files on ramdisk need to have their security context restored to the proper
// value. This must happen before /dev is populated by ueventd.
// 如注释所述，以下文件在selinux被加载前就创建了
// 于是，在selinux启动后，需要重新设置一些属性
static void selinux_restore_context() {
LOG(INFO) << "Running restorecon...";
selinux_android_restorecon("/dev", 0);
selinux_android_restorecon("/dev/kmsg", 0);
selinux_android_restorecon("/dev/socket", 0);
selinux_android_restorecon("/dev/random", 0);
selinux_android_restorecon("/dev/urandom", 0);
selinux_android_restorecon("/dev/__properties__", 0);
selinux_android_restorecon("/plat_file_contexts", 0);
selinux_android_restorecon("/nonplat_file_contexts", 0);
selinux_android_restorecon("/plat_property_contexts", 0);
selinux_android_restorecon("/nonplat_property_contexts", 0);
selinux_android_restorecon("/plat_seapp_contexts", 0);
selinux_android_restorecon("/nonplat_seapp_contexts", 0);
selinux_android_restorecon("/plat_service_contexts", 0);
selinux_android_restorecon("/nonplat_service_contexts", 0);
selinux_android_restorecon("/plat_hwservice_contexts", 0);
selinux_android_restorecon("/nonplat_hwservice_contexts", 0);
selinux_android_restorecon("/sepolicy", 0);
selinux_android_restorecon("/vndservice_contexts", 0);
selinux_android_restorecon("/dev/block", SELINUX_ANDROID_RESTORECON_RECURSE);
selinux_android_restorecon("/dev/device-mapper", 0);
selinux_android_restorecon("/sbin/mke2fs_static", 0);
selinux_android_restorecon("/sbin/e2fsdroid_static", 0);
}
创建epoll句柄
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建文件系统目录并挂载相关的文件系统 */
/* 03. 重定向输入输出/内核Log系统 */
/* 04. 挂在一些分区设备 */
/* 05. 完成SELinux相关工作 */
/* 06. is_first_stage 收尾 */
/* ------------ 第一阶段 ------------- END ------------ */
/* ------------ 第二阶段 ------------ BEGIN------------ */
/* 01. 初始化属性域 */
/* 02. 清空环境变量 */
/* 03. 完成SELinux相关工作 */
epoll_fd = epoll_create1(EPOLL_CLOEXEC); // 调用epoll_create1创建epoll句柄
if (epoll_fd == -1) {
PLOG(ERROR) << "epoll_create1 failed";
exit(1);
}
... ...
}
在linux的网络编程中，很长的时间都在使用 select 来做事件触发。在linux新的内核中，有了一种替换它的机制，就是 epoll。
相比于select，epoll最大的好处在于它不会随着监听fd数目的增长而降低效率。因为在内核中的 select 实现中，它是采用轮询来处理的，轮询的fd数目越多，自然耗时越多。
epoll机制一般使用epoll_create(int size)函数创建epoll句柄，size用来告诉内核这个句柄可监听的fd的数目。
注意这个参数不同于select()中的第一个参数，在select中需给出最大监听数加1的值。
此外，当创建好epoll句柄后，它就会占用一个fd值，在linux下如果查看/proc/进程id/fd/，能够看到创建出的fd，因此在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。
上述代码使用的epoll_create1(EPOLL_CLOEXEC)来创建epoll句柄，该标志位表示生成的epoll fd具有“执行后关闭”特性。
装载子进程信号处理器
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建文件系统目录并挂载相关的文件系统 */
/* 03. 重定向输入输出/内核Log系统 */
/* 04. 挂在一些分区设备 */
/* 05. 完成SELinux相关工作 */
/* 06. is_first_stage 收尾 */
/* ------------ 第一阶段 ------------- END ------------ */
/* ------------ 第二阶段 ------------ BEGIN------------ */
/* 01. 初始化属性域 */
/* 02. 清空环境变量 */
/* 03. 完成SELinux相关工作 */
/* 04. 创建epoll句柄 */
signal_handler_init(); // 装载子进程信号处理器
}
init是一个守护进程，为了防止init的子进程成为僵尸进程(zombie process)，需要init在子进程在结束时获取子进程的结束码，通过结束码将程序表中的子进程移除，防止成为僵尸进程的子进程占用程序表的空间（程序表的空间达到上限时，系统就不能再启动新的进程了，会引起严重的系统问题）。
在linux当中，父进程是通过捕捉 SIGCHLD 信号来得知子进程运行结束的情况，此处init进程调用 signal_handler_init 的目的就是捕获子进程结束的信号。
我们跟踪下signal_handler_init()：
void signal_handler_init() {
// Create a signalling mechanism for SIGCHLD.
int s[2];
// 利用socketpair创建出已经连接的两个socket，分别作为信号的读、写端
if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK | SOCK_CLOEXEC, 0, s) == -1) {
PLOG(ERROR) << "socketpair failed";
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);
// 用于终止出现问题的子进程
ServiceManager::GetInstance().ReapAnyOutstandingChildren();
// 注册信号处理函数handle_signal
register_epoll_handler(signal_read_fd, handle_signal);
}
在深入分析代码前，我们需要了解一些基本概念：Linux进程通过互相发送消息来实现进程间的通信，这些消息被称为“信号”。每个进程在处理其它进程发送的信号时都要注册处理者，处理者被称为信号处理器。
注意到sigaction结构体的sa_flags为SA_NOCLDSTOP。由于系统默认在子进程暂停时也会发送信号SIGCHLD，init需要忽略子进程在暂停时发出的SIGCHLD信号，因此将act.sa_flags 置为SA_NOCLDSTOP，该标志位表示仅当进程终止时才接受SIGCHLD信号。
接下来，我们分步骤详细了解一下signal_handler_init具体的工作流程。
SIGCHLD_handler
// system/core/init/signal_handler.cpp
static void SIGCHLD_handler(int) {
if (TEMP_FAILURE_RETRY(write(signal_write_fd, "1", 1)) == -1) {
PLOG(ERROR) << "write(signal_write_fd) failed";
}
}
从上面代码我们知道，init进程是所有进程的父进程，当其子进程终止产生SIGCHLD信号时，SIGCHLD_handler将对signal_write_fd执行写操作。由于socketpair的绑定关系，这将触发信号对应的signal_read_fd收到数据。
register_epoll_handler
根据前文的代码我们知道，在装载信号监听器的最后，signal_handler_init调用了register_epoll_handler，其代码如下所示，注意传入的参数分别为signal_read_fd和handle_signal：
// system/core/init/init.cpp
void register_epoll_handler(int fd, void (*fn)()) {
epoll_event ev;
ev.events = EPOLLIN;
ev.data.ptr = reinterpret_cast<void*>(fn);
// epoll_fd增加一个监听对象fd,fd上有数据到来时，调用fn处理
if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd, &ev) == -1) {
PLOG(ERROR) << "epoll_ctl failed";
}
}
根据代码不难看出：当epoll句柄监听到signal_read_fd中有数据可读时，将调用handle_signal进行处理。
至此，结合上文我们知道：当init进程调用signal_handler_init后，一旦收到子进程终止带来的SIGCHLD消息后，将利用信号处理者SIGCHLD_handler向signal_write_fd写入信息；由于绑定的关系，epoll句柄将监听到signal_read_fd收到消息，于是将调用handle_signal进行处理。
handle_signal
// system/core/init/signal_handler.cpp
static void handle_signal() {
// Clear outstanding requests.
char buf[32];
read(signal_read_fd, buf, sizeof(buf));
ServiceManager::GetInstance().ReapAnyOutstandingChildren();
}
从代码中可以看出，handle_signal只是清空signal_read_fd中的数据，然后调用ServiceManager::GetInstance().ReapAnyOutstandingChildren()。
ServiceManager定义于 system/core/init/service.cpp 中，是一个单例对象：
... ...
ServiceManager::ServiceManager() {
}
ServiceManager& ServiceManager::GetInstance() {
static ServiceManager instance;
return instance;
}
... ...
void ServiceManager::ReapAnyOutstandingChildren() {
while (ReapOneProcess()) {
}
}
... ...
如上所示，ReapAnyOutstandingChildren函数实际上调用了ReapOneProcess。我们结合代码，看看ReapOneProcess的具体工作。
bool ServiceManager::ReapOneProcess() {
siginfo_t siginfo = {};
// This returns a zombie pid or informs us that there are no zombies left to be reaped.
// It does NOT reap the pid; that is done below.
//用waitid函数获取状态发生变化的子进程pid
//waitid的标记为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;
// At this point we know we have a zombie pid, so we use this scopeguard to reap the pid
// whenever the function returns from this point forward.
// We do NOT want to reap the zombie earlier as in Service::Reap(), we kill(-pid, ...) and we
// want the pid to remain valid throughout that (and potentially future) usages.
auto reaper = make_scope_guard([pid] { TEMP_FAILURE_RETRY(waitpid(pid, nullptr, WNOHANG)); });
if (PropertyChildReap(pid)) {
return true;
}
// 利用FindServiceByPid函数，找到pid对应的服务
// FindServiceByPid主要通过轮询解析init.rc生成的service_list，找到pid与参数一致的srvc
Service* svc = FindServiceByPid(pid);
... ... // 输出服务结束的原因
if (!svc) { // 没有找到，说明已经结束了
return true;
}
svc->Reap();
// 根据svc的类型，决定后续的处理方式
if (svc->flags() & SVC_EXEC) {
exec_waiter_.reset(); // 可执行服务则重置对应的waiter
}
if (svc->flags() & SVC_TEMPORARY) {
RemoveService(*svc); // 移除临时服务
}
return true;
}
Reap
void Service::Reap() {
// 清理未携带SVC_ONESHOT 或 携带了SVC_RESTART标志的srvc的进程组
if (!(flags_ & SVC_ONESHOT) || (flags_ & SVC_RESTART)) {
KillProcessGroup(SIGKILL);
}
// Remove any descriptor resources we may have created.
// 清除srvc中创建出的任意描述符
std::for_each(descriptors_.begin(), descriptors_.end(),
std::bind(&DescriptorInfo::Clean, std::placeholders::_1));
// 清理工作完毕后，后面决定是否重启机器或重启服务
// TEMP服务不用参与这种判断
if (flags_ & SVC_TEMPORARY) {
return;
}
pid_ = 0;
flags_ &= (~SVC_RUNNING);
// Oneshot processes go into the disabled state on exit,
// except when manually restarted.
// 对于携带了SVC_ONESHOT并且未携带SVC_RESTART的srvc，将这类服务的标志置为SVC_DISABLED，不再自启动
if ((flags_ & SVC_ONESHOT) && !(flags_ & SVC_RESTART)) {
flags_ |= SVC_DISABLED;
}
// Disabled and reset processes do not get restarted automatically.
if (flags_ & (SVC_DISABLED | SVC_RESET)) {
NotifyStateChange("stopped");
return;
}
// If we crash > 4 times in 4 minutes, reboot into recovery.
boot_clock::time_point now = boot_clock::now();
// 未携带SVC_RESTART的关键服务，在规定的间隔内，crash字数过多时，会导致整机重启；
if ((flags_ & SVC_CRITICAL) && !(flags_ & SVC_RESTART)) {
if (now < time_crashed_ + 4min) {
if (++crash_count_ > 4) {
LOG(ERROR) << "critical process '" << name_ << "' exited 4 times in 4 minutes";
panic();
}
} else {
time_crashed_ = now;
crash_count_ = 1;
}
}
// 将待重启srvc的标志位置为SVC_RESTARTING（init进程将根据该标志位，重启服务）
flags_ &= (~SVC_RESTART);
flags_ |= SVC_RESTARTING;
// Execute all onrestart commands for this service.
// 重启在init.rc文件中带有onrestart选项的服务
onrestart_.ExecuteAllCommands();
NotifyStateChange("restarting");
return;
}
不难看出，Reap函数的主要作用就是清除问题进程相关的资源，然后根据进程对应的类型，决定是否重启机器或重启进程。
ExecuteAllCommands
我们在这一部分的最后，看看定义于system/core/init/Action.cpp中的ExecuteAllCommands函数：
void Action::ExecuteAllCommands() const {
for (const auto& c : commands_) {
ExecuteCommand(c);
}
}
void Action::ExecuteCommand(const Command& command) const {
android::base::Timer t;
// 进程重启时，将执行对应的函数
int result = command.InvokeFunc();
// 打印log
auto duration = t.duration();
// Any action longer than 50ms will be warned to user as slow operation
if (duration > 50ms || android::base::GetMinimumLogSeverity() <= android::base::DEBUG) {
std::string trigger_name = BuildTriggersString();
std::string cmd_str = command.BuildCommandString();
LOG(INFO) << "Command '" << cmd_str << "' action=" << trigger_name << " (" << filename_
<< ":" << command.line() << ") returned " << result << " took "
<< duration.count() << "ms.";
}
}
整个signal_handler_init的内容比较多，在此总结一下：signal_handler_init的本质就是监听子进程死亡的信息，然后进行对应的清理工作，并根据死亡进程的类型，决定是否需要重启进程或机器。
启动属性服务
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建文件系统目录并挂载相关的文件系统 */
/* 03. 重定向输入输出/内核Log系统 */
/* 04. 挂在一些分区设备 */
/* 05. 完成SELinux相关工作 */
/* 06. is_first_stage 收尾 */
/* ------------ 第一阶段 ------------- END ------------ */
/* ------------ 第二阶段 ------------ BEGIN------------ */
/* 01. 初始化属性域 */
/* 02. 清空环境变量 */
/* 03. 完成SELinux相关工作 */
/* 04. 创建epoll句柄 */
/* 05. 装载子进程信号处理器 */
property_load_boot_defaults(); // 进程调用property_load_boot_defaults进行默认属性配置相关的工作
export_oem_lock_status(); // 最终就是决定"ro.boot.flash.locked"的值
start_property_service(); // 启动属性服务
set_usb_controller();
... ...
}
老样子，这边我们跟踪几个重要的函数。
property_load_boot_defaults
void property_load_boot_defaults() {
// 就是从各种路径读取默认配置
// load_properties_from_file的基本操作就是read_file，然后解析并设置
if (!load_properties_from_file("/system/etc/prop.default", NULL)) {
// Try recovery path
if (!load_properties_from_file("/prop.default", NULL)) {
// Try legacy path
load_properties_from_file("/default.prop", NULL);
}
}
load_properties_from_file("/odm/default.prop", NULL);
load_properties_from_file("/vendor/default.prop", NULL);
update_sys_usb_config(); // 就是设置"persist.sys.usb.config"相关的配置
}
如代码所示，property_load_boot_defaults 实际上就是调用 load_properties_from_file 解析配置文件，然后根据解析的结果，设置系统属性。
start_property_service
void start_property_service() {
property_set("ro.property_service.version", "2");
// 创建了一个非阻塞socket
property_set_fd = CreateSocket(PROP_SERVICE_NAME, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
false, 0666, 0, 0, nullptr, sehandle);
if (property_set_fd == -1) {
PLOG(ERROR) << "start_property_service socket creation failed";
exit(1);
}
// 调用listen函数监听property_set_fd， 于是该socket变成一个server
listen(property_set_fd, 8);
// 监听server socket上是否有数据到来
register_epoll_handler(property_set_fd, handle_property_set_fd);
}
init进程在共享内存区域中，创建并初始化属性域。其它进程可以访问属性域中的值，但更改属性值仅能在init进程中进行。这就是init进程调用start_property_service的原因。
其它进程修改属性值时，要预先向init进程提交值变更申请，然后init进程处理该申请，并修改属性值。在访问和修改属性时，init进程都可以进行权限控制。
匹配命令和函数之间对应关系
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建文件系统目录并挂载相关的文件系统 */
/* 03. 重定向输入输出/内核Log系统 */
/* 04. 挂在一些分区设备 */
/* 05. 完成SELinux相关工作 */
/* 06. is_first_stage 收尾 */
/* ------------ 第一阶段 ------------- END ------------ */
/* ------------ 第二阶段 ------------ BEGIN------------ */
/* 01. 初始化属性域 */
/* 02. 清空环境变量 */
/* 03. 完成SELinux相关工作 */
/* 04. 创建epoll句柄 */
/* 05. 装载子进程信号处理器 */
/* 06. 启动属性服务*/
const BuiltinFunctionMap function_map; // system/core/init/builtins.cpp，定义Action中的function_map_为BuiltinFuntionMap
Action::set_function_map(&function_map); // 在Action中保存function_map对象，记录了命令与函数之间的对应关系
/* 07. 匹配命令和函数之间对应关系 */
/* ------------ 第二阶段 ------------ END ------------ */
... ...
}
至此，init进程的准备工作执行完毕， 接下来就要开始解析init.rc文件了。
第三阶段（init.rc）
解析init.rc
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建文件系统目录并挂载相关的文件系统 */
/* 03. 重定向输入输出/内核Log系统 */
/* 04. 挂在一些分区设备 */
/* 05. 完成SELinux相关工作 */
/* 06. is_first_stage 收尾 */
/* ------------ 第一阶段 ------------- END ------------ */
/* ------------ 第二阶段 ------------ BEGIN------------ */
/* 01. 初始化属性域 */
/* 02. 清空环境变量 */
/* 03. 完成SELinux相关工作 */
/* 04. 创建epoll句柄 */
/* 05. 装载子进程信号处理器 */
/* 06. 启动属性服务*/
/* 07. 匹配命令和函数之间对应关系 */
/* ------------ 第二阶段 ------------ END ------------ */
/* ------------ 第三阶段 ----------- BEGIN------------ */
ActionManager& am = ActionManager::GetInstance();
ServiceManager& sm = ServiceManager::GetInstance();
Parser& parser = Parser::GetInstance(); // 构造解析文件用的parser对象
// 为一些类型的关键字，创建特定的parser
parser.AddSectionParser("service", std::make_unique<ServiceParser>(&sm)); // 增加ServiceParser为一个section，对应name为service
parser.AddSectionParser("on", std::make_unique<ActionParser>(&am)); // 增加ActionParser为一个section，对应name为action
parser.AddSectionParser("import", std::make_unique<ImportParser>(&parser)); // 增加ActionParser为一个section，对应name为import
std::string bootscript = GetProperty("ro.boot.init_rc", ""); // 判断是否存在bootscript
// 如果没有bootscript，则解析init.rc文件
if (bootscript.empty()) { // 8.0引入
parser.ParseConfig("/init.rc"); // 开始实际的解析过程
parser.set_is_system_etc_init_loaded(
parser.ParseConfig("/system/etc/init"));
parser.set_is_vendor_etc_init_loaded(
parser.ParseConfig("/vendor/etc/init"));
parser.set_is_odm_etc_init_loaded(parser.ParseConfig("/odm/etc/init"));
} else {
// 若存在bootscript, 则解析bootscript
parser.ParseConfig(bootscript);
parser.set_is_system_etc_init_loaded(true);
parser.set_is_vendor_etc_init_loaded(true);
parser.set_is_odm_etc_init_loaded(true);
}
... ...
}
如果没有定义bootScript，那么init进程还是会解析init.rc文件。init.rc文件是在init进程启动后执行的启动脚本，文件中记录着init进程需执行的操作。
此处解析函数传入的参数为“/init.rc”，解析的是运行时与init进程同在根目录下的init.rc文件。该文件在编译前，定义于system/core/rootdir/init.rc中。
✨ 继续往下分析main函数之前；
✨ 我们先了解一下init.rc是什么，然后分析下parser解析init.rc过程；
✨ 最后我们再继续跟源码！
init.rc配置文件
init.rc是一个配置文件，内部由Android初始化语言编写（Android Init Language）编写的脚本，主要包含五种类型语句：Action、Command、Service、Option 和 Import，在分析代码的过程中我们会详细介绍。
init.rc的配置代码在：system/core/rootdir/init.rc 中。
init.rc文件是在init进程启动后执行的启动脚本，文件中记录着init进程需执行的操作。
init.rc文件大致分为两大部分：
一部分是以“on”关键字开头的 动作列表（action list）：
on early-init // Action类型语句
# Set init and its forked children's oom_adj. // #：注释符号
write /proc/1/oom_score_adj -1000
... ...
# Shouldn't be necessary, but sdcard won't start without it. http://b/22568628.
mkdir /mnt 0775 root system
... ...
start ueventd
Action类型语句格式：
on <trigger> [&& <trigger>]* // 设置触发器
<command>
<command> // 动作触发之后要执行的命令
另一部分是以“service”关键字开头的 服务列表（service list）： 如 Zygote
service ueventd /sbin/ueventd // Service类型语句
class core
critical
seclabel u:r:ueventd:s0
Service类型语句格式：
service <name> <pathname> [ <argument> ]* // <service的名字><执行程序路径><传递参数>
<option> // option是service的修饰词，影响什么时候、如何启动services
<option>
...
借助系统环境变量或Linux命令，
🏹 动作列表用于创建所需目录，以及为某些特定文件指定权限；
🏹 服务列表用来记录init进程需要启动的一些子进程，如上面代码所示，service关键字后的第一个字符串表示服务（子进程）的名称，第二个字符串表示服务的执行路径。
值得一提的是从Android 7.0后的源码，对init.rc文件进行了拆分，每个服务一个rc文件。我们要分析的zygote服务的启动脚本则在init.zygoteXX.rc中定义。
在init.rc的import段我们看到如下代码：
import /init.${ro.zygote}.rc // 可以看出init.rc不再直接引入一个固定的文件，而是根据属性ro.zygote的内容来引入不同的文件
从android5.0开始，android开始支持64位的编译，zygote本身也就有了32位和64位的区别，所以在这里用ro.zygote属性来控制启动不同版本的zygote进程。
init.rc位于/system/core/rootdir下。在这个路径下还包括四个关于zygote的rc文件。分别是init.zygote32.rc，init.zygote32_64.rc，init.zygote64.rc，init.zygote64_32.rc，由硬件决定调用哪个文件。
这里拿32位处理器为例，init.zygote32.rc的代码如下所示：
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
class main # class是一个option，指定zygote服务的类型为main
priority -20
user root
group root readproc
socket zygote stream 660 root system # socket关键字表示一个option，创建一个名为dev/socket/zygote，类型为stream，权限为660的socket
onrestart write /sys/android_power/request_state wake # onrestart是一个option，说明在zygote重启时需要执行的command
onrestart write /sys/power/state on
onrestart restart audioserver
onrestart restart cameraserver
onrestart restart media
onrestart restart netd
onrestart restart wificond
writepid /dev/cpuset/foreground/tasks
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server 语句解读：
在Init.zygote32.rc中，定义了一个zygote服务：zygote，由关键字service告诉init进程创建一个名为zygote的进程，这个进程要执行的程序是：/system/bin/app_process，给这个进程四个参数：
🏹 -Xzygote：该参数将作为虚拟机启动时所需的参数
🏹 /system/bin：代表虚拟机程序所在目录
🏹 --zygote：指明以ZygoteInit.java类中的main函数作为虚拟机执行入口
🏹 --start-system-server：告诉Zygote进程启动systemServer进程
init.rc解析过程
回顾解析init.rc的代码：
int main(int argc, char** argv) {
... ...
ActionManager& am = ActionManager::GetInstance();
ServiceManager& sm = ServiceManager::GetInstance();
Parser& parser = Parser::GetInstance(); // 构造解析文件用的parser对象
parser.AddSectionParser("service", std::make_unique<ServiceParser>(&sm)); // 增加ServiceParser为一个section，对应name为service
parser.AddSectionParser("on", std::make_unique<ActionParser>(&am)); // 增加ActionParser为一个section，对应name为action
parser.AddSectionParser("import", std::make_unique<ImportParser>(&parser)); // 增加ActionParser为一个section，对应name为import
std::string bootscript = GetProperty("ro.boot.init_rc", "");
if (bootscript.empty()) {
parser.ParseConfig("/init.rc"); // 开始实际的解析过程
parser.set_is_system_etc_init_loaded(
parser.ParseConfig("/system/etc/init"));
parser.set_is_vendor_etc_init_loaded(
parser.ParseConfig("/vendor/etc/init"));
parser.set_is_odm_etc_init_loaded(parser.ParseConfig("/odm/etc/init"));
} else {
parser.ParseConfig(bootscript);
parser.set_is_system_etc_init_loaded(true);
parser.set_is_vendor_etc_init_loaded(true);
parser.set_is_odm_etc_init_loaded(true);
}
... ...
}
Parse
我们发现在解析前，使用了Parser类（在init目录下的 init_parser.h 中定义），构造了parser对象：
Parser& parser = Parser::GetInstance(); // 构造解析文件用的parser对象
初始化ServiceParser用来解析 “service”块，ActionParser用来解析"on"块，ImportParser用来解析“import”块，“import”是用来引入一个init配置文件，来扩展当前配置的。
parser.AddSectionParser("service", std::make_unique<ServiceParser>(&sm)); // 增加ServiceParser为一个section，对应name为service
parser.AddSectionParser("on", std::make_unique<ActionParser>(&am)); // 增加ActionParser为一个section，对应name为action
parser.AddSectionParser("import", std::make_unique<ImportParser>(&parser)); // 增加ActionParser为一个section，对应name为import
/system/core/init/readme.txt中对init文件中的所有关键字做了介绍，主要包含了Actions, Commands, Services, Options, and Imports等，可自行学习解读。
ParseConfig
下面就是分析解析过程了：parser.ParseConfig("/init.rc") （函数定义于 system/core/init/init_parser.cpp 中）
bool Parser::ParseConfig(const std::string& path) {
if (is_dir(path.c_str())) { // 判断传入参数是否为目录地址
return ParseConfigDir(path); // 递归目录，最终还是靠ParseConfigFile来解析实际的文件
}
return ParseConfigFile(path); // 传入参数为文件地址
}
先来看看ParseConfigDir函数：
bool Parser::ParseConfigDir(const std::string& path) {
LOG(INFO) << "Parsing directory " << path << "...";
std::unique_ptr<DIR, int(*)(DIR*)> config_dir(opendir(path.c_str()), closedir);
if (!config_dir) {
PLOG(ERROR) << "Could not import directory '" << path << "'";
return false;
}
// 递归目录，得到需要处理的文件
dirent* current_file;
std::vector<std::string> files;
while ((current_file = readdir(config_dir.get()))) {
// Ignore directories and only process regular files.
if (current_file->d_type == DT_REG) {
std::string current_path =
android::base::StringPrintf("%s/%s", path.c_str(), current_file->d_name);
files.emplace_back(current_path);
}
}
// Sort first so we load files in a consistent order (bug 31996208)
std::sort(files.begin(), files.end());
for (const auto& file : files) {
// 容易看出，最终仍是调用ParseConfigFile
if (!ParseConfigFile(file)) {
LOG(ERROR) << "could not import file '" << file << "'";
}
}
return true;
}
接下来就重点分析ParseConfigFile()：
bool Parser::ParseConfigFile(const std::string& path) {
... ...
android::base::Timer t;
std::string data;
std::string err;
if (!ReadFile(path, &data, &err)) { // 读取路径指定文件中的内容，保存为字符串形式
LOG(ERROR) << err;
return false;
}
... ...
ParseData(path, data); // 解析获取的字符串
... ...
return true;
}
ParseConfigFile只是读取文件的内容并转换为字符串，实际的解析工作被交付给ParseData。
ParseData
ParseData函数定义于system/core/init/init_parser.cpp中，负责根据关键字解析出服务和动作。动作与服务会以链表节点的形式注册到service_list与action_list中，service_list与action_list是init进程中声明的全局结构体。
跟踪ParseData()：
void Parser::ParseData(const std::string& filename, const std::string& data) {
//TODO: Use a parser with const input and remove this copy
// copy一波数据
std::vector<char> data_copy(data.begin(), data.end());
data_copy.push_back('\0');
// 解析用的结构体
parse_state state;
state.line = 0;
state.ptr = &data_copy[0];
state.nexttoken = 0;
SectionParser* section_parser = nullptr;
std::vector<std::string> args;
for (;;) {
switch (next_token(&state)) { // next_token以行为单位分割参数传递过来的字符串，初始没有分割符时，最先走到T_TEXT分支
case T_EOF:
if (section_parser) {
section_parser->EndSection(); // 解析结束
}
return;
case T_NEWLINE:
state.line++;
if (args.empty()) {
break;
}
... ...
// 在前文创建parser时，我们为service，on，import定义了对应的parser
// 这里就是根据第一个参数，判断是否有对应的parser
if (section_parsers_.count(args[0])) {
if (section_parser) {
// 结束上一个parser的工作，将构造出的对象加入到对应的service_list与action_list中
section_parser->EndSection();
}
// 获取参数对应的parser
section_parser = section_parsers_[args[0]].get();
std::string ret_err;
// 调用实际parser的ParseSection函数
if (!section_parser->ParseSection(std::move(args), filename, state.line, &ret_err)) {
LOG(ERROR) << filename << ": " << state.line << ": " << ret_err;
section_parser = nullptr;
}
} else if (section_parser) {
std::string ret_err;
/*
* 如果第一个参数不是service，on，import
* 则调用前一个parser的ParseLineSection函数
* 这里相当于解析一个参数块的子项
*/
if (!section_parser->ParseLineSection(std::move(args), state.line, &ret_err)) {
LOG(ERROR) << filename << ": " << state.line << ": " << ret_err;
}
}
// 清空本次解析的数据
args.clear();
break;
case T_TEXT:
// 将本次解析的内容写入到args中
args.emplace_back(state.text);
break;
}
}
}
上面的代码看起来比较复杂，但实际上就是面向对象，根据不同的关键字，使用不同的parser对象进行解析。
至此，init.rc解析完！Ok，别忘了，main函数还没有分析完，继续往下看。
第四阶段
向执行队列中添加其他action
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建文件系统目录并挂载相关的文件系统 */
/* 03. 重定向输入输出/内核Log系统 */
/* 04. 挂在一些分区设备 */
/* 05. 完成SELinux相关工作 */
/* 06. is_first_stage 收尾 */
/* ------------ 第一阶段 ------------- END ------------ */
/* ------------ 第二阶段 ------------ BEGIN------------ */
/* 01. 初始化属性域 */
/* 02. 清空环境变量 */
/* 03. 完成SELinux相关工作 */
/* 04. 创建epoll句柄 */
/* 05. 装载子进程信号处理器 */
/* 06. 启动属性服务*/
/* 07. 匹配命令和函数之间对应关系 */
/* ------------ 第二阶段 ------------ END ------------ */
/* ------------ 第三阶段 ----------- BEGIN------------ */
/* init解析 */
/* ------------ 第三阶段 ----------- END ------------ */
/* ------------ 第四阶段 ----------- BEGIN------------ */
// 通过am对命令执行顺序进行控制
// ActionManager& am = ActionManager::GetInstance();
// init执行命令触发器主要分为early-init，init，late-init，boot等
am.QueueEventTrigger("early-init"); // 添加触发器early-init，执行on early-init内容
// Queue an action that waits for coldboot done so we know ueventd has set up all of /dev...
am.QueueBuiltinAction(wait_for_coldboot_done_action, "wait_for_coldboot_done");
// ... so that we can start queuing up actions that require stuff from /dev.
am.QueueBuiltinAction(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
am.QueueBuiltinAction(set_mmap_rnd_bits_action, "set_mmap_rnd_bits");
am.QueueBuiltinAction(set_kptr_restrict_action, "set_kptr_restrict");
am.QueueBuiltinAction(keychord_init_action, "keychord_init");
am.QueueBuiltinAction(console_init_action, "console_init");
// Trigger all the boot actions to get us started.
am.QueueEventTrigger("init"); // 添加触发器init，执行on init内容，主要包括创建/挂在一些目录，以及symlink等
// Repeat mix_hwrng_into_linux_rng in case /dev/hw_random or /dev/random
// wasn't ready immediately after wait_for_coldboot_done
am.QueueBuiltinAction(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
// Don't mount filesystems or start core system services in charger mode.
std::string bootmode = GetProperty("ro.bootmode", "");
if (bootmode == "charger") {
am.QueueEventTrigger("charger"); // on charger阶段
} else {
am.QueueEventTrigger("late-init"); // 非充电模式添加触发器last-init
}
// Run all property triggers based on current state of the properties.
am.QueueBuiltinAction(queue_property_triggers_action, "queue_property_triggers");
}
其余工作
继续分析main函数：
int main(int argc, char** argv) {
/* ------------ 第一阶段 ------------ BEGIN------------ */
/* 01. 判断及增加环境变量 */
/* 02. 创建文件系统目录并挂载相关的文件系统 */
/* 03. 重定向输入输出/内核Log系统 */
/* 04. 挂在一些分区设备 */
/* 05. 完成SELinux相关工作 */
/* 06. is_first_stage 收尾 */
/* ------------ 第一阶段 ------------- END ------------ */
/* ------------ 第二阶段 ------------ BEGIN------------ */
/* 01. 初始化属性域 */
/* 02. 清空环境变量 */
/* 03. 完成SELinux相关工作 */
/* 04. 创建epoll句柄 */
/* 05. 装载子进程信号处理器 */
/* 06. 启动属性服务*/
/* 07. 匹配命令和函数之间对应关系 */
/* ------------ 第二阶段 ------------ END ------------ */
/* ------------ 第三阶段 ----------- BEGIN------------ */
/* init解析 */
/* ------------ 第三阶段 ----------- END ------------ */
/* ------------ 第四阶段 ----------- BEGIN------------ */
/* 01. 向执行队列中添加其他action */
/* 02. 其余工作 */
while (true) {
// 判断是否有事件需要处理
// By default, sleep until something happens.
int epoll_timeout_ms = -1;
if (do_shutdown && !shutting_down) {
do_shutdown = false;
if (HandlePowerctlMessage(shutdown_command)) {
shutting_down = true;
}
}
if (!(waiting_for_prop || sm.IsWaitingForExec())) {
am.ExecuteOneCommand(); // 依次执行每个action中携带command对应的执行函数
}
if (!(waiting_for_prop || sm.IsWaitingForExec())) {
if (!shutting_down) restart_processes(); // 重启一些挂掉的进程
// If there's a process that needs restarting, wake up in time for that.
if (process_needs_restart_at != 0) { // 进程重启相关逻辑
epoll_timeout_ms = (process_needs_restart_at - time(nullptr)) * 1000;
if (epoll_timeout_ms < 0) epoll_timeout_ms = 0;
}
// If there's more work to do, wake up again immediately.
if (am.HasMoreCommands()) epoll_timeout_ms = 0; // 有action待处理，不等待
}
epoll_event ev;
// 没有事件到来的话，最多阻塞timeout时间
int nr = TEMP_FAILURE_RETRY(epoll_wait(epoll_fd, &ev, 1, epoll_timeout_ms));
if (nr == -1) {
PLOG(ERROR) << "epoll_wait failed";
} else if (nr == 1) {
//有事件到来，执行对应处理函数
//根据上文知道，epoll句柄（即epoll_fd）主要监听子进程结束，及其它进程设置系统属性的请求
((void (*)()) ev.data.ptr)();
}
}
} // end main
至此，Init.cpp的main函数分析完毕！init进程已经启动完成，一些重要的服务如core服务和main服务也都启动起来，并启动了zygote（/system/bin/app_process64）进程，zygote初始化时会创建虚拟机，启动systemserver等。
参考Blog
01. https://www.cnblogs.com/pepsimaxin/p/6702945.html
02. https://blog.csdn.net/gaugamela/article/details/79280385
03. http://qiangbo.space/2016-10-10/AndroidAnatomy_Process_Creation/
