android系统启动流程启动画面学习之init和init.rc分析
这段时间，断断续续的忙了一阵，因为父亲的去世也不情愿的休息了20来天，一点也没有办法。回来后重新开始学习android的启动流程。对android系统级别的学习，阅读代码成为了唯一的办法，不像应用程序开发来得那么明了快捷。之前花了好多时间才对android的binder驱动做了一定的了解，最近几天从android的启动画面，分析到了init这个内核最先启动的一个进程。参考内容包括老罗的android之旅和邓平凡老师的深入理解android卷，本人只是对学习做一定的总结，帮助自己进一步理解。
一 . init.c中的main函数（路径：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; if (!strcmp(basename(argv[0]), "ueventd")) return ueventd_main(argc, argv); /* clear the umask */ 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", 0, "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); /* 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(); log_init(); INFO("reading config file\n"); init_parse_config_file("/init.rc"); /* pull the kernel commandline and ramdisk properties file in */ import_kernel_cmdline(0); get_hardware_name(hardware, &revision); snprintf(tmp, sizeof(tmp), "/init.%s.rc", hardware);//和平台硬件hardware有关系 init_parse_config_file(tmp); 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(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"); /* execute all the boot actions to get us started */ action_for_each_trigger("init", action_add_queue_tail); 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); 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"); /* execute all the boot actions to get us started */ action_for_each_trigger("early-boot", action_add_queue_tail); action_for_each_trigger("boot", action_add_queue_tail);//把boot这个action添加到action_queue链表中 /* 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 for(;;) { int nr, i, timeout = -1; execute_one_command(); //检查action_queue列表是否为空,执行action 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; } 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(); else if (ufds[i].fd == get_keychord_fd()) handle_keychord(); else if (ufds[i].fd == get_signal_fd()) handle_signal(); } } } return 0;}init作为用户空间第一个启动的进程，需要完成很多的任务。分以下部分内容来分析
1. uevent进程
if (!strcmp(basename(argv[0]), "ueventd"))
return ueventd_main(argc, argv);
这个函数是取出argv中的第一个参数，比如/sbin/ueventd，则basename为ueventd。android系统第一次启动的进程名init,所以该函数ueventd_main不执行，该函数的真正执行在init启动service ueventd /sbin/ueventd后，fork出一个子进程，execve启动/sbin/ueventd后，实际上该函数是对init的符合链接，也就是ueventd进程执行起来后执行的代码还是init.c中的main，因此不同的进程名执行相同的main函数。ueventd_main函数的主要功能：在Linux系统中现在都使用uevent机制来管理设备的热插拔事件，给用户空间权利来完成一些设备文件节点的创建。这种机制是建立在socket的通信机制上，用户空间和内核驱动进行交互，详细的机制没有去了解过。是linux2.6的版本中常用的机制。比如驱动出现device_create等时，会向用户空间报告一个uevent事件，用户空间由uevent进程解析后去创建设备节点。
2.init.rc的解析
INFO("reading config file\n");
init_parse_config_file("/init.rc");
init.rc是一个配置文件，内部有许多的语言规则，所有语言会在init_parse_config_file中进行解析。调用流程如下：init_parse_config_file—>read_file—>parse_config.
parse_config源码如下：
static void parse_config(const char *fn, char *s)//s为init.rc中字符串的内容{ struct parse_state state; char *args[INIT_PARSER_MAXARGS]; int nargs; nargs = 0; state.filename = fn; state.line = 1; state.ptr = s; state.nexttoken = 0; state.parse_line = parse_line_no_op; for (;;) { switch (next_token(&state)) { case T_EOF: //文件的结尾 state.parse_line(&state, 0, 0); return; case T_NEWLINE://新的一行 if (nargs) { int kw = lookup_keyword(args[0]); //读取init.rc返回关键字例如service,返回K_service if (kw_is(kw, SECTION)) { //查看关键字是否为SECTION,只有service和on满足 state.parse_line(&state, 0, 0); parse_new_section(&state, kw, nargs, args); } else { state.parse_line(&state, nargs, args);//on 和service两个段下面的内容 } nargs = 0; } break; case T_TEXT://文本内容 if (nargs < INIT_PARSER_MAXARGS) { args[nargs++] = state.text; } break; } }}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;}这个函数中可以看到在for的无邪循环中，主要对init.rc的内容进行解析，以一行一行进行读取，每读取完一行内容换行时到下一行时，使用lookup_keyword分析已经读取的一行的第一个参数，部分代码如下：
case 's': if (!strcmp(s, "ervice")) return K_service; if (!strcmp(s, "etenv")) return K_setenv; if (!strcmp(s, "etkey")) return K_setkey; if (!strcmp(s, "etprop")) return K_setprop; if (!strcmp(s, "etrlimit")) return K_setrlimit; if (!strcmp(s, "ocket")) return K_socket; if (!strcmp(s, "tart")) return K_start; if (!strcmp(s, "top")) return K_stop; if (!strcmp(s, "ymlink")) return K_symlink; if (!strcmp(s, "ysclktz")) return K_sysclktz;
该函数主要对每一行的第一个字符做case，然后在strcmp第一个命令，这些命令都是按init.rc的格式要求来进行的。比如常用的service和on等经过lookup_keyword后返回K_servcie和K_on。随后使用kw_is(kw, SECTION)判断返回的kw是不是属于SECTION类型，在init.rc中只有service和on满足该类型，这样就会对on和service所在的段进行解析，我们这里首先分析service，以init.rc中的service zygote为例
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
当解析到这段代码时，执行parse_service
static void *parse_service(struct parse_state *state, int nargs, char **args){ struct service *svc; 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); if (!svc) { parse_error(state, "out of memory\n"); return 0; } svc->name = args[1]; //sevice的名字 svc->classname = "default"; //svc的类名默认是default memcpy(svc->args, args + 2, sizeof(char*) * nargs);//首个参数放的是可执行文件 svc->args[nargs] = 0; svc->nargs = nargs;//参数个数 svc->onrestart.name = "onrestart"; list_init(&svc->onrestart.commands); list_add_tail(&service_list, &svc->slist); return svc;}在这里agrs[1]就是zygote，系统会先查找是否已经存在该服务，然后构建一个service svc，进行相关的填充，包括服务名，服务所属的类别名字，已经服务启动带入的参数个数（要减去service和服务名zygote)，最后将这个svc加入到service_list全局链表中。随后所做的是对Service的下面几行Option进行解析，比如class,socket,onrestart等等。使用的是parse_line_service函数，如下：
static void parse_line_service(struct parse_state *state, int nargs, char **args){ struct service *svc = state->context; struct command *cmd; int i, kw, kw_nargs; if (nargs == 0) { return; } svc->ioprio_class = IoSchedClass_NONE; kw = lookup_keyword(args[0]); switch (kw) { case K_capability: break; case K_class: if (nargs != 2) { parse_error(state, "class option requires a classname\n"); } else { svc->classname = args[1];//比如main，core类 } break; case K_console: svc->flags |= SVC_CONSOLE; break; case K_disabled: svc->flags |= SVC_DISABLED;...... case K_onrestart: nargs--; args++; kw = lookup_keyword(args[0]); if (!kw_is(kw, 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; } 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;.......}这里以class这个keyword为例，会将当前class所属的svc进行类名的变革，变为main类别，类似的socket和onrestart类似。
到此为止整个service都解析完成 ，开始下一个section的内容。但是zygote这个服务进程的启动还没有开始，将在下面分析。
下面分析on字段的内容，以on boot这个section作为列子进行分析
on boot ifup lo hostname localhost domainname localdomain....# Set this property so surfaceflinger is not started by system_init setprop system_init.startsurfaceflinger 0 class_start core class_start main
和前面分析像类似，case中进入K_on选项执行函数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)); act->name = args[1]; //action的名字如boot,init等 list_init(&act->commands); list_add_tail(&action_list, &act->alist); /* XXX add to hash */ return act;}在这里可以看到一个action结构体类似于service,这个action的名字为boot，最后会将这个action加入到全局链表action_list中。
随后执行parse_line_action函数，对on字段所在的option进行解析，代码如下：
static void parse_line_action(struct parse_state* state, int nargs, char **args) //action所在的行{ struct command *cmd; struct action *act = state->context;//on boot启动 int (*func)(int nargs, char **args); int kw, n; if (nargs == 0) { return; } kw = lookup_keyword(args[0]);//命令的参数个数 if (!kw_is(kw, 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); cmd->func = kw_func(kw); cmd->nargs = nargs; memcpy(cmd->args, args, sizeof(char*) * nargs); list_add_tail(&act->commands, &cmd->clist); //这里以class_start main为例该关键字为 KEYWORD(class_start, COMMAND, 1, do_class_start)，填充一个command结构体，包括这个cmd的执行函数如class_start对应的func为do_class_start，函数的参数个数nargs=1。同时将这个cmd添加到action的commands所在的全局列表中。本文中将会出现2个cmd。
至此，on和service两个section已经举列子分析完成。
3 下面继续分析main函数中的queue_builtin_action和action_for_each_trigger。
queue_builtin_action(console_init_action, "console_init");//第二个开机画面显示函数
该函数实现将console_init这个action添加到action_queue全局链表中看。
action_for_each_trigger("boot", action_add_queue_tail);//把boot这个action添加到action_queue链表中
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) { act = node_to_item(node, struct action, alist); if (!strcmp(act->name, trigger)) { func(act); } }}在该函数中，首先遍历action_list链表，找到action，看是否有名字叫boot的trigger存在，我们知道刚才在解析init.rc中的on boot时，将boot这个作为action的name加入到了action_list中去，所以可以找到这个boot的action。成功匹配后调用action_add_queue_tail，家这个action再次加入到action_queue中，等待着执行。
4 for(;;)循环中执行execute_one_command
void execute_one_command(void){ int ret; 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; ret = cur_command->func(cur_command->nargs, cur_command->args);//执行class_start等 INFO("command '%s' r=%d\n", cur_command->args[0], ret);}使用action_remove_queue_head获取action_queue链表中的action后，移除该节点，使用get_first_command获得在action中的命令，比如这里出现的boot和console_init这两个action。针对console_init启动console_init_action这个函数。如果是boot则会对boot这个action所具有的commands链表进行cmd的获取，class_start的func指针函数为do_class_start:
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;}可以看到提取了命令行的第二个参数入main，core等。在service_for_each_class中遍历service_list查找属于该类的service，如我们前面提到的zygote，查找到后执行service_start_if_not_disabled——>service_start至此我们进入了启动service的代码
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 * state and immediately takes it out of the restarting * state if it was in there */ svc->flags &= (~(SVC_DISABLED|SVC_RESTARTING)); svc->time_started = 0;//服务的启动时间设为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; if (needs_console && (!have_console)) { ERROR("service '%s' requires console\n", svc->name); svc->flags |= SVC_DISABLED; return; } if (stat(svc->args[0], &s) != 0) { //通过文件名获取文件信息保存到s的buf中 ERROR("cannot find '%s', disabling '%s'\n", svc->args[0], svc->name); svc->flags |= SVC_DISABLED; return; } if ((!(svc->flags & SVC_ONESHOT)) && dynamic_args) { ERROR("service '%s' must be one-shot to use dynamic args, disabling\n", svc->args[0]); svc->flags |= SVC_DISABLED; return; } NOTICE("starting '%s'\n", svc->name); 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)); 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)); } } if (needs_console) { setsid(); open_console(); } else { zap_stdio(); }#if 0 for (n = 0; svc->args[n]; n++) { INFO("args[%d] = '%s'\n", n, svc->args[n]); } for (n = 0; ENV[n]; n++) { INFO("env[%d] = '%s'\n", n, ENV[n]); }#endif setpgid(0, getpid()); /* as requested, set our gid, supplemental gids, and uid */ if (svc->gid) { setgid(svc->gid); } if (svc->nr_supp_gids) { setgroups(svc->nr_supp_gids, svc->supp_gids); } if (svc->uid) { setuid(svc->uid); } 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));//执行服务的可执行文件 } } else { char *arg_ptrs[INIT_PARSER_MAXARGS+1]; int arg_idx = svc->nargs; char *tmp = strdup(dynamic_args); char *next = tmp; char *bword; /* Copy the static arguments */ memcpy(arg_ptrs, svc->args, (svc->nargs * sizeof(char *))); while((bword = strsep(&next, " "))) { arg_ptrs[arg_idx++] = bword; if (arg_idx == INIT_PARSER_MAXARGS) break; } arg_ptrs[arg_idx] = '\0'; execve(svc->args[0], (char**) arg_ptrs, (char**) ENV); } _exit(127); } if (pid < 0) { ERROR("failed to start '%s'\n", svc->name); svc->pid = 0; return; } svc->time_started = gettime(); svc->pid = pid; svc->flags |= SVC_RUNNING; if (properties_inited()) notify_service_state(svc->name, "running");}分析这段代码，主要内容：
a.检查当前service如zygote的flag即SVC_RUNNING（服务运行中），SVC_DISABLE等
b.fork一个子进程，子进程中会建立一个socket用于通信，同时使用if (execve(svc->args[0], (char**) svc->args, (char**) ENV) < 0)执行zygote对应的可执行文件，至此service zygote真正的启动。
到这里为止，对android系统的init启动有了清晰的了解，对init如何启动adbd，zygote等service有了一定的了解，以及对init.rc有了清晰的认识。init中还有部分内容等着后续几天做一定的学习。
补充：service进程的重启在restart_processes中进行，他会重启flag为SVC_RESTARTING的服务。这部分进程的重启其实在init由handle_signal来管理，一旦出现service崩溃，poll函数会接受到相关文件变化的信息，执行handle_signal中的wait_for_one_process
static int wait_for_one_process(int block){ pid_t pid; int status; struct service *svc; struct socketinfo *si; time_t now; struct listnode *node; struct command *cmd; while ( (pid = waitpid(-1, &status, block ? 0 : WNOHANG)) == -1 && errno == EINTR ); if (pid <= 0) return -1; INFO("waitpid returned pid %d, status = %08x\n", pid, status); svc = service_find_by_pid(pid); if (!svc) { ERROR("untracked pid %d exited\n", pid); return 0; }..... svc->flags |= SVC_RESTARTING; /* Execute all onrestart commands for this service. */ list_for_each(node, &svc->onrestart.commands) { cmd = node_to_item(node, struct command, clist); cmd->func(cmd->nargs, cmd->args); } notify_service_state(svc->name, "restarting"); return 0;}该函数使用waitpid,找到子进程退出的进程号pid，然后查找到该service，对service中的onrestart这个commands进行操作，入restart media等。同时将service的flag设置为SVC_RESTARTING，这样就结合前面讲到的restart_processes重新启动该服务进程。。