Android笔记 - Android启动之Android Framework启动

Posted 2022-12-06 demonyan

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)