Android笔记 - Android启动之Android Framework启动
init 进程进入 main 函数后，主要完成以下四项工作。第一，在根文件系统中创建目录作为挂载点，然后挂载虚拟文件系统；第二， 解析启动脚本文件 init.rc；第三，根据启动脚本 init.rc 的解析结果开启 Android Framework 核心服务进程；第四，监听事件，重启服务。
1. 在根文件系统中创建目录，挂载虚拟文件系统
虚拟文件系统不会保存在外部存储设备中，开机时由内核产生。除了 tmpfs 外，这些文件系统用作内核空间和用户空间的访问接口。它们的基本信息如下表所示：
| 文件系统 | 挂载点 | 主要用途 |
|---|---|---|
| tmpfs | /dev | 用于保存临时文件，提高设备访问效率 |
| devpts | /dev/pts | 支持虚拟终端设备 |
| proc | /proc | 访问内核数据结构的接口 |
| sysfs | /sys | 访问系统数据的接口，特点是one-value-per-file |
通过系统调用 mount 挂载虚拟文件系统，代码实现如下所示。
代码路径：system/core/init/init.c
int main(int argc, char **argv)
{
......
mkdir("/dev", 0755);
mkdir("/proc", 0755);
mkdir("/sys", 0755);
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);
......
}2. 解析启动脚本文件 init.rc
init.rc 文件在系统根目录下，包含了 Android Framework 的初始化内容，其内部会 import 其他的初始化文件，比如 init.environ.rc 文件，init.usb.rc 文件，init.{ro.hardware}.rc 文件，以及 init.${ro.zygote}.rc 文件。
init.rc 按照一种特定的语法描述，也就是 Android 初始化语言 (Android Init Language) 来描述。Android 初始化语言的帮助文档位于 system/core/init/readme.txt。
Android 初始化语言有以下六个基本概念。
Action
Action 由关键字 on 来声明。Action 格式如下：
on <trigger>
<command>
<command>
...<trigger> 是触发条件，同时也是 Action 的名字。Action 满足触发条件时就会执行 <command>
Service
Service 由关键字 service 来声明。系统服务进程比如 servicemanager, zygote, uevent, installd 等都是一个 Service。Service 格式如下：
service <name> <pathname> [ <argument> ]*
<option>
<option>
...<name>表示 service 的名字，必须要指定
<pathname>表示 service 的执行路径，必须要指定
<argument>表示传给 service 的参数，可以为0个或多个
<option>表示 service 启动的配置参数
Section
Section 是 init.rc 的基本组成单元。每个Action 或者 Service 都是一个 Section。需要注意的是 Section 的名字不能重复，否则只有第一个 Section 定义有效。
Option
Option 来用修饰 Service，由它来指定何时以及如何启动 Service。比如，critical 表示一个 Service 是系统关键服务，退出后 init 进程会重启服务。如果一分钟内该服务退出四次，就会触发整个系统重启。
Trigger
Trigger 表示一个自定义的触发条件，用来触发 Action 中 Command 的执行。early-init, init, early-fs, fs, post-fs, post-fs-data, charger, early-boot , boot等都是一个 Trigger。
Command
Command 是最小功能单元，表示一个 Linux 命令或者一个方法调用。
解析 init.rc 的工作由函数init_parse_config_file 来完成。具体细节可以参考初始化文件（init.rc）解析 这篇文章。解析完成后，得到一个 service_list 链表和一个 action_list 链表。其中，service_list 链表用来保存 service 的解析结果，action_list 链表用来保存 action 的解析结果。如下图所示：
除了启动脚本文件 init.rc 可以添加 action 到 action_list 链表外，调用 queue_builtin_action 函数也可以添加 action 到 action_list 链表，同时该函数还会调用 action_add_queue_tail 将该 action 添加到 action_queue 链表末尾，以便后面执行 action 中的 command。
代码路径：system/core/init/init_parser.c
void queue_builtin_action(int (*func)(int nargs, char **args), char *name)
{
struct action *act;
struct command *cmd;
act = calloc(1, sizeof(*act));
act->name = name;
list_init(&act->commands);
list_init(&act->qlist);
cmd = calloc(1, sizeof(*cmd));
cmd->func = func;
cmd->args[0] = name;
list_add_tail(&act->commands, &cmd->clist);
list_add_tail(&action_list, &act->alist);
action_add_queue_tail(act);
} 为了让 action 按照一定的顺序触发，使用 action_for_each_trigger 函数来根据 trigger 的内容（early-init -> init -> early-fs -> fs -> post-fs -> post-fs-data -> charger -> early-boot -> boot）对 action 在链表中的顺序进行调整。调整后的 action 由 action_queue 链表来保存。过程如下所示：
代码路径：system/core/init/init.c
int main(int argc, char **argv)
{
......
action_for_each_trigger("early-init", action_add_queue_tail);
queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done");
queue_builtin_action(keychord_init_action, "keychord_init");
queue_builtin_action(console_init_action, "console_init");
/* execute all the boot actions to get us started */
action_for_each_trigger("init", action_add_queue_tail);
/* skip mounting filesystems in charger mode */
if (!is_charger) {
action_for_each_trigger("early-fs", action_add_queue_tail);
action_for_each_trigger("fs", action_add_queue_tail);
action_for_each_trigger("post-fs", action_add_queue_tail);
action_for_each_trigger("post-fs-data", action_add_queue_tail);
}
queue_builtin_action(property_service_init_action, "property_service_init");
queue_builtin_action(signal_init_action, "signal_init");
queue_builtin_action(check_startup_action, "check_startup");
if (is_charger) {
action_for_each_trigger("charger", action_add_queue_tail);
} else {
action_for_each_trigger("early-boot", action_add_queue_tail);
action_for_each_trigger("boot", 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");
......
}3. 根据启动脚本 init.rc 的解析结果开启核心服务进程
通过之前的初始化工作得到 action_queue 链表后，调用 execute_one_command 函数遍历 action_queue 链表，并执行链表中 action 的 command，实际上是调用 command 中 func 函数指针指向的处理函数。
代码路径：system/core/init/init.h
struct command
{
/* list of commands in an action */
struct listnode clist;
int (*func)(int nargs, char **args);
int nargs;
char *args[1];
};
下面以 boot action (boot 既是 action 的触发条件，又可以作为 action 的名称) 为例，梳理 zygote 服务进程的启动流程，其他核心服务进程的启动过程也类似。
在这些启动的核心服务进程中，其中两个最重要的核心服务进程是 zygote 进程和 servicemanager 进程。
zygote 进程是 Android 启动后的第一个虚拟机进程。它主要负责启动 system_server 进程，以及所有的应用程序进程，所以也称为孵化器进程。zygote 进程会启动子进程 system_server，system_server 进程在 nativeInit 函数中启动 Native 系统服务比如 SensorService，在 ServerThread 的 initAndLoop 函数中启动 Java 系统服务比如 ActivityManagerService, PackageManagerService, ContentService 等，并将系统服务注册进 ServiceManager。
servicemanager 进程是 Binder 进程间通信机制的核心之一。它负责管理系统中所有的 Service 组件，提供 Service 组件的注册服务，并且向 Client 组件提供获取 Service 代理对象的服务。
以下是 boot action 在 init.rc 文件中的内容：
on boot
......
class_start core
class_start main在调用 init_parse_config_file 函数完成解析后，action_queue 链表中名字为 boot 的 action 包含两个 command，这两个 command 的 func 都赋值为 do_class_start，只是一个 command 的参数为 core；另一个 command 的参数为 main。当 execute_one_command 遍历到 boot 这个 action 时，依次执行这两个 command，即调用 do_class_start 函数。
代码路径：system/core/init/builtins.c
int do_class_start(int nargs, char **args)
{
/* Starting a class does not start services * which are explicitly disabled. They must * be started individually. */
service_for_each_class(args[1], service_start_if_not_disabled);
return 0;
}do_class_start 内部调用service_for_each_class 函数遍历前面解析得到的 service_list，如果发现某个 service 的 classname 与参数 args[1] 相同，则调用 service_start_if_not_disabled 函数启动该 service。
代码路径：system/core/init/builtins.c
static void service_start_if_not_disabled(struct service *svc)
{
if (!(svc->flags & SVC_DISABLED)) {
service_start(svc, NULL);
}
}zygote 在 init.rc 中的内容如下，由于 classname 为 main，和上述第二个 command 的参数相同，而且 flags 不为 SVC_DISABLED，因此系统开始调用 service_start 函数来启动 zygote。
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
class main
socket zygote stream 660 root system
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
onrestart restart media
onrestart restart netd根据 Android 初始化语言的语法，可以知道 zygote 服务进程的名字是 zygote ，执行程序路径为
/system/bin/app_process，参数为-Xzygote /system/bin --zygote --start-system-server。创建一个名字为 zygote 的 socket，这个 socket 用于接收 ActivityManagerService 发送过来的新建应用程序进程的请求。zygote 进程重启时会往 sysfs 中写入命令，同时会重启 media 服务和 netd 服务。
service_start 函数首先使用 fork 函数克隆出一个子进程。然后在子进程中创建 socket ，并在环境变量中设置创建的 socket 信息。最后调用系统函数 execve 开始执行 /system/bin/app_process 程序。
代码路径：system/core/init/init.c
void service_start(struct service *svc, const char *dynamic_args)
{
struct stat s;
pid_t pid;
int needs_console;
int n;
char *scon = NULL;
int rc;
/* starting a service removes it from the disabled or reset * state and immediately takes it out of the restarting * state if it was in there */
svc->flags &= (~(SVC_DISABLED|SVC_RESTARTING|SVC_RESET|SVC_RESTART));
svc->time_started = 0;
/* running processes require no additional work -- if * they're in the process of exiting, we've ensured * that they will immediately restart on exit, unless * they are ONESHOT */
if (svc->flags & SVC_RUNNING) {
return;
}
......
pid = fork();
if (pid == 0) {
......
for (si = svc->sockets; si; si = si->next) {
int socket_type = (
!strcmp(si->type, "stream") ? SOCK_STREAM :
(!strcmp(si->type, "dgram") ? SOCK_DGRAM : SOCK_SEQPACKET));
int s = create_socket(si->name, socket_type,
si->perm, si->uid, si->gid);
if (s >= 0) {
publish_socket(si->name, s);
}
}
......
if (!dynamic_args) {
if (execve(svc->args[0], (char**) svc->args, (char**) ENV) < 0) { ERROR("cannot execve('%s'): %s\n", svc->args[0], strerror(errno)); } } ...... } ...... }/system/bin/app_process 是 zygote 进程的可执行程序，其源代码位于 frameworks/base/cmds/app_process/app_main.cpp 文件，入口函数是 main。具体启动细节请参考老罗的文章 Android 系统进程 Zygote 启动过程的源代码分析。
4. 监听事件，重启服务
init 进程最终会进入一个无限循环。在这个无限循环中，init 进程调用系统函数 poll 监听三类事件。分别调用 get_property_set_fd 得到文件描述符 property_fd，调用 get_signal_fd 得到文件描述符 signal_fd ，get_keychord_fd 得到文件描述符 keychord_fd。这三个文件描述符的初始化过程之前通过 queue_builtin_action 添加进 action_queue，然后被触发执行。
queue_builtin_action(keychord_init_action, "keychord_init");
queue_builtin_action(property_service_init_action, "property_service_init");
queue_builtin_action(signal_init_action, "signal_init"); 其中，property_fd 用于监听属性设置操作，signal_fd 用于获取子进程退出信号，keychord_fd 用于监听外设的组合按键。代码如下：
代码路径：system/core/init/init.c
int main(int argc, char **argv)
{
......
for(;;) {
int nr, i, timeout = -1;
execute_one_command();
restart_processes();
if (!property_set_fd_init && get_property_set_fd() > 0) {
ufds[fd_count].fd = get_property_set_fd();
ufds[fd_count].events = POLLIN;
ufds[fd_count].revents = 0;
fd_count++;
property_set_fd_init = 1;
}
if (!signal_fd_init && get_signal_fd() > 0) {
ufds[fd_count].fd = get_signal_fd();
ufds[fd_count].events = POLLIN;
ufds[fd_count].revents = 0;
fd_count++;
signal_fd_init = 1;
}
if (!keychord_fd_init && get_keychord_fd() > 0) {
ufds[fd_count].fd = get_keychord_fd();
ufds[fd_count].events = POLLIN;
ufds[fd_count].revents = 0;
fd_count++;
keychord_fd_init = 1;
}
......
nr = poll(ufds, fd_count, timeout);
if (nr <= 0)
continue;
for (i = 0; i < fd_count; i++) {
if (ufds[i].revents == POLLIN) {
if (ufds[i].fd == get_property_set_fd())
handle_property_set_fd();
else if (ufds[i].fd == get_keychord_fd())
handle_keychord();
else if (ufds[i].fd == get_signal_fd())
handle_signal();
}
}
}
return 0;
}当监听到 property_fd 上发生了可读事件时，调用 handle_property_set_fd 函数处理事件。首先通过 socket 接收到客户端传过来的消息，然后根据消息类型设置属性或者启动相应的服务。
当监听到 signal_fd 上发生了可读事件时，调用 handle_signal 函数处理事件。通过 waitpid 得到子进程的 pid，对子进程做一些清理工作。然后根据子进程的启动配置参数判断是否需要重新，如果需要则设置其属性为 SVC_RESTARTING，最后在 restart_processes 中完成重启，过程如下所示：
代码路径：system/core/init/init.c
static void restart_processes()
{
process_needs_restart = 0;
service_for_each_flags(SVC_RESTARTING,
restart_service_if_needed);
}
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;
}
}当监听到 keychord_fd 上发生了可读事件时，调用 handle_keychord 函数处理事件。通过系统调用 read 从 keychord_fd 上读取 id，再根据 id 启动相应的 keychord 服务。
至此，Android 启动流程第二阶段完成，下文开始分析应用程序 Launcher 的启动过程。
参考学习资料
1. Understanding The Linux Kernel(Third Edition)