Android 启动过程的底层实现

Android 启动过程的底层实现

大家好,又见面了,我是全栈君。


3.1 android正常模式启动流程
主要流程例如以下:
1.系统加电。运行bootloader,bootloader会将内核载入到内存中。

2.内核载入到内存之后首先进入内核引导阶段,最后调用start_kernel进入内核启动。start_kernel终于会启动init程序
3.init程序负责解析init.rc文件并开启守护进程。最重要的两个守护进程就是zygoteServiceManager
4.zygote启动子进程system_server,在system_server中开启android核心服务并加入到SystemManager之中,系统进入systemReady状态。
5.在systemReady状态下AMS和zygote的socket通信,启动Home应用进入系统桌面。

这里仅仅介绍步骤2和步骤3。
直接看init程序是怎样启动的

3.2 init进程运行过程
init是linux用户空间的第一个进程,它的进程号是1。工作主要有下面几个部分:
1.初始化文件系统和日志系统,主要是linux标准函数调用
2.解析init.rc和init<hardware>.rc初始化文件,当中init.rc文件的解析很重要
3.解析上面的文件之后运行Action和Service
4.循环监听处理事件

init进程相应的代码是在system\core\init\Init.c,看它的入口函数main:
int main(int argc, char **argv){    int fd_count = 0;    struct pollfd ufds[4];    char *tmpdev;    char* debuggable;    char tmp[32];    int property_set_fd_init = 0;    int signal_fd_init = 0;    int keychord_fd_init = 0;    //假设传入的argv[0]參数是ueventd,运行ueventd_main函数    if (!strcmp(basename(argv[0]), "ueventd"))        return ueventd_main(argc, argv);    /* clear the umask */    //假设是文件。文件权限为666,文件夹权限是777      umask(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.         */   //创建文件夹并挂载    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);        /* indicate that booting is in progress to background fw loaders, etc */    close(open("/dev/.booting", O_WRONLY | O_CREAT, 0000));        /* 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();    //初始化日志系统    klog_init();         //解析init.rc配置文件(这个是重点分析的)    INFO("reading config file\n");    init_parse_config_file("/init.rc");    /* pull the kernel commandline and ramdisk properties file in */    import_kernel_cmdline(0, import_kernel_nv);    /* don't expose the raw commandline to nonpriv processes */    chmod("/proc/cmdline", 0440);    //读取/proc/cpuinfo得到机器hardware名称    get_hardware_name(hardware, &revision);    snprintf(tmp, sizeof(tmp), "/init.%s.rc", hardware);    //解析tmp 文件,也就是/init.<hardware>.rc文件     init_parse_config_file(tmp);        //解析完上面两个rc文件之后得到非常多Action。    //这里运行名称为early-init的Action    action_for_each_trigger("early-init", action_add_queue_tail);    //触发内置的Action。第一个參数是函数指针,第二个參数是action的名称    queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done");    queue_builtin_action(property_init_action, "property_init");    queue_builtin_action(keychord_init_action, "keychord_init");    queue_builtin_action(console_init_action, "console_init");    queue_builtin_action(set_init_properties_action, "set_init_properties");    // 运行名称为init的action    /* execute all the boot actions to get us started */    action_for_each_trigger("init", action_add_queue_tail);    /* skip mounting filesystems in charger mode */    //假设正在充电则运行以下的action    if (strcmp(bootmode, "charger") != 0) {        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);    }    //触发内置Action    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 (!strcmp(bootmode, "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_propety_triggers");#if BOOTCHART    queue_builtin_action(bootchart_init_action, "bootchart_init");#endif//运行完上面初始化和触发action的过程之后进入一个死循环,运行Command    for(;;) {        int nr, i, timeout = -1;               execute_one_command();       //假设service异常退出,重新启动它           restart_processes();       //监听来自property service事件,后面会介绍        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;        }        //监听来自signal事件 。signal是用来处理子进程退出时的操作,防止子进程编程僵尸进程        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;        }       //监听来自keychord设备事件          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;        }         //假设异常终止的service重新启动,设置等待时间        if (process_needs_restart) {            timeout = (process_needs_restart - gettime()) * 1000;            if (timeout < 0)                timeout = 0;        }        if (!action_queue_empty() || cur_action)            timeout = 0;#if BOOTCHART        if (bootchart_count > 0) {            if (timeout < 0 || timeout > BOOTCHART_POLLING_MS)                timeout = BOOTCHART_POLLING_MS;            if (bootchart_step() < 0 || --bootchart_count == 0) {                bootchart_finish();                bootchart_count = 0;            }        }#endif        //多路监听设备        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();//处理property service事件                else if (ufds[i].fd == get_keychord_fd())                    handle_keychord();//处理keychord事件                 else if (ufds[i].fd == get_signal_fd())                    handle_signal();//处理signal事件              }        }    }    return 0;}
init要做的工作还是非常多的。

第一阶段是初始化文件系统。不作讨论。

从第二部分開始分析


3.3 init.rc文件解析
先来看一些init.rc文件,它在system\core\rootdir\init.rc
#on用来声明这是一个Action。early-init是该Action的触发条件,也是它的名称
on early-init
    #运行命令 
    start ueventd
# create mountpoints
      #运行命令 
    mkdir /mnt 0775 root system

 //省略。

。。

#service声明是这是一个Service,servicemanager 是Service名称,/system/bin/servicemanager是程序地址service servicemanager /system/bin/servicemanager#class、user等都是option class core user system group system critical onrestart restart zygote onrestart restart mediaservice zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server class main socket zygote stream 666 onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart restart media onrestart restart netd //....

能够看出init.rc有自己的文件格式,该格式是由android init language定义的。简要说明一下:
3.3.1 android init language(android 初始化语言)
一共同拥有四种类型Action、Service、Command、Options
两个基本keywordon和service
辅助指令的keywordTrigger
使用on来声明一个Action,使用service声明一个Service
一个Action或者一个Service是Section,init.rc就是由一个一个的Section组成
Command是最小的功能单位。代表一个linux命令或者一个方法调用
Trigger是触发条件,假设满足这个条件就运行Action,也是Action的名称
Option用来修饰Service。描写叙述Service的一些信息

分别来介绍
1.Action
Action就是一组被命名的Command运行序列。在满足触发器条件时就会将该action放到一个队里中。以下会介绍。
格式例如以下:
on <trigger>
     <command>
     <command>
     <command>
      …..
2.Trigger
触发器,用来推断特定类型条件的发生,用在Action之中
常见的trigger
1.boot:  /init.conf载入后第一个被触发的trigger。
2.property:<property name>=<property value>:当name的值为value时触发。

on property:ro.debuggable=1
start console
3.device-added-<path>: 设备加入时触发
4.device-removed-<path>:设备移除时触发
5.service-exited-<name>:服务退出时触发

3.command
命令,能够是linux命令或者函数调用
常见的command:
    exec <path> [ <argument> ]*  执行路径为path的命令,參数是argument
    export <name> <value>    在全局环境变量中设在环境变量 <name>为<value>。
    ifup <interface>      启动网络接口<interface>
    import <filename>     解析一个init配置文件,扩展当前配置。
    hostname <name>      设置主机名。
    chmod <octal-mode> <path>     更改文件訪问权限。
    chown <owner> <group> <path>    更改文件的全部者和组。
    class_start <serviceclass>   启动全部指定服务类下的未执行服务。

class_stop <serviceclass> 停止指定服务类下的全部已执行的服务。 domainname <name> 设置域名。 insmod <path> 载入<path>中的模块。

mkdir <path> [mode] [owner] [group] 创建一个文件夹<path>, mount <type> <device> <dir> [ <mountoption> ]* 试图在文件夹<dir>挂载指定的设备 setprop <name> <value> 设置系统属性 <name> 为 <value>值. setrlimit <resource> <cur> <max> 设置<resource>的rlimit(资源限制)。 start <service> 启动指定服务(假设此服务还未执行)。 stop <service> 停止指定服务(假设此服务在执行中)。 symlink <target> <path> 创建一个指向<path>的软连接<target>。 sysclktz <mins_west_of_gmt> 设置系统时钟基准(0代表时钟滴答以格林威治平均时(GMT)为准) trigger <event> 触发一个事件。 write <path> <string> [ <string> ]* 打开路径为<path>的一个文件,并写入一个或多个字符串。


4.Service
就是init进程启动或者又一次启动的程序,格式:
service<name><path>[<argument>]*
<option>
<option>
<option>
<option>
当中name是服务名称,path是程序路径,argument是參数。option是服务设置选项
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
    class main
    socket zygote stream 666
    onrestart write /sys/android_power/request_state wake
    onrestart write /sys/power/state on
    onrestart restart media
    onrestart restart netd

zygote是服务名称, /system/bin/app_process是程序路径, -Xzygote /system/bin –zygote –start-system-server是參数
以下的class。onrestart都是option

5.option
用来辅助设置service选项
常见的:
     critical: 说明这是一个对于设备关键的服务。假设一定时间退出多次,系统将会重新启动并进入recovery(恢复)模式。

disabled:说明这个服务禁用,不会自己主动启动此服务。可是能够手动启动。 setenv <name> <value> :环境变量设置 在进程启动时将环境变量<name>设置为<value>。

socket <name> <type> <perm> [ <user> [ <group> ] ] 创建一个Uinx域的名为/dev/socket/<name> 的套接字,并传递它的文件描写叙述符给已启动的进程。<type> 必须是 "dgram"或"stream"。User 和 group默觉得0。

user <username> 在启动这个服务前改变切换到用户username,此时默觉得root。

group <groupname> [ <groupname> ]* 在启动这个服务前改变切换到用户组username,此时默觉得root。 oneshot:仅仅启动一次。一旦关闭就不再重新启动 class <name> 指定一个服务类别。全部同一类的服务能够同一时候启动和停止。默觉得"default"类服务。 onrestart <Command> 当服务重新启动,运行一个命令

3.3.2 解析配置文件函数
init.c中的main函数中已经指明解析配置文件的函数是init_parse_config_file函数,该函数在system\core\init\init.parser.c文件里
int init_parse_config_file(const char *fn)
{
    char *data;
     //读取配置文件
    data = read_file(fn, 0);
    if (!data) return -1;
     //重点是这个函数。解析配置文件
    parse_config(fn, data);
    DUMP();
    return 0;
}
接着看parse_config函数
static void parse_config(const char *fn, char *s)
{
    struct parse_state state;//保存解析状态
    char *args[INIT_PARSER_MAXARGS];//存储參数
    int nargs;//參数个数

    nargs = 0;
    state.filename = fn;//解析得文件路径
    state.line = 0;//当前解析的行号
    state.ptr = s;//当前解析的内容
    state.nexttoken = 0;//当前解析是那种类型的行。有文件结束T_EOF,新的一行T_NEWLINE,參数T_TEXT
    state.parse_line = parse_line_no_op;//parse_line_no_op是空操作
    for (;;) {
        switch (next_token(&state)) {
        case T_EOF://文件结束
            state.parse_line(&state, 0, 0);
            return;
        case T_NEWLINE://新的一行
            state.line++;
            if (nargs) {
                int kw = lookup_keyword(args[0]);//是哪一个keyword
                if (kw_is(kw, SECTION)) {//假设该keyword是section 
                    state.parse_line(&state, 0, 0);
                    parse_new_section(&state, kw, nargs, args);//在这里才真正開始開始解析Section
                } else {
                    state.parse_line(&state, nargs, args);
                }
                nargs = 0;
            }
            break;
        case T_TEXT:
            if (nargs < INIT_PARSER_MAXARGS) {
                args[nargs++] = state.text;
            }
            break;
        }
    }
}
关键函数是parse_new_section
void parse_new_section(struct parse_state *state, int kw,int nargs, char **args)
{
    printf("[ %s %s ]\n", args[0],nargs > 1 ? args[1] : "");
    switch(kw) {
    case K_service://假设是Service的Section,開始解析Service
        state->context = parse_service(state, nargs, args);//保存调用过parse_service的service 
        if (state->context) {
            state->parse_line = parse_line_service;//parse_line_service 才是真正的解析并填充Service函数
            return;
        }
        break;
    case K_on://假设是Action的Section。開始解析Action 
        state->context = parse_action(state, nargs, args);//保存调用过parse_action的action
        if (state->context) {
            state->parse_line = parse_line_action;//parse_line_action才是真正的解析并填充Action函数 
            return;
        }
        break;
    case K_import:
        if (nargs != 2) {
            ERROR("single argument needed for import\n");
        } else {
            int ret = init_parse_config_file(args[1]);
            if (ret)
                ERROR("could not import file %s\n", args[1]);
        }
    }
    state->parse_line = parse_line_no_op;
}
解析Service调用了parse_service和parse_line_service
解析Action调用了parse_action和parse_line_action

3.3.3 解析Service
1.parse_service
先介绍几个概念:service结构体、service_list变量、list_init函数、list_add_tail函数
service结构体用来保存和service相关信息。定义在/system/core/init/init.h文件里
struct service {
        /* list of all services */
//用于将结构体连接成一个双向链表。init中有一个全局变量service_list,专门保存解析后的service
   struct listnode slist;//用于将结构体连接成一个双向链表,init中有一个全局变量

    const char *name;//名称
    const char *classname;//classname,默认是default
    unsigned flags;//属性标志
    pid_t pid;//进程号
    time_t time_started;    /* time of last start 上次启动时间   */
    time_t time_crashed;    /* first crash within inspection window 上次异常退出时间 */
    int nr_crashed;         /* number of times crashed within window  异常退出次数*/
    
    uid_t uid;//用户id
    gid_t gid;//用户组id
    gid_t supp_gids[NR_SVC_SUPP_GIDS];
    size_t nr_supp_gids;
    //service使用的socket
    struct socketinfo *sockets;
    //service环境变量
    struct svcenvinfo *envvars;
    //service中的onrestart是一个option,可是它后面是一系列的command,能够看做是一个action
    struct action onrestart;  /* Actions to execute on restart. */
    
    /* keycodes for triggering this service via /dev/keychord */
     //和keychord有关的
    int *keycodes;
    int nkeycodes;
    int keychord_id;
     //io优先级
    int ioprio_class;
    int ioprio_pri;
    //參数个数
    int nargs;
    /* "MUST BE AT THE END OF THE STRUCT" */
    //參数列表
    char *args[1];
}
2.service_list成员变量:init进程中的一个双向链表,专门保存解析后的service,它的类型是listnode类型:
struct listnode
{
     struct listnode * next;
     struct listnode * prev;
 };
存放链表的前后指针。将链表中的指针部分和数据部分分离,使得这个结构和数据类型无关。避免了不同数据类型定义大量反复的链表操作。

3.list_init函数在system/core/libcutils/list.c中
void list_init(struct listnode *node)
{
    node->next = node;
    node->prev = node;
}

4.list_add_tail函数在system/core/libcutils/list.c中

void list_add_tail(struct listnode *head, struct listnode *item)
{
    item->next = head;
    item->prev = head->prev;
    head->prev->next = item;
    head->prev = item;
}

将item将增加到head链表的尾部

再来看parse_service函数:
static void *parse_service(struct parse_state *state, int nargs, char **args)
{
    struct service *svc;//定义的service结构体,用来保存解析出来的service
     //异常处理代码
    if (nargs < 3) {
        parse_error(state, "services must have a name and a program\n");
        return 0;
    }
    if (!valid_name(args[1])) {
        parse_error(state, "invalid service name '%s'\n", args[1]);
        return 0;
    }

    svc = service_find_by_name(args[1]);
    if (svc) {
        parse_error(state, "ignored duplicate definition of service '%s'\n", args[1]);
        return 0;
    }

    nargs -= 2;
    svc = calloc(1, sizeof(*svc) + sizeof(char*) * nargs);//为Service分配内存空间
    if (!svc) {
        parse_error(state, "out of memory\n");
        return 0;
    }
    为svc结构体填充数据赋值
    svc->name = args[1];
    svc->classname = "default";//默觉得default类比
    memcpy(svc->args, args + 2, sizeof(char*) * nargs);
    svc->args[nargs] = 0;
    svc->nargs = nargs;
    svc->onrestart.name = "onrestart";
    //Service中的onrestart 是Action类型的链表。初始化该链表
    list_init(&svc->onrestart.commands);
    //将service中的slist增加到service_list 中
    list_add_tail(&service_list, &svc->slist);
    return svc;
}
parse_service只填充了service的一小部分内容,当中大部分内容须要
parse_line_service完毕
2.parse_line_service
static void parse_line_service(struct parse_state *state, int nargs, char **args)
{
    struct service *svc = state->context;//取出刚才创建的service
    struct command *cmd;
    int i, kw, kw_nargs;

    if (nargs == 0) {
        return;
    }

    svc->ioprio_class = IoSchedClass_NONE;//设置IO优先级

    kw = lookup_keyword(args[0]);//配置service中的option关键字
    switch (kw) {
     //......  
    case K_onrestart://处理onrestart选项
        nargs--;
        args++;
        kw = lookup_keyword(args[0]);
        if (!kw_is(kw, COMMAND)) {//假设onrestart 选项后面不是command 提示错误
            parse_error(state, "invalid command '%s'\n", args[0]);
            break;
        }
        kw_nargs = kw_nargs(kw);
        if (nargs < kw_nargs) {
            parse_error(state, "%s requires %d %s\n", args[0], kw_nargs - 1,
                kw_nargs > 2 ? "arguments" : "argument");
            break;
        }
        //service中onrestart  option的command序列创建过程
        cmd = malloc(sizeof(*cmd) + sizeof(char*) * nargs);
        cmd->func = kw_func(kw);
        cmd->nargs = nargs;
        memcpy(cmd->args, args, sizeof(char*) * nargs);
        list_add_tail(&svc->onrestart.commands, &cmd->clist);
        break;
    case K_critical:
        svc->flags |= SVC_CRITICAL;
        break;
    case K_setenv: { /* name value */
        struct svcenvinfo *ei;
        if (nargs < 2) {
            parse_error(state, "setenv option requires name and value arguments\n");
            break;
        }
        ei = calloc(1, sizeof(*ei));
        if (!ei) {
            parse_error(state, "out of memory\n");
            break;
        }
        ei->name = args[1];
        ei->value = args[2];
        ei->next = svc->envvars;
        svc->envvars = ei;
        break;
    }

    //假设须要创建socket
    case K_socket: {/* name type perm [ uid gid ] */
        struct socketinfo *si;
        if (nargs < 4) {
            parse_error(state, "socket option requires name, type, perm arguments\n");
            break;
        }
        if (strcmp(args[2],"dgram") && strcmp(args[2],"stream")
                && strcmp(args[2],"seqpacket")) {
            parse_error(state, "socket type must be 'dgram', 'stream' or 'seqpacket'\n");
            break;
        }
        si = calloc(1, sizeof(*si));
        if (!si) {
            parse_error(state, "out of memory\n");
            break;
        }
        si->name = args[1];
        si->type = args[2];
        si->perm = strtoul(args[3], 0, 8);
        if (nargs > 4)
            si->uid = decode_uid(args[4]);
        if (nargs > 5)
            si->gid = decode_uid(args[5]);
        si->next = svc->sockets;
        svc->sockets = si;
        break;
    }
    ...
    default:
        parse_error(state, "invalid option '%s'\n", args[0]);
    }
}

3.3.3 解析Action
解析Action调用了parse_actionparse_line_action两个函数
先看一下Action的结构,它定义在sytem/core/init/init.h文件里:    
struct action {
        /* node in list of all actions */
    struct listnode alist;//用来存储全部的Action指针
        /* node in the queue of pending actions */
    struct listnode qlist;//用来存储即将运行的Action指针
        /* node in list of actions for a trigger */
    struct listnode tlist;//用来存储等待触发的Action节点

    unsigned hash;
    const char *name;//Action的名称
   
    struct listnode commands;//Action中的command命令 
    struct command *current;
};

Action中能够有多个Command,所以用listnode来存储command。

command结构。它定义在sytem/core/init/init.h文件里:    
struct command{        /* list of commands in an action */    struct listnode clist;//一个Action中的command队列    int (*func)(int nargs, char **args);//command相应的函数指针    int nargs;//函数參数个数    char *args[1];//函数參数};

看完这些数据结构再看parse_actionparse_line_action两个函数
1.parse_action
static void *parse_action(struct parse_state *state, int nargs, char **args)
{
    struct action *act;
    if (nargs < 2) {
        parse_error(state, "actions must have a trigger\n");
        return 0;
    }
    if (nargs > 2) {
        parse_error(state, "actions may not have extra parameters\n");
        return 0;
    }
    act = calloc(1, sizeof(*act));//为action结构体分配内存
    act->name = args[1];//填充action的名称
    list_init(&act->commands);//初始化action中的command指针队列
    list_add_tail(&action_list, &act->alist);//将Action指针存放在action_list队列中
        /* XXX add to hash */
    return act;
}
和service中的parse_service操作类似:分配内存,填出一部分数据,大部分数据还是在parse_line_action函数中运行
2.parse_line_action
static void parse_line_action(struct parse_state* state, int nargs, char **args)
{
    struct command *cmd;
    struct action *act = state->context;//action的引用
    int (*func)(int nargs, char **args);
    int kw, n;

    if (nargs == 0) {
        return;
    }

    kw = lookup_keyword(args[0]);
    if (!kw_is(kw, COMMAND)) {//匹配是否是Command,假设不是。提示错误
        parse_error(state, "invalid command '%s'\n", args[0]);
        return;
    }

    n = kw_nargs(kw);
    if (nargs < n) {
        parse_error(state, "%s requires %d %s\n", args[0], n - 1,
            n > 2 ? "arguments" : "argument");
        return;
    }
    cmd = malloc(sizeof(*cmd) + sizeof(char*) * nargs);//为Command分配内存
    cmd->func = kw_func(kw);//获取command相应的函数指针
    cmd->nargs = nargs;
    memcpy(cmd->args, args, sizeof(char*) * nargs);
    list_add_tail(&act->commands, &cmd->clist);//command增加到action的command列表
}

由于action中的数据结构少,复杂一点的就是使用listnode来存放command,所以parse_line_action的操作比起parse_line_service要简单一些。

3.4触发以及启动Action和Service
上面都是Action和Service的解析。启动Action和Service。

以下看一下启动的流程

分成两个阶段,一个是触发。一个是真正启动
3.4.1 触发Action
init函数在解析完init.rc文件之后运行了action_for_each_trigger和queue_builtin_action两个函数。
 
//这里触发名称为early-init的Action    action_for_each_trigger("early-init", action_add_queue_tail);    //触发内置的Action。第一个參数是函数指针。第二个參数是action的名称    queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done");    queue_builtin_action(property_init_action, "property_init");    queue_builtin_action(keychord_init_action, "keychord_init");    queue_builtin_action(console_init_action, "console_init");    queue_builtin_action(set_init_properties_action, "set_init_properties");

先看action_for_each_trigger,在system/core/init/init_parser.c
void action_for_each_trigger(const char *trigger,void (*func)(struct action *act))
{
    struct listnode *node;
    struct action *act;
    list_for_each(node, &action_list) {//实际就是遍历action_list
        act = node_to_item(node, struct action, alist);
        if (!strcmp(act->name, trigger)) {
            func(act);
        }
    }
}

当中list_for_each:
#define list_for_each(node, list) \
    for (node = (list)->next; node != (list); node = node->next)

就是遍历list链表
node_to_item就是在member中查找node的偏移量
#define node_to_item(node, container, member) \
    (container *) (((char*) (node)) - offsetof(container, member))

以代码action_for_each_trigger(“early-init”, action_add_queue_tail);为例
上面的代码找到action_list中trigger名称为”early-init”的action act ,并调用action_add_queue_tail(act)。再看看action_add_queue_tail函数,该函数还是在system/core/init/init_parser.c文件里
void action_add_queue_tail(struct action *act)
{   //将action中的qlist增加到action_queue中,当中qlist是中即将运行的action 。
    list_add_tail(&action_queue, &act->qlist);
}

能够看出,仅仅是将action增加到一个action_queue
中。并没有启动action的操作。

再看 queue_builtin_action(wait_for_coldboot_done_action, “wait_for_coldboot_done”);
void queue_builtin_action(int (*func)(int nargs, char **args), char *name)
{
    struct action *act;
    struct command *cmd;

    act = calloc(1, sizeof(*act));//action分配内存
    act->name = name;//设置action名称
    list_init(&act->commands);//初始化action的command链表

    cmd = calloc(1, sizeof(*cmd));//为链表分配内存
    cmd->func = func;//填充函数运行
    cmd->args[0] = name;//填充函数名称
    list_add_tail(&act->commands, &cmd->clist);//将command的clist增加到action的command链表中

    list_add_tail(&action_list, &act->alist);//将action的alist增加到action_list 链表中
    action_add_queue_tail(act);也是调用action_add_queue_tail。将创建的action增加到action_queue 链表中
}
能够看出queue_builtin_action就是创建一个action,填充该action的name和command数据。然后将该action增加到action_queue 链表中
action_for_each_trigger和queue_builtin_action两个函数的调用并没有运行Action,那么在哪里调用的呢,接着看:
  for(;;) {
        ....      
        execute_one_command();//就是这里启动了解析的action
       //假设service异常退出。重新启动它   
        restart_processes();
     ...
}


3.4.2 运行action
就是调用execute_one_command函数来启动Action,此函数在system/core/init/init.c文件里
void execute_one_command(void)
{
    int ret;
     //取出action中的command,运行action就是运行command
    if (!cur_action || !cur_command || is_last_command(cur_action, cur_command)) {
        cur_action = action_remove_queue_head();
        cur_command = NULL;
        if (!cur_action)
            return;
        INFO("processing action %p (%s)\n", cur_action, cur_action->name);
        cur_command = get_first_command(cur_action);
    } else {
        cur_command = get_next_command(cur_action, cur_command);
    }

    if (!cur_command)
        return;
     //调用command中的func函数
    ret = cur_command->func(cur_command->nargs, cur_command->args);
    INFO("command '%s' r=%d\n", cur_command->args[0], ret);
}

execute_one_command做了两个工作:取出action中的command。并运行该command相应的func函数。

当中command的func变量在parse_line_action函数赋值,command命令和相应的函数的相应关系在Keywords.h文件里


以early-init action为例:
on early-init      write /proc/1/oom_adj -16     start ueventd
write /proc/1/oom_adj -16,start ueventd都是命令,当中相应的函数是do_write和do_start函数

先看write /proc/1/oom_adj -16 
int do_write(int nargs, char **args){    const char *path = args[1];    const char *value = args[2];   ...    //调用库函数write_file,想 /proc/1/oom_adj 文件里写入16    return write_file(path, value);}
再看start ueventd 
int do_start(int nargs, char **args){    struct service *svc;    //找到servicename是ueventd  的service    svc = service_find_by_name(args[1]);    if (svc) {       //调用service_start 函数        service_start(svc, NULL);    }    return 0;}
service_start在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;        /* 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->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;    }    needs_console = (svc->flags & SVC_CONSOLE) ? 1 : 0;   ....     //创建子进程    pid = fork();    if (pid == 0) {        struct socketinfo *si;        struct svcenvinfo *ei;        char tmp[32];        int fd, sz;               //将属性信息增加到环境变量        if (properties_inited()) {            get_property_workspace(&fd, &sz);            sprintf(tmp, "%d,%d", dup(fd), sz);            add_environment("ANDROID_PROPERTY_WORKSPACE", tmp);        }        for (ei = svc->envvars; ei; ei = ei->next)            add_environment(ei->name, ei->value);        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)); //创建socket int s = create_socket(si->name, socket_type, si->perm, si->uid, si->gid); if (s >= 0) { publish_socket(si->name, s); } } if (svc->ioprio_class != IoSchedClass_NONE) { if (android_set_ioprio(getpid(), svc->ioprio_class, svc->ioprio_pri)) { ERROR("Failed to set pid %d ioprio = %d,%d: %s\n", getpid(), svc->ioprio_class, svc->ioprio_pri, strerror(errno)); } } //pid<0说明创建子进程失败,没有启动服务 if (pid < 0) { ERROR("failed to start '%s'\n", svc->name); svc->pid = 0; return; } //再设置service的启动信息 svc->time_started = gettime();//service的启动时间 svc->pid = pid;//service的进程id svc->flags |= SVC_RUNNING;//service的状态 if (properties_inited()) //更新状态 notify_service_state(svc->name, "running");}

在这个command运行过程中新建一个子进程,并且和service有点关系。那么真正的Service是怎样启动的呢?

3.4.3 Service的启动
事实上在上面已经看到Service的启动时通过service_start函数来实现,那么就看哪个函数调用了它,在system/core/init/builtin.c文件里找到了service_start_if_not_disabled
static void service_start_if_not_disabled(struct service *svc)
{
    if (!(svc->flags & SVC_DISABLED)) {
        service_start(svc, NULL);//调用了service_start函数
    }
}

可是这里是通过Service结构体来启动的。应该找到通过字符串方式启动Service,继续找哪个函数调用service_start_if_not_disabled,找到了do_class_start函数,这个函数就会启动Service。

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;}
那么这个Service在
Keywords.h文件里相应哪一个command呢?
 KEYWORD(class_start, COMMAND, 1, do_class_start);
就是command class_start。
当中关于args[1]參数的意义理解非常重要,我们先看一下init.rc中class_start后面都有什么參数:
class_start main
class_start core
等等,这个core、main究竟是什么意思呢?

是不是想起来Service中有一个option是class的,就是这个东西。

 service_for_each_class(args[1], service_start_if_not_disabled)函数作用就是从service_list中找到全部classname是args[1],且不是disable的的service结构体,并调用service_start_if_not_disabled函数来处理这个Service结构体,这样子就非常明朗了。\
我们在init.rc文件里找那些action中有class_start 的command,找打一个on boot的Action
on boot# basic network init  # set RLIMIT_NICE to allow priorities from 19 to -20   ...# Memory management.  Basic kernel parameters, and allow the high# level system server to be able to adjust the kernel OOM driver# paramters to match how it is managing things.  ...# Define TCP buffer sizes for various networks#   ReadMin, ReadInitial, ReadMax, WriteMin, WriteInitial, WriteMax,  ...# Set this property so surfaceflinger is not started by system_init   ...    class_start core    class_start main
class_start core(main)就是启动全部class为”core”或者”main”的service,那么这些service有那么些呢?


service servicemanager /system/bin/servicemanager    class core   ...service vold /system/bin/vold    class core    ...service netd /system/bin/netd    class main   ...service debuggerd /system/bin/debuggerd    class mainservice ril-daemon /system/bin/rild    class main   ...service surfaceflinger /system/bin/surfaceflinger    class main     ...service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server    class main   ...service drm /system/bin/drmserver    class main   ...service media /system/bin/mediaserver    class main  ...service bootanim /system/bin/bootanimation    class main    ...service dbus /system/bin/dbus-daemon --system --nofork    class main   ...service installd /system/bin/installd    class main  ...service flash_recovery /system/etc/install-recovery.sh    class main     ...service keystore /system/bin/keystore /data/misc/keystore    class main     ...
有非常多这样的Service。这些Service称为守护进程,当中最重要的是zygote和servicemanager。


如今我们找到启动服务的Action:boot,那么我们再看init在解析完init.rc文件之后有没有触发on boot的Action?
 if (!strcmp(bootmode, "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);    }

存在的,确实触发了boot的action。
也就是说Service是通过Action中的class_start classname这样的方式来启动的。假设一个Action中有一个class_start core类型的command。那么在触发该Action之后,全部的classname为core的Service将被创建一个子线程的方式启动,作为init的子线程。

3.4.4 属性服务
android中的属性服务类似于Windows平台中的注冊表,以键值对的方式存放,用来将一些属性存储在属性服务中。
属性服务相同还是通过Action的方式来启动的。
1.属性服务的启动流程
属性服务的启动主要在init.c中,对property操作的地方主要有两个:
queue_builtin_action(property_init_action, "property_init");
queue_builtin_action(property_service_init_action, "property_service_init");
先看调用了创建了Action:property_init,此Action的command相应的函数是:property_init_action,在sytem/core/init/init.c文件里
static int property_init_action(int nargs, char **args)
{
    bool load_defaults = true;

    INFO("property init\n");
    if (!strcmp(bootmode, "charger"))
        load_defaults = false;
    property_init(load_defaults);
    return 0;
}

property_init函数在system/core/init/Property_service.c中
void property_init(bool load_defaults)
{
    init_property_area();//初始化存储区域
    if (load_defaults)
        load_properties_from_file(PROP_PATH_RAMDISK_DEFAULT);//载入配置文件
}

做了两个工作:调用init_property_area(),初始化存储区域; 调用load_properties_from_file(PROP_PATH_RAMDISK_DEFAULT),载入配置文件。
init_property_area()设计到android shared memory,仅仅须要知道这部分分配了一个共享区域
再看 load_properties_from_file(PROP_PATH_RAMDISK_DEFAULT)。载入配置文件并设置:

property_init_action这部分功能就是为property分配内存空间,并读取配置文件。

又创建了Action:property_service_init,此Action的command相应的函数是:property_service_init_action。在sytem/core/init/init.c文件里
static int property_service_init_action(int nargs, char **args)
{
    /* read any property files on system or data and
     * fire up the property service.  This must happen
     * after the ro.foo properties are set above so
     * that /data/local.prop cannot interfere with them.
     */
    start_property_service();
    return 0;
}
调用了
system/core/init/Property_service.c中
start_property_service函数
void start_property_service(void)
{
    int fd;
    //载入其它配置文件
    load_properties_from_file(PROP_PATH_SYSTEM_BUILD);
    load_properties_from_file(PROP_PATH_SYSTEM_DEFAULT);
    load_properties_from_file(PROP_PATH_LOCAL_OVERRIDE);
    /* Read persistent properties after all default values have been loaded. */
    load_persistent_properties();
    //创建一个socket等待client请求
    fd = create_socket(PROP_SERVICE_NAME, SOCK_STREAM, 0666, 0, 0);
    if(fd < 0) return;
    fcntl(fd, F_SETFD, FD_CLOEXEC);
    fcntl(fd, F_SETFL, O_NONBLOCK);
    //监听fd的连接请求。最大请求个数是8
    listen(fd, 8);
    property_set_fd = fd;
}
创建一个socket并监听来自client的连接通信。以下可client是怎样连接的

2.client请求属性服务
上面的过程是属性服务的启动过程。相当于server端,那么开启server是为了让client訪问使用,那么client在哪里请求服务呢?

在sytem/core/libcutils/Properites.c中的property_set函数

int property_set(const char *key, const char *value){    return __system_property_set(key, value);}

__system_property_set在bionic/libc/bionic/system_properites.c文件里
int __system_property_set(const char *key, const char *value)
{
    int err;
    int tries = 0;
    int update_seen = 0;
    prop_msg msg;
     ..
    通过send_prop_msg 函数来他发送消息
    err = send_prop_msg(&msg);
    if(err < 0) {
        return err;
    }
    return 0;
}

static int send_prop_msg(prop_msg *msg)
{
    struct pollfd pollfds[1];
    struct sockaddr_un addr;
    socklen_t alen;
    size_t namelen;
    int s;
    int r;
    int result = -1;
     //创建socket
    s = socket(AF_LOCAL, SOCK_STREAM, 0);
    if(s < 0) {
        return result;
    }
   //为socket设置数据
    memset(&addr, 0, sizeof(addr));
    namelen = strlen(property_service_socket);
    strlcpy(addr.sun_path, property_service_socket, sizeof addr.sun_path);
    addr.sun_family = AF_LOCAL;
    alen = namelen + offsetof(struct sockaddr_un, sun_path) + 1;
    //连接socket
    if(TEMP_FAILURE_RETRY(connect(s, (struct sockaddr *) &addr, alen) < 0)) {
        close(s);
        return result;
    }
   //发送消息
    r = TEMP_FAILURE_RETRY(send(s, msg, sizeof(prop_msg), 0));

    if(r == sizeof(prop_msg)) {
        // We successfully wrote to the property server but now we
        // wait for the property server to finish its work.  It
        // acknowledges its completion by closing the socket so we
        // poll here (on nothing), waiting for the socket to close.
        // If you 'adb shell setprop foo bar' you'll see the POLLHUP
        // once the socket closes.  Out of paranoia we cap our poll
        // at 250 ms.
        pollfds[0].fd = s;
        pollfds[0].events = 0;
        r = TEMP_FAILURE_RETRY(poll(pollfds, 1, 250 /* ms */));
        if (r == 1 && (pollfds[0].revents & POLLHUP) != 0) {
            result = 0;
        } else {
            // Ignore the timeout and treat it like a success anyway.
            // The init process is single-threaded and its property
            // service is sometimes slow to respond (perhaps it's off
            // starting a child process or something) and thus this
            // times out and the caller thinks it failed, even though
            // it's still getting around to it.  So we fake it here,
            // mostly for ctl.* properties, but we do try and wait 250
            // ms so callers who do read-after-write can reliably see
            // what they've written.  Most of the time.
            // TODO: fix the system properties design.
            result = 0;
        }
    }

    close(s);
    return result;
}


3.5 循环监听处理时间
在触发完Action之后进入一个死循环,调用系统函数poll等待信号
 
for(;;) {
        int nr, i, timeout = -1;

        execute_one_command();
        restart_processes();

       //指定了三类事件的监听get_property_set_fd、get_signal_fd、get_keychord_fd
       // 这就是监听来自client请求属性服务的信号  
        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;
        }
       //keychord 信号
        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;
        }

        if (process_needs_restart) {
            timeout = (process_needs_restart - gettime()) * 1000;
            if (timeout < 0)
                timeout = 0;
        }

        if (!action_queue_empty() || cur_action)
            timeout = 0;
      ...
        //使用poll系统调用监听上述三类事件的信号
        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())
                    //keychord信号处理函数 
                    handle_keychord();
                else if (ufds[i].fd == get_signal_fd())
                     //子进程退出信号处理函数  
                    handle_signal();
            }
        }
    }

到此为止循环监听事件结束,init进程也运行完成。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/116514.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

  • .net类的初始化机制,顺序,内存分配,

    .net类的初始化机制,顺序,内存分配,

  • tar 打包隐藏文件[通俗易懂]

    tar 打包隐藏文件[通俗易懂]前言:先说一下遇到的场景:前段时间在配合做DevOps,组内有块代码是php的,需要用tar命令打包归档上传到nexus库,后来发现解压出来的包居然缺失了隐藏文件(配置文件),查了一下资料解决了,这里记录一下。1.tar命令常规用法-c 创建新的档案文件-C 指定到要解压到的目录。注意:该目录必须存在-f 指定打包的文件名。在f之后要立即接打包文件名!不能再加参数!-x 解压-O 将文件解压到标准输出-p 使用原文件的原来属性-P 创建归档文件,使用绝对路径-t 列出档

  • Java的下载与安装简易教程

    Java的下载与安装简易教程分享一下windows10系统下安装Java的教程一.Java的下载与安装要想学习Java语言,第一个条件就是要让电脑上具备有Java环境,那么怎么让电脑具备Java环境呢?1.首先下载Java的安装包。点击Java下载地址:https://www.oracle.com/technetwork/java/javase/downloads/index.html(官网地址)如下图:2.点击上图红色方框的Download,跳转到另一个页面,如下图:…

  • datagrip在线激活码[免费获取]

    (datagrip在线激活码)2021最新分享一个能用的的激活码出来,希望能帮到需要激活的朋友。目前这个是能用的,但是用的人多了之后也会失效,会不定时更新的,大家持续关注此网站~IntelliJ2021最新激活注册码,破解教程可免费永久激活,亲测有效,下面是详细链接哦~https://javaforall.cn/100143.html…

  • mysql根据经纬度计算距离函数_根据两点经纬度坐标计算距离

    mysql根据经纬度计算距离函数_根据两点经纬度坐标计算距离方式1:st_distance_sphereSELECT*,st_distance_sphere(point(lng,lat),point(116.3424590000,40.0497810000))asjuliFROMtableORDERBYjuliASC没用除以1000,所以是以米为单位方式2:st_distanceSELECT*,(st_distance(point(lng,lat),point(116.3424590000,40.0497810000))*1

  • 带通滤波器设计要注意采样率

    带通滤波器设计要注意采样率设计为采样频率600M,中心频率140M,带宽2M,Fs_org=140e6;Fs=Fs_org;T=1/Fs;%600/140=4.28,约600M采样率,t1=[0:T/4.28:1000*T];%原先错误代码,几乎就没有滤波%t1=[0:T/200:1000*T];%错误在于采样率远远大于600Mp=3*sin

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号