0. 前言
Android中的內核啟動后,kernel會啟動第一個用戶級別的進程:init,它是一個由內核啟動的第一個用戶級進程。
我們可以通過 adb shell ps | grep init 來查看到他的pid 為 1.
接下來從源碼的角度看看init進程啟動的時候做了什么?
注:本文分析的andorid版本為 remotes/aosp/nougat-release.
init進程的源碼在android源碼的: <Android源代碼目錄>/system/core/init 目錄中。
我們看到該目錄下有一個Android.mk文件,至少看到如下內容,告訴我們會生成一個init的的可執行文件。
LOCAL_MODULE:= init
include $(BUILD_EXECUTABLE)
而init的入口main函數是在init.cpp文件中定義的。
1. 入口
a. 命令行解析
if (!strcmp(basename(argv[0]), "ueventd")) {
return ueventd_main(argc, argv);
}
if (!strcmp(basename(argv[0]), "watchdogd")) {
return watchdogd_main(argc, argv);
}
watchdog和uevent命令已經集成到了init, 它們在/sbin目錄,是一個鏈接文件,直接鏈接到/init,所以當執行/sbin/eventd或/sbin/watchdogd時,將會進入對應的ueventd_main或watchdogd_main入口點。
ueventd守護進程負責解析/ueventd.rc文件,并創建相應的設備結點等。
watchdogd守護進程負責定時向 "/dev/watchdog"執行寫操作,以判斷系統是否正常運行。
這兩個進程不是本文討論的重點,所以先忽略。。。
b. 掛載根文件系統的目錄
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, "hidepid=2,gid=" MAKE_STR(AID_READPROC));
mount("sysfs", "/sys", "sysfs", 0, NULL);
mount("selinuxfs", "/sys/fs/selinux", "selinuxfs", 0, NULL);
mknod("/dev/kmsg", S_IFCHR | 0600, makedev(1, 11));
分別掛載proc和和sysfs文件系統到/proc 和/sys目錄
close(open("/dev/.booting", O_WRONLY | O_CREAT | O_CLOEXEC, 0000));
在/dev目錄創建一個空文件.booting來表示正在執行初始化
InitKernelLogging(argv);
重定向標準輸入,標準輸出,標準錯誤輸出到 /dev/null
selinux_initialize(is_first_stage)
加載SELinux策略, 后面有一些初始化文件上下文的操作等
3. 解析init.rc文件
Parser& parser Parser::GetInstance();
parser.AddSectionParser("service",std::make_unique<ServiceParser>());
parser.AddSectionParser("on", std::make_unique<ActionParser>());
parser.AddSectionParser("import", std::make_unique<ImportParser>());
parser.ParseConfig("/init.rc");
3.1. init.rc文件是以塊(section)為單位組織的,一個section包含多行。section分為兩大類:分別為“服務(service)”和“行為(action)”。
3.2. “服務”塊以關鍵字“service”開始,表示啟動某個進程的方式和參數,“行為”塊以關鍵字“on”開始,表示一堆命令的集合。每個塊以關鍵字“service”或“on”開始,直到下一個“on”或“service”結束,中間所有行都屬于這個“塊”。
3.3. 上面在解析init.rc文件時使用了Parser類(在init目錄下的init_parser.h中定義), 初始化ServiceParser用來解析 “service”塊,ActionParser用來解析"on"塊,ImportParser用來解析“import”塊,“import”是用來引入一個init配置文件,來擴展當前配置的。
3.4. parser解析init.rc文件,/init.rc文件是<Android源代碼目錄>/system/core/rootdir/init.rc。
3.5. <Android源代碼目錄>/system/core/init/readme.txt 中對init文件中的所有關鍵字做了介紹,主要包含了Actions, Commands, Services, Options, and Imports等
3.6. 在ParseConfig解析完init腳本后,init會依次執行幾個重要的階段:
3.6.1. on early-init階段
am.QueueEventTrigger("early-init");
執行on early-init
內容,主要包括 start ueventd 等3.6.2. on init 階段
am.QueueEventTrigger("init");
執行on init
內容,主要包括 創建/掛載一些目錄,以及symlink等-
3.6.3. on charger/late-init階段
// Don't mount filesystems or start core system services in charger mode.
std::string bootmode = property_get("ro.bootmode");
if (bootmode == "charger") {
am.QueueEventTrigger("charger");
} else {
am.QueueEventTrigger("late-init");
}
如果是充電模式下啟動 就會執行on charger
內容, 否則執行on late-init
內容,在init.rc的on late-init
中
看到很多trigger(觸發器),用于執行對應的Action.
trigger late-fs# Now we can mount /data. File encryption requires keymaster to decrypt # /data, which in turn can only be loaded when system properties are present. trigger post-fs-data # Load persist properties and override properties (if enabled) from /data. trigger load_persist_props_action # Remove a file to wake up anything waiting for firmware. trigger firmware_mounts_complete trigger early-boot trigger boot
從最后兩行可以看出,late-init
觸發了on early-boot
和on boot
兩個Action.
3.6.4. on boot 階段
在on boot
的最后class_start core
會啟動class為core的服務,這些服務包括ueventd、logd、healthd、adbd(disabled)、lmkd(LowMemoryKiller)、servicemanager、vold、debuggerd、surfaceflinger、bootanim(disabled)等-
3.6.5. main服務的啟動
在main函數后面的for循環中,調用execute_one_command依次執行操作隊列中的命令
while (true) {
if (!waiting_for_exec) {
am.ExecuteOneCommand();
restart_processes();
}
}
在/init.rc的開頭部分
import /init.environ.rc
import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.usb.configfs.rc
import /init.${ro.zygote}.rc通過ro.zygote的屬性import對應的zygote的rc文件,通過
adb shell getprop ro.zygote
查看得到zygote64_32, 所以import的是/init.zygote64_32.rc文件,該文件中定義的zygote如下:service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server --socket-name=zygote class main priority -20 socket zygote stream 660 root system onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart restart audioserver onrestart restart cameraserver onrestart restart media onrestart restart netd writepid /dev/cpuset/foreground/tasks /dev/stune/foreground/tasks
可以看到zygote的class是main, 它是在
on nonencrypted
時被啟動的
on nonencrypted
# A/B update verifier that marks a successful boot.
exec - root -- /system/bin/update_verifier nonencrypted
class_start main
class_start late_start
注:但在Android 7.0中,對該機制做了一些改變 。
單一的init*.rc,被拆分,服務根據其二進制文件的位置(/system,/vendor,/odm)定義到對應分區的etc/init目錄中,每個服務一個rc文件。與該服務相關的觸發器、操作等也定義在同一rc文件中。
/system/etc/init,包含系統核心服務的定義,如SurfaceFlinger、MediaServer、Logcatd等。
/vendor/etc/init, SOC廠商針對SOC核心功能定義的一些服務。比如高通、MTK某一款SOC的相關的服務。
/odm/etc/init,OEM/ODM廠商如小米、華為、OPP其產品所使用的外設以及差異化功能相關的服務。
查看android 7.0虛擬機的/system/etc/init 如下
上面的servicemanager這個服務也從init.rc中拆分出來了。
4. 啟動完成
至此,init進程已經啟動完成,一些重要的服務如core服務和main服務也都啟動起來,并啟動了zygote(/system/bin/app_process64)進程,zygote初始化時會創建虛擬機,啟動systemserver等,它的啟動過程也是非常復雜,等下一篇再說。。
5. 擴展閱讀
http://wonview.blog.163.com/blog/static/585013272012111924915229/
http://blog.csdn.net/k_linux_man/article/details/7292746
http://blog.csdn.net/fuyajun01/article/details/22572921
http://blog.csdn.net/windskier/article/details/6416547/