Android启动流程
安卓的启动流程
安卓的启动流程大致分为几个阶段。
1、BootRom：启动电源以及系统启动。
当电源按下时，引导芯片代码从预定义的地方（固化在ROM中）开始执行。加载引导程序BootLoader到RAM，然后执行。
2、引导程序Bootloader
引导程序BootLoader是在android操作系统开始运行前的一个小程序，他的主要作用是把系统OS拉起来并运行。
3、Linux kernel启动
当内核启动时，设置缓存、被保护存储器、计划列表、加载驱动。当内核完成系统设置时，它首先在系统文件中寻找init.rc文件，并启动init进程。
4、init进程启动
初始化和启动属性服务，并且启动Zygote进程。
5、Zygote进程启动
创建Java虚拟机并为Java虚拟机注册JNI方法，创建服务器端Socket，启动SystemServer进程。
6、systemserver进程启动
启动Binder线程池和SystemServiceManager，并且启动各种系统服务。
7、Launcher进程启动
被SystemServer进程启动的AMS会启动Launcher，Launcher启动后会将已安装应用的快捷图标显示到界面上。
下面介绍安卓世界的启动流程即从init进程开始讲起。
init进程的启动
首先Bootloader引导程序启动完Linux内核后，会加载各种驱动和数据结构，当有了驱动以后，开始启动Android系统，同时会加载用户级别的第一个进程init。启动该进程首先进入到system/core/init/目录下的main.cpp文件中，执行main方法。
51 int main(int argc, char** argv) {
52 #if __has_feature(address_sanitizer)
53 __asan_set_error_report_callback(AsanReportCallback);
54 #endif
55 // Boost prio which will be restored later
56 setpriority(PRIO_PROCESS, 0, -20);
57 if (!strcmp(basename(argv[0]), "ueventd")) {
58 return ueventd_main(argc, argv);
59 }
60
61 if (argc > 1) {
62 if (!strcmp(argv[1], "subcontext")) {
63 android::base::InitLogging(argv, &android::base::KernelLogger);
64 const BuiltinFunctionMap& function_map = GetBuiltinFunctionMap();
65
66 return SubcontextMain(argc, argv, &function_map);
67 }
68
69 if (!strcmp(argv[1], "selinux_setup")) {
70 return SetupSelinux(argv);
71 }
72
73 if (!strcmp(argv[1], "second_stage")) {
74 return SecondStageMain(argc, argv);
75 }
76 }
77
78 return FirstStageMain(argc, argv);
79 }
80
FirstStageMain
可以在kernel中看到， 启动时并没有带任何参数，所在最先执行的就是FirstStageMain。这个函数主要功能就是创建目录、挂载分区等，最后进入第二次运行init,可以看到这次是带了selinux_setup参数；FirstStageMain函数实现在：system/core/init/first_stage_init.cpp。
int FirstStageMain(int argc, char** argv) {
...
353 if (!DoFirstStageMount(!created_devices)) {
354 LOG(FATAL) << "Failed to mount required partitions early ...";
355 }
...
372 const char* path = "/system/bin/init";
373 const char* args[] = {path, "selinux_setup", nullptr};
374 auto fd = open("/dev/kmsg", O_WRONLY | O_CLOEXEC);
375 dup2(fd, STDOUT_FILENO);
376 dup2(fd, STDERR_FILENO);
377 close(fd);
378 execv(path, const_cast<char**>(args));
379
380 // execv() only returns if an error happened, in which case we
381 // panic and never fall through this conditional.
382 PLOG(FATAL) << "execv(\"" << path << "\") failed";
SetupSelinux
我们根据上面main函数的代码，参数为selinux_setup的时候，执行SetupSelinux函数，
第二步：进入SetupSelinux(argv),这个函数实现在system/core/init/selinux.cpp中。主要就是启动SElinux， 然后现再成功的进入下一步，根据参数可以看到， 接下来进入SecondStageMain
714 int SetupSelinux(char** argv) {
724 MountMissingSystemPartitions();
725
726 SelinuxSetupKernelLogging();
727
728 LOG(INFO) << "Opening SELinux policy";
729
730 // Read the policy before potentially killing snapuserd.
731 std::string policy;
732 ReadPolicy(&policy);
...
742 LoadSelinuxPolicy(policy);
762 const char* path = "/system/bin/init";
763 const char* args[] = {path, "second_stage", nullptr};
764 execv(path, const_cast<char**>(args));
765
SecondStageMain
函数实现是在system/core/init/init.cpp中
728 int SecondStageMain(int argc, char** argv) {
PropertyInit();
...
800 // Now set up SELinux for second stage.
801 SelinuxSetupKernelLogging();
802 SelabelInitialize();
803 SelinuxRestoreContext();
...
StartPropertyService(&property_fd);
...
837 ActionManager& am = ActionManager::GetInstance();
838 ServiceList& sm = ServiceList::GetInstance();
839
840 LoadBootScripts(am, sm);
...
am.QueueEventTrigger("early-init");
...
am.QueueEventTrigger("init");
// Don't mount filesystems or start core system services in charger mode.
std::string bootmode = GetProperty("ro.bootmode", "");
if (bootmode == "charger") {
am.QueueEventTrigger("charger");
} else {
am.QueueEventTrigger("late-init");
}
可以该阶段主要做的事情是初始化property系统，解析init.rc。然后再执行early init action，执行init action, 执行 early-boot and boot actions。
其中/init.rc是主要的.rc文件，由init可执行文件在开始执行时加载。它负责系统的初始设置。
在加载主目录/init.rc后,init立即加载包含在/{system,vendor,odm}/etc/init/目录中的所有文件。
303 static void LoadBootScripts(ActionManager& action_manager, ServiceList& service_list) {
304 Parser parser = CreateParser(action_manager, service_list);
305
306 std::string bootscript = GetProperty("ro.boot.init_rc", "");
307 if (bootscript.empty()) {
308 parser.ParseConfig("/system/etc/init/hw/init.rc");
309 if (!parser.ParseConfig("/system/etc/init")) {
310 late_import_paths.emplace_back("/system/etc/init");
311 }
312 // late_import is available only in Q and earlier release. As we don't
313 // have system_ext in those versions, skip late_import for system_ext.
314 parser.ParseConfig("/system_ext/etc/init");
315 if (!parser.ParseConfig("/vendor/etc/init")) {
316 late_import_paths.emplace_back("/vendor/etc/init");
317 }
318 if (!parser.ParseConfig("/odm/etc/init")) {
319 late_import_paths.emplace_back("/odm/etc/init");
320 }
321 if (!parser.ParseConfig("/product/etc/init")) {
322 late_import_paths.emplace_back("/product/etc/init");
323 }
324 } else {
325 parser.ParseConfig(bootscript);
326 }
327 }
328
我们先看init.rc文件的具体内容。
7 import /init.environ.rc
8 import /system/etc/init/hw/init.usb.rc
9 import /init.${ro.hardware}.rc
10 import /vendor/etc/init/hw/init.${ro.hardware}.rc
11 import /system/etc/init/hw/init.usb.configfs.rc
12 import /system/etc/init/hw/init.${ro.zygote}.rc
on early-init
...
119 on init
...
418 # This allows the ledtrig-transient properties to be created here so
419 # that they can be chown'd to system:system later on boot
420 write /sys/class/leds/vibrator/trigger "transient"
421
422 # This is used by Bionic to select optimized routines.
423 write /dev/cpu_variant:${ro.bionic.arch} ${ro.bionic.cpu_variant}
424 chmod 0444 /dev/cpu_variant:${ro.bionic.arch}
425 write /dev/cpu_variant:${ro.bionic.2nd_arch} ${ro.bionic.2nd_cpu_variant}
426 chmod 0444 /dev/cpu_variant:${ro.bionic.2nd_arch}
427
428 # Allow system processes to read / write power state.
429 chown system system /sys/power/state
430 chown system system /sys/power/wakeup_count
431 chmod 0660 /sys/power/state
438 # Start logd before any other services run to ensure we capture all of their logs.
439 start logd
440 # Start lmkd before any other services run so that it can register them
441 chown root system /sys/module/lowmemorykiller/parameters/adj
442 chmod 0664 /sys/module/lowmemorykiller/parameters/adj
443 chown root system /sys/module/lowmemorykiller/parameters/minfree
444 chmod 0664 /sys/module/lowmemorykiller/parameters/minfree
445 start lmkd
446
447 # Start essential services.
448 start servicemanager
449 start hwservicemanager
450 start vndservicemanager
...
467 # Mount filesystems and start core system services.
468 on late-init
469 trigger early-fs
...
475 trigger fs
476 trigger post-fs
...
495 # Now we can start zygote for devices with file based encryption
496 trigger zygote-start
497
498 # Remove a file to wake up anything waiting for firmware.
499 trigger firmware_mounts_complete
500
501 trigger early-boot
502 trigger boot
946 # It is recommended to put unnecessary data/ initialization from post-fs-data
947 # to start-zygote in device's init.rc to unblock zygote start.
948 on zygote-start && property:ro.crypto.state=unencrypted
949 wait_for_prop odsign.verification.done 1
950 # A/B update verifier that marks a successful boot.
951 exec_start update_verifier_nonencrypted
952 start statsd
953 start netd
954 start zygote
955 start zygote_secondary
956
957 on zygote-start && property:ro.crypto.state=unsupported
958 wait_for_prop odsign.verification.done 1
959 # A/B update verifier that marks a successful boot.
960 exec_start update_verifier_nonencrypted
961 start statsd
962 start netd
963 start zygote
964 start zygote_secondary
965
966 on zygote-start && property:ro.crypto.state=encrypted && property:ro.crypto.type=file
967 wait_for_prop odsign.verification.done 1
968 # A/B update verifier that marks a successful boot.
969 exec_start update_verifier_nonencrypted
970 start statsd
971 start netd
972 start zygote
973 start zygote_secondary
然后我们看是怎么解析init.rc文件的。给parse 变量进行赋值，创建了三个parser，分别是对service ，on,import进行parse。
首先*.rc 脚本中所有 service关键字定义的服务将会添加到 service_list 列表中。
*.rc 脚本中所有 on 关键开头的项将会被会添加到 action_list 列表中。
282 Parser CreateParser(ActionManager& action_manager, ServiceList& service_list) {
283 Parser parser;
284
285 parser.AddSectionParser("service", std::make_unique<ServiceParser>(
286 &service_list, GetSubcontext(), std::nullopt));
287 parser.AddSectionParser("on", std::make_unique<ActionParser>(&action_manager, GetSubcontext()));
288 parser.AddSectionParser("import", std::make_unique<ImportParser>(&parser));
289
290 return parser;
291 }
35 void Parser::AddSectionParser(const std::string& name, std::unique_ptr<SectionParser> parser) {
36 section_parsers_[name] = std::move(parser);
37 }
解析的关键函数是parseData函数，
next_token函数用就是寻找单词结束或者行结束标志，如果是单词结束标志就将单词push到args中，如果是行结束标志，则根据第一个单词来判断是否是一个section，section的标志只有三个"on",“service”,“import”，如果是"section"，会根据关键字的不同会调用不同的 parser去解析(多态) 通过相应的ParseSection()函数来处理一个section,，action 使用 ActionParser，而 service 使用 ServiceParser 解析,该部分定义在LoadBootScrip()函数的第一行,parser.AddSectionParser()方法为parser的map成员section_parsers_创建了三个SectionParser，分别用来解析service，on，import的section；否则把这一行继续作为前“section”所属的行来处理
ParseSection()被用来解析一个新的section，ParseLineSection()被用来解析该section下的命令行
43 void Parser::ParseData(const std::string& filename, std::string* data) {
44 data->push_back('\n');
45 data->push_back('\0');
`...
73 for (;;) {
74 switch (next_token(&state)) {
75 case T_EOF:
76 end_section();
77
78 for (const auto& [section_name, section_parser] : section_parsers_) {
79 section_parser->EndFile();
80 }
81
82 return;
83 case T_NEWLINE: {
84 state.line++;
85 if (args.empty()) break;
86 // If we have a line matching a prefix we recognize, call its callback and unset any
87 // current section parsers. This is meant for /sys/ and /dev/ line entries for
88 // uevent.
89 auto line_callback = std::find_if(
90 line_callbacks_.begin(), line_callbacks_.end(),
91 [&args](const auto& c) { return android::base::StartsWith(args[0], c.first); });
92 if (line_callback != line_callbacks_.end()) {
93 end_section();
94
95 if (auto result = line_callback->second(std::move(args)); !result.ok()) {
96 parse_error_count_++;
97 LOG(ERROR) << filename << ": " << state.line << ": " << result.error();
98 }
99 } else if (section_parsers_.count(args[0])) {
100 end_section();
101 section_parser = section_parsers_[args[0]].get();
102 section_start_line = state.line;
103 if (auto result =
104 section_parser->ParseSection(std::move(args), filename, state.line);
105 !result.ok()) {
106 parse_error_count_++;
107 LOG(ERROR) << filename << ": " << state.line << ": " << result.error();
108 section_parser = nullptr;
109 bad_section_found = true;
110 }
111 } else if (section_parser) {
112 if (auto result = section_parser->ParseLineSection(std::move(args), state.line);
113 !result.ok()) {
114 parse_error_count_++;
115 LOG(ERROR) << filename << ": " << state.line << ": " << result.error();
116 }
117 } else if (!bad_section_found) {
118 parse_error_count_++;
119 LOG(ERROR) << filename << ": " << state.line
120 << ": Invalid section keyword found";
121 }
122 args.clear();
123 break;
124 }
125 case T_TEXT:
126 args.emplace_back(state.text);
127 break;
128 }
129 }
130 }
解析完了init.rc文件以后，调用am.QueueEventTrigger(‘init-early’)意为early-init时间已经到来，可以执行triggle只为early-init的action了。
init最终会进入了无限循环的监听状态，可以看到这里面一个核心函数就是 am.ExecuteOneCommand();之前说的QueueEventTrigger(“early-init”)把early-init加入到event_queue_的队列中，ExecuteOneCommand()一开始就遍历之前解析的action向量表。当一个 action 对象所有的 command 均执行完毕后，再执行下一个action。
zygote 启动
ini进程启动进程中，最关键的是启动zygote
我们在init.rc文件中可以看到出zygote的启动流程是，init.cpp中配置了late-init事件，然后在执行late-init事件的时候，触发了zygote-start事件，然后在zygote-start的时候，执行了start zygote以及start zygote_secondary启动了zygote进程。
zygote进程对应的bin文件是/system/bin/app_process64这个可执行文件，对应的源码路径为frameworks/base/cmds/app_process/app_main.cpp，所以会进到它的main函数中。
我们总结一下，zygote的主要行为是
创建虚拟机–startVM
注册JNI函数–startReg
通过JNI知道Java层的com.android.internal.os.ZygoteInit 类，调用main 函数，进入java 世界。
ZygoteInit.java的路径： frameworks/base/core/java/com/android/internal/os/ZygoteInit.java
该类中会调用ZygoteInit.startSystemServer去启动systemserver。
/frameworks/base/cmds/app_process/app_main.cpp
Zygote总结：
解析init.zygote.rc中的参数，创建AppRuntime并调用AppRuntime.start()方法
调用AndroidRuntime的startVM()方法创建虚拟机，再调用startReg()注册JNI函数
通过JNI方式调用ZygoteInit.main()，第一次进入Java世界
registerZygoteSocket()建立socket通道，zygote作为通信的服务端，用于响应客户端请求
preload()预加载通用类、drawable和color资源、openGL以及共享库以及WebView，用于提高app启动效率
通过startSystemServer()，fork得力帮手system_server进程，也是Java Framework的运行载体（下面讲到system server再详细讲解）
调用runSelectLoop()，随时待命，当接收到请求创建新进程请求时立即唤醒并执行相应工作
systemserver进程的启动
system server进程是由zygote进程fork出来的，在上面的ZygoteInit.main方法中调用forksystemserver方法，新创建出来的system_server进程便进入handleSystemServerProcess()方法，然后执行ZygoteInit.zygoteInit通过反射获取SystemServer类的main方法参数
/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java
888 public static void main(String[] argv) {
...
975 if (startSystemServer) {
976 Runnable r = forkSystemServer(abiList, zygoteSocketName, zygoteServer);
977
978 // {@code r == null} in the parent (zygote) process, and {@code r != null} in the
979 // child (system_server) process.
980 if (r != null) {
981 r.run();
982 return;
983 }
984 }
startBootstrapServices
启动系统启动所需的一小部分关键服务，这些服务具有复杂的相互依赖关系，所以会在此将他们全部初始化。
startCoreServices
启动一些在startBootstrapServices中没有依赖的一部分服务，具体服务如下：
SystemConfigService、BatteryService、UsageStatsService、CachedDeviceStateService、BinderCallsStatsService、LooperStatsService、RollbackManagerService、NativeTombstoneManagerService、BugreportManagerService、GpuService
startOtherServices
启动一些在startBootstrapServices和startCoreServices没有启动的服务，由于服务过多，在此只展示一些我们熟悉的服务，所有服务请通过阅读源码查看。
WindowManagerService、InputManagerService、VibratorManagerService、AlarmManagerService、BluetoothService、StorageManagerService、UiModeManagerService、StatusBarManagerService、VpnManagerService、NotificationManagerService、LocationManagerService、ConnectivityManager
最终也会启动SystemUI的Service。
SystemServer主要负责一下几部分内容：
启动相关的信息的存储。
设置Binder thread相关的配置。
构建ActivityThread以及系统上下文。
通过SystemServiceManager去启动系统中的各种Service。
使Main Looper进入循环，等待消息处理任务。