Android的init進程啟動過程

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會依次執行幾個重要的階段:

  1. 3.6.1. on early-init階段
    am.QueueEventTrigger("early-init"); 執行on early-init 內容,主要包括 start ueventd 等

  2. 3.6.2. on init 階段
    am.QueueEventTrigger("init"); 執行on init 內容,主要包括 創建/掛載一些目錄,以及symlink等

  3. 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-booton boot兩個Action.

  1. 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)等

  2. 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 如下

15:13:04屏幕截圖.png

上面的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/

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容