[深刻理解Android卷一全文-第三章]深刻理解init

因爲《深刻理解Android 卷一》和《深刻理解Android卷二》再也不出版,而知識的傳播不該該由於紙質媒介的問題而中斷,因此我將在OSC博客中全文轉發這兩本書的所有內容。 node


第3章  深刻理解init

本章主要內容 android

·  深刻分析init。 shell

本章涉及的源代碼文件名及位置 數組

下面是本章分析的源碼文件名及其位置。 服務器

·  init.c app

system/core/init/init.c dom

·  parser.c socket

system/core/init/parser.c ionic

·  builtins.c 函數

system/core/init/builtins.c

·  keywords.h

system/core/init/keywords/h

·  init.rc

system/core/rootdir/init.rc

·  properties_service.c

system/core/init/properties_service.c

·  libc_init_dynamic.c

bionic/libc/bionic/libc_init_common.c

·  libc_init_common.c

bionic/libc/bionic/libc_init_common.c

·  properties.c

system/core/libcutils/properties.c

3.1  概述

 init是一個進程,確切地說,它是Linux系統中用戶空間的第一個進程。因爲Android是基於Linux內核的,因此init也是Android系統中用戶空間的第一個進程,它的進程號是1。做爲天字第一號的進程,init被賦予了不少極其重要的工做職責,本章將關注其中兩個比較重要的職責:

·  init進程負責建立系統中的幾個關鍵進程,尤爲是下一章要介紹的Zygote,它更是Java世界的開創者。那麼,init進程是如何建立Zygote的呢?

·  Android系統有不少屬性,因而init就提供了一個property service(屬性服務)來管理它們。那麼這個屬性服務是怎麼工做的呢?

如上所述,本章將經過下面兩方面內容來分析init:

·  init如何建立zygote。

·  init的屬性服務是如何工做的。

 

3.2  init分析

init進程的入口函數是main,它的代碼以下所示:

[-->init.c]

int main(int argc, char **argv)

{

    intdevice_fd = -1;

    intproperty_set_fd = -1;

    intsignal_recv_fd = -1;

    intkeychord_fd = -1;

    int fd_count;

    ints[2];

    intfd;

    structsigaction act;

    chartmp[PROP_VALUE_MAX];

    structpollfd ufds[4];

    char*tmpdev;

    char*debuggable;

   

   //設置子進程退出的信號處理函數,該函數爲sigchld_handler。

   act.sa_handler = sigchld_handler;

    act.sa_flags= SA_NOCLDSTOP;

   act.sa_mask = 0;

   act.sa_restorer = NULL;

   sigaction(SIGCHLD, &act, 0);

  

   ......//建立一些文件夾,並掛載設備,這些是和Linux相關的,不擬作過多討論。

   mkdir("/dev/socket", 0755);

   mount("devpts", "/dev/pts", "devpts", 0,NULL);

   mount("proc", "/proc", "proc", 0, NULL);

   mount("sysfs", "/sys", "sysfs", 0, NULL);

 

    //重定向標準輸入/輸出/錯誤輸出到/dev/_null_。

open_devnull_stdio();

/*

設置init的日誌輸出設備爲/dev/__kmsg__,不過該文件打開後,會當即被unlink了,

這樣,其餘進程就沒法打開這個文件讀取日誌信息了。

*/

   log_init();

   

   //上面涉及不少和Linux系統相關的知識,不熟悉的讀者可自行研究,它們不影響咱們的分析

   //解析init.rc配置文件

   parse_config_file("/init.rc");

 

    ......

    //下面這個函數經過讀取/proc/cpuinfo獲得機器的Hardware名,個人HTCG7手機爲bravo。

   get_hardware_name();

snprintf(tmp,sizeof(tmp), "/init.%s.rc", hardware);

//解析這個和機器相關的配置文件,個人G7手機對應文件爲init.bravo.rc。

   parse_config_file(tmp);

 

/*

解析完上述兩個配置文件後,會獲得一系列的Action(動做),下面兩句代碼將執行那些處於

early-init階段的Action。init將動做執行的時間劃分爲四個階段:early-init、init、

early-boot、boot。因爲有些動做必須在其餘動做完成後才能執行,因此就有了前後之分。哪些

動做屬於哪一個階段由配置文件決定。後面會介紹配置文件的相關知識。

*/

   action_for_each_trigger("early-init", action_add_queue_tail);

   drain_action_queue();

 

/*

建立利用Uevent和Linux內核交互的socket。關於Uevent的知識,第9章中對

Vold進行分析時會作介紹。

    */

   device_fd = device_init();

    //初始化和屬性相關的資源

property_init();

//初始化/dev/keychord設備,這和調試有關,本書不討論它的用法。讀者能夠自行研究,

//內容比較簡單。

   keychord_fd = open_keychord();

 

    ......

/*

  INIT_IMAGE_FILE定義爲」/initlogo.rle」,下面這個函數將加載這個文件做爲系統的開機

 畫面,注意,它不是開機動畫控制程序bootanimation加載的開機動畫文件。

*/

if(load_565rle_image(INIT_IMAGE_FILE) ) {

   /*

若是加載initlogo.rle文件失敗(多是沒有這個文件),則會打開/dev/ty0設備,並

輸出」ANDROID」的字樣做爲開機畫面。在模擬器上看到的開機畫面就是它。

*/

      ......

      }

   }

 

    if(qemu[0])

       import_kernel_cmdline(1);

   ......

//調用property_set函數設置屬性項,一個屬性項包括屬性名和屬性值。

   property_set("ro.bootloader", bootloader[0] ? bootloader :"unknown");

 

    ......//執行位於init階段的動做

   action_for_each_trigger("init", action_add_queue_tail);

   drain_action_queue();

 

    //啓動屬性服務

   property_set_fd = start_property_service();

 

/*

調用socketpair函數建立兩個已經connect好的socket。socketpair是Linux的系統調用,

不熟悉的讀者能夠利用man socketpair查詢相關信息。後面就會知道它們的用處了。

*/

    if(socketpair(AF_UNIX, SOCK_STREAM, 0, s) == 0) {

       signal_fd = s[0];

       signal_recv_fd = s[1];

        ......

    }

 

    ......

 

    //執行配置文件中early-boot和boot階段的動做。

   action_for_each_trigger("early-boot", action_add_queue_tail);

   action_for_each_trigger("boot", action_add_queue_tail);

   drain_action_queue();

......    

   

//init關注來自四個方面的事情。

    ufds[0].fd= device_fd;//device_fd用於監聽來自內核的Uevent事件

   ufds[0].events = POLLIN;

   ufds[1].fd = property_set_fd;//property_set_fd用於監聽來自屬性服務器的事件

ufds[1].events= POLLIN;

//signal_recv_fd由socketpair建立,它的事件來自另一個socket。

   ufds[2].fd = signal_recv_fd;

   ufds[2].events = POLLIN;

   fd_count = 3;

if(keychord_fd > 0) {

   //若是keychord設備初始化成功,則init也會關注來自這個設備的事件。

       ufds[3].fd = keychord_fd;

       ufds[3].events = POLLIN;

       fd_count++;

}

......

 

#if BOOTCHART

    ......//與Boot char相關,不作討論了。

/*

Boot chart是一個小工具,它能對系統的性能進行分析,並生成系統啓動過程的圖表,

以提供一些有價值的信息,而這些信息最大的用處就是幫助提高系統的啓動速度。

    */

#endif

  for(;;) {

        //今後init將進入一個無限循環。

       int nr, i, timeout = -1;

 

       for (i = 0; i < fd_count; i++)

           ufds[i].revents = 0;

       

        //在循環中執行動做

       drain_action_queue();

       restart_processes(); //重啓那些已經死去的進程

......

#if BOOTCHART

        ...... // Boot Chart相關

#endif

        //調用poll等待一些事情的發生

        nr= poll(ufds, fd_count, timeout);

       ......

       //ufds[2]保存的是signal_recv_fd,用於接收來自socket的消息。

        if(ufds[2].revents == POLLIN) {

           //有一個子進程去世,init要處理這個事情

            read(signal_recv_fd, tmp, sizeof(tmp));

           while (!wait_for_one_process(0))

               ;

           continue;

        }

 

        if(ufds[0].revents == POLLIN)

           handle_device_fd(device_fd);//處理Uevent事件

        if(ufds[1].revents == POLLIN)

           handle_property_set_fd(property_set_fd);//處理屬性服務的事件。

        if(ufds[3].revents == POLLIN)

           handle_keychord(keychord_fd);//處理keychord事件。

    }

 

    return0;

}

從上面的代碼中可知,init的工做任務仍是很重的。上面的代碼雖已省略了很多行,可結果仍是很長,不過從本章要分析的兩個知識點來看,可將init的工做流程精簡爲如下四點:

·  解析兩個配置文件,其中,將分析對init.rc文件的解析。

·  執行各個階段的動做,建立Zygote的工做就是在其中的某個階段完成的。

·  調用property_init初始化屬性相關的資源,而且經過property_start_service啓動屬性服務。

·  init進入一個無限循環,而且等待一些事情的發生。重點關注init如何處理來自socket和來自屬性服務器相關的事情。

精簡工做流程,是之後分析代碼時經常使用的方法。讀者在分析代碼的過程當中,也可以使用這種方法。

3.2.1  解析配置文件

根據上面的代碼可知,在init中會解析兩個配置文件,其中一個是系統配置文件init.rc,另一個是和硬件平臺相關的配置文件。以HTC G7手機爲例,這個配置文件名爲init.bravo.rc,其中bravo是硬件平臺的名稱。對這兩個配置文件進行解析,調用的是同一個parse_config_file函數。下面就來看這個函數,在分析過程當中以init.rc爲主。

[-->parser.c]

int parse_config_file(const char *fn)

{

char *data;

data = read_file(fn, 0);//讀取配置文件的內容,這個文件是init.rc。

if (!data) return -1;

parse_config(fn,data); //調用parse_config作真正的解析

return 0;

}

讀取完文件的內容後,將調用parse_config進行解析,這個函數的代碼以下所示:

[-->parser.c]

static void parse_config(const char *fn, char*s)

{

struct parse_state state;

char *args[SVC_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;

      caseT_NEWLINE:

           if (nargs) {

              //獲得關鍵字的類型

               int kw = lookup_keyword(args[0]);

               if (kw_is(kw, SECTION)) { //判斷關鍵字類型是否是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:

          ......

           break;

        }

    }

}

上面就是parse_config函數,代碼雖短,實際卻比較複雜。從總體來講,parse_config首先會找到配置文件的一個section,而後針對不一樣的 section使用不一樣的解析函數來解析。那麼,什麼是section呢?這和init.rc文件的組織結構有關。先沒必要急着去看init.rc,仍是先到代碼中去尋找答案。

1. 關鍵字定義

keywords.h這個文件定義了init中使用的關鍵字,它的用法頗有意思,先來看這個文件,代碼以下所示:

[-->keywords.h]

#ifndef KEYWORD //若是沒有定義KEYWORD宏,則走下面的分支

......//聲明一些函數,這些函數就是前面所說Action的執行函數。

int do_class_start(int nargs, char **args);

int do_class_stop(int nargs, char **args);

......

int do_restart(int nargs, char **args);

......

#define __MAKE_KEYWORD_ENUM__  //定義一個宏

/*

定義KEYWORD宏,雖然有四個參數,不過這裏只用第一個,其中K_##symbol中的##表示鏈接

的意思,即最後獲得的值爲K_symbol。symbol其實就是init.rc中的關鍵字

*/

#define KEYWORD(symbol, flags, nargs, func)K_##symbol,

enum { //定義一個枚舉,這個枚舉定義了各個關鍵字的枚舉值。

   K_UNKNOWN,

#endif

......

//根據上面KEYWORD的定義,這裏將獲得一個枚舉值K_class,

   KEYWORD(class,       OPTION,  0, 0)

   KEYWORD(class_start, COMMAND, 1, do_class_start)//K_class_start,

KEYWORD(class_stop,  COMMAND, 1, do_class_stop)//K_class_stop,

KEYWORD(on,          SECTION, 0, 0)//K_on,

   KEYWORD(oneshot,     OPTION,  0, 0)

   KEYWORD(onrestart,   OPTION,  0, 0)

   KEYWORD(restart,     COMMAND, 1,do_restart)

   KEYWORD(service,     SECTION, 0,0)

    ......

   KEYWORD(socket,      OPTION,  0, 0)

   KEYWORD(start,       COMMAND, 1,do_start)

   KEYWORD(stop,        COMMAND, 1,do_stop)

    ......

#ifdef __MAKE_KEYWORD_ENUM__

   KEYWORD_COUNT,

};

#undef __MAKE_KEYWORD_ENUM__

#undef KEYWORD //取消KEYWORD宏定義

#endif

keywords.h好像沒什麼奇特,不過是個簡單的頭文件。爲何說它的用法頗有意思呢?來看代碼中是如何使用它的,以下所示:

[-->parser.c]

......//parser.c中將包含keywords.h頭文件,並且還不僅一次!!

//第一次包含keywords.h,根據keywords.h的代碼,咱們首先會獲得一個枚舉定義

#include "keywords.h"

/*

從新定義KEYWORD宏,這回四個參數全用上了,看起來好像是一個結構體。其中#symbol表示

一個字符串,其值爲「symbol」。

*/

#define KEYWORD(symbol, flags, nargs, func) \

    [K_##symbol ] = { #symbol, func, nargs + 1, flags, },

 

//定義一個結構體keyword_info數組,它用來描述關鍵字的一些屬性,請注意裏面的註釋內容。

struct {

    constchar *name;  //關鍵字的名。

    int(*func)(int nargs, char **args);//對應關鍵字的處理函數。

unsignedchar nargs;//參數個數,每一個關鍵字的參數個數是固定的。

//關鍵字的屬性,有三種屬性,COMMAND、OPTION和SECTION。其中COMMAND有對應的處理函數

   unsigned char flags;

} keyword_info[KEYWORD_COUNT] = {

[ K_UNKNOWN ] = { "unknown", 0, 0, 0},

/*

第二次包含keywords.h,因爲已經從新定了KEYWORD宏,因此之前那些做爲枚舉值的關鍵字

如今變成keyword_info數組的索引了。

*/

#include "keywords.h"   

};

#undef KEYWORD

 

//一些輔助宏,幫助咱們快速操做keyword_info中的內容。

#define kw_is(kw, type) (keyword_info[kw].flags& (type))

#define kw_name(kw) (keyword_info[kw].name)

#define kw_func(kw) (keyword_info[kw].func)

#define kw_nargs(kw) (keyword_info[kw].nargs)

如今領略了keywords.h的神奇之處了吧?原來它幹了兩件事情:

·  第一次包含keyworks.h時,它聲明瞭一些諸如do_classstart這樣的函數,另外還定義了一個枚舉,枚舉值爲K_class,K_mkdir等關鍵字。

·  第二次包含keywords.h後,獲得了一個keyword_info結構體數組,這個keyword_info結構體數組之前面定義的枚舉值爲索引,存儲對應的關鍵字信息,這些信息包括關鍵字名、處理函數、處理函數的參數個數,以及屬性。

目前,關鍵字信息中最重要的就是symbol和flags了。什麼樣的關鍵字被認爲是section呢?根據keywords.h的定義,symbol爲下面兩個的關鍵字表示section:

KEYWORD(on,          SECTION, 0, 0)

KEYWORD(service,     SECTION, 0, 0)

有了上面的知識,再來看配置文件init.rc的內容。

2. init.rc的解析

init.rc的內容以下所示:(咱們截取了部份內容,注意,其中的註釋符號是#。)

[-->init.rc]

on init  #根據上面的分析,on關鍵字標示一個section,對應的名字是」init」

 ......  #下面全部的內容都屬於這個section,直到下一個section開始時。

 exportPATH /sbin:/system/sbin:/system/bin:/system/xbin

 exportLD_LIBRARY_PATH /system/lib

 exportANDROID_BOOTLOGO 1 #根據keywords.h的定義,export表示一個COMMAND

export ANDROID_ROOT /system

 exportANDROID_ASSETS /system/app

...... #省略部份內容

on boot  #這是一個新的section,名爲」boot」

   ifup lo#這是一個COMMAND

   hostname localhost

   domainname localdomain

    ......

   #class_start也是一個COMMAND,對應函數爲do_class_start,很重要,切記。

    class_startdefault 

    ......

#下面這個section的意思是:待屬性persist.service.adb.enable的值變爲1後,

#須要執行對應的COMMAND,這個COMMAND是start adbd

     onproperty:persist.service.adb.enable=1

         start adbd //start是一個COMMAND

     on property:persist.service.adb.enable=0

         stopadbd

    ......

#service也是section的標示,對應section的名爲「zygote「

service zygote /system/bin/app_process -Xzygote/system/bin –zygote        \

 --start-system-server

    socketzygote stream 666  #socket關鍵字表示OPTION

   onrestart write /sys/android_power/request_state wake #onrestart也是OPTION

   onrestart write /sys/power/state on

   onrestart restart media

#一個section,名爲」media」

service media /system/bin/mediaserver

    usermedia

    groupsystem audio camera graphics inet net_bt net_bt_admin net_raw

iopriort 4

從上面對init.rc的分析中可知:

·  一個section的內容從這個標示section的關鍵字開始,到下一個標示section的地方結束。

·  init.rc中出現了名爲boot和init的section,這裏的boot和init,就是前面介紹的動做執行四個階段中的boot和init。也就是說,在boot階段執行的動做都是由boot這個section定義的。

另外還可發現,zygote被放在了一個servicesection中。下面以zygote這個section爲例,介紹service是如何解析的。

3.2.2  解析service

zygote對應的service section內容是:

[-->init.rc::zygote]

service zygote /system/bin/app_process -Xzygote/system/bin –zygote \ --start-system-server

socketzygote stream 666  #socket是OPTION

#下面的onrestart是OPTION,而write和restart是COMMAND

    onrestartwrite /sys/android_power/request_state wake

   onrestart write /sys/power/state on

onrestartrestart media

解析section的入口函數是parse_new_section,它的代碼以下所示:

[-->parser.c]

void parse_new_section(struct parse_state*state, int kw,

                       int nargs, char **args)

{

   switch(kw) {

    caseK_service:  //解析service,用parse_service和parse_line_service

       state->context = parse_service(state, nargs, args);

        if(state->context) {

           state->parse_line = parse_line_service;

            return;

        }

       break;

    caseK_on: //解析on section

        ......//讀者能夠本身研究

       break;

    }

   state->parse_line = parse_line_no_op;

}

其中,service解析時,用到了parse_service和parse_line_service兩個函數,在分別介紹它們以前,先看init是如何組織這個service的。

1. service結構體

init中使用了一個叫service的結構體來保存和service section相關的信息,不妨來看這個結構體,代碼以下所示:

[-->init.h::service結構體定義]

struct service {

 //listnode是一個特殊的結構體,在內核代碼中用得很是多,主要用來將結構體連接成一個

  //雙向鏈表。init中有一個全局的service_list,專門用來保存解析配置文件後獲得的service。

   struct listnode slist; 

    constchar *name; //service的名字,對應咱們這個例子就是」zygote」。

    constchar *classname; //service所屬class的名字,默認是」defult」

   unsigned flags;//service的屬性

    pid_tpid;    //進程號

    time_ttime_started;   //上一次啓動的時間

    time_ttime_crashed;  //上一次死亡的時間

    intnr_crashed;        //死亡次數

     uid_tuid;     //uid,gid相關

    gid_tgid;

    gid_tsupp_gids[NR_SVC_SUPP_GIDS];

    size_tnr_supp_gids;

   /*

有些service須要使用socket,下面這個socketinfo用來描述socket的相關信息。

咱們的zygote也使用了socket,配置文件中的內容是socket zygote stream 666。

它表示將建立一個AF_STREAM類型的socket(其實就是TCP socket),該socket的名爲「zygote」,

讀寫權限是666。

   */

structsocketinfo *sockets; 

//service通常運行在單獨的一個進程中,envvars用來描述建立這個進程時所需的環境變量信息。

    structsvcenvinfo *envvars; 

   /*

  雖然關鍵字onrestart標示一個OPTION,但是這個OPTION後面通常跟着COMMAND,

 下面這個action結構體可用來存儲command信息,立刻就會分析到它。

*/

    structaction onrestart;

   

    //和keychord相關的內容

    int*keycodes;

    intnkeycodes;

    intkeychord_id;

    //io優先級設置

    intioprio_class;

    intioprio_pri;

    //參數個數

    intnargs;

    //用於存儲參數

    char*args[1];

}; 

咱們如今已瞭解的service的結構體,相對來講還算是清晰易懂的。而zygote中的那三個onrestart該怎麼表示呢?請看service中使用的這個action結構體:

[-->init.h::action結構體定義]

struct action {

/*

一個action結構體可存放在三個雙向鏈表中,其中alist用於存儲全部action,

qlist用於連接那些等待執行的action,tlist用於連接那些待某些條件知足後

就須要執行的action。

*/

    structlistnode alist;

   structlistnode qlist;

    structlistnode tlist;

 

   unsigned hash;

    constchar *name;

   

   //這個OPTION對應的COMMAND鏈表,以zygote爲例,它有三個onrestart option,因此

  //它對應會建立三個command結構體。

    structlistnode commands;

    structcommand *current;

};

瞭解了上面的知識後,你是否能猜到parse_service和parse_line_service的做用了呢?立刻就來看它們。

2. parse_service

parse_service的代碼以下所示:

[-->parser.c]

static void *parse_service(struct parse_state*state, int nargs, char **args)

{

    structservice *svc; //聲明一個service結構體

    ......

    //init維護了一個全局的service鏈表,先判斷是否已經有同名的service了。

    svc =service_find_by_name(args[1]);

    if(svc) {

       ......  //若是有同名的service,則不能繼續後面的操做。

       return 0;

    }

   

nargs-= 2;

    svc =calloc(1, sizeof(*svc) + sizeof(char*) * nargs);

    ......

   svc->name = args[1];

svc->classname= "default";//設置classname爲」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);

    //把zygote這個service加到全局鏈表service_list中。

   list_add_tail(&service_list, &svc->slist);

    returnsvc;

}

parse_service函數只是搭建了一個service的架子,具體的內容尚需由後面的解析函數來填充。來看service的另一個解析函數parse_line_service。

3. parse_line_service

parse_line_service的代碼以下所示:

[-->parser.c]

static void parse_line_service(structparse_state *state, int nargs,

char **args)

{

    structservice *svc = state->context;

    structcommand *cmd;

    int i,kw, kw_nargs;

    ......

   svc->ioprio_class = IoSchedClass_NONE;

    //其實仍是根據關鍵字來作各類處理。

    kw =lookup_keyword(args[0]);

    switch(kw) {

    caseK_capability:

       break;

    caseK_class:

        if(nargs != 2) {

           ......

        }else {

           svc->classname = args[1];

        }

       break;

    ......

caseK_oneshot:

   /*

這是service的屬性,它一共有五個屬性,分別爲:

SVC_DISABLED:不隨class自動啓動。下面將會看到class的做用。

SVC_ONESHOT:退出後不須要重啓,也就是這個service只啓動一次就能夠了。

SVC_RUNNING:正在運行,這是service的狀態。

SVC_RESTARTING:等待重啓,這也是service的狀態。

SVC_CONSOLE:該service須要使用控制檯 。

SVC_CRITICAL:若是在規定時間內該service不斷重啓,則系統會重啓並進入恢復模式。

zygote沒有使用任何屬性,這代表它:會隨着class的處理自動啓動;

退出後會由init重啓;不使用控制檯;即便不斷重啓也不會致使系統進入恢復模式。

       */

       svc->flags |= SVC_ONESHOT;

       break;

    caseK_onrestart: //根據onrestart的內容,填充action結構體的內容

       nargs--;

       args++;

        kw= lookup_keyword(args[0]);

        ......

        //建立command結構體

       cmd = malloc(sizeof(*cmd) + sizeof(char*) * nargs);

       cmd->func = kw_func(kw);

       cmd->nargs = nargs;

       memcpy(cmd->args, args, sizeof(char*) * nargs);

        //把新建的command加入到雙向鏈表中。

       list_add_tail(&svc->onrestart.commands, &cmd->clist);

       break;

    ......

    caseK_socket: { //建立socket相關信息

       struct socketinfo *si;

        ......

        si= calloc(1, sizeof(*si));

        if(!si) {

           parse_error(state, "out of memory\n");

           break;

        }

       si->name = args[1]; //socket的名字

       si->type = args[2]; //socket的類型

       si->perm = strtoul(args[3], 0, 8); //socket的讀寫權限

        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]);

    }

}

parse_line_service將根據配置文件的內容填充service結構體,那麼,zygote解析完後會獲得什麼呢?圖3-1表示了zygote解析後的結果:

圖3-1  zygote解析結果示意圖

從上圖中可知:

·  service_list鏈表將解析後的service所有連接到了一塊兒,而且是一個雙向鏈表,前向節點用prev表示,後向節點用next表示。

·  socketinfo也是一個雙向鏈表,由於zygote只有一個socket,因此畫了一個虛框socket作爲鏈表的示範。

·  onrestart經過commands指向一個commands鏈表,zygote有三個commands。

zygote這個service解析完了,如今就是「萬事俱備,只欠東風」了。接下來要了解的是,init是如何控制service的。

3.2.3  init控制service

先看service是如何啓動的。

1.啓動zygote

init.rc中有這樣一句話:

#class_start是一個COMMAND,對應的函數爲do_class_start,很重要,切記。

 class_startdefault

class_start標示一個COMMAND,對應的處理函數爲do_class_start,它位於boot section的範圍內。爲何說它很重要呢?

還記得init進程中的四個執行階段嗎?當init進程執行到下面幾句話時,do_class_start就會被執行了。

//將bootsection節的command加入到執行隊列

action_for_each_trigger("boot",action_add_queue_tail);

//執行隊列裏的命令,class但是一個COMMAND,因此它對應的do_class_start會被執行。

drain_action_queue();

下面來看do_class_start函數:

[-->builtins.c]

int do_class_start(int nargs, char **args)

{

/*

args爲do_class_start的參數,init.rc中只有一個參數,就是default。

下面這個函數將從service_list中尋找classname爲」default」的service,而後

調用service_start_if_not_disabled函數。如今讀者明白了service結構體中

classname的做用了嗎?

*/

service_for_each_class(args[1],service_start_if_not_disabled);

return 0;

}

咱們已經知道,zygote這個service的classname的值就是「default」,因此會針對這個service調用service_start_if_not_disabled,這個函數的代碼是:

[-->parser.c]

static void service_start_if_not_disabled(structservice *svc)

{

if (!(svc->flags & SVC_DISABLED)) {

     service_start(svc,NULL); //zygote可沒有設置SVC_DISABLED

 }

}

service_start函數的代碼以下所示:

[-->init.c]

void service_start(struct service *svc, constchar *dynamic_args)

{

    structstat s;

    pid_tpid;

    intneeds_console;

    int n;

 

   svc->flags &= (~(SVC_DISABLED|SVC_RESTARTING));

   svc->time_started = 0;

   

    if(svc->flags & SVC_RUNNING) {

       return;//若是這個service已在運行,則不用處理

    }

  /*

service通常運行於另一個進程中,這個進程也是init的子進程,因此啓動service前須要判斷

對應的可執行文件是否存在,zygote對應的可執行文件是/system/bin/app_process

*/

    if(stat(svc->args[0], &s) != 0) {

      svc->flags |= SVC_DISABLED;

       return;

    }

    ......

   pid =fork(); //調用fork建立子進程

if(pid == 0) {

    //pid爲零,咱們在子進程中

       struct socketinfo *si;

       struct svcenvinfo *ei;

       char tmp[32];

       int fd, sz;

       

//獲得屬性存儲空間的信息並加到環境變量中,後面在屬性服務一節中會碰到使用它的地方。

       get_property_workspace(&fd, &sz);

       add_environment("ANDROID_PROPERTY_WORKSPACE", tmp);

        //添加環境變量信息

       for (ei = svc->envvars; ei; ei = ei->next)

           add_environment(ei->name, ei->value);

        //根據socketinfo建立socket

       for (si = svc->sockets; si; si = si->next) {

           int s = create_socket(si->name,

                                  !strcmp(si->type,"dgram") ?

                                  SOCK_DGRAM :SOCK_STREAM,

                                  si->perm,si->uid, si->gid);

           if (s >= 0) {

               //在環境變量中添加socket信息。

                publish_socket(si->name, s);

           }

        }

       ......//設置uid,gid等

     setpgid(0, getpid());

       if(!dynamic_args) {

        /*

執行/system/bin/app_process,這樣就進入到app_process的main函數中了。

fork、execve這兩個函數都是Linux系統上經常使用的系統調用。

        */

            if (execve(svc->args[0], (char**)svc->args, (char**) ENV) < 0) {

              ......

           }

        }else {

          ......

    }

 

   ......//父進程init的處理,設置service的信息,如啓動時間、進程號,以及狀態等。

   svc->time_started = gettime();

   svc->pid = pid;

   svc->flags |= SVC_RUNNING;

//每個service都有一個屬性,zygote的屬性爲init.svc.zygote,如今設置它的值爲running

   notify_service_state(svc->name, "running");

}

原來,zygote是經過fork和execv共同建立的!但service結構中的那個onrestart好像沒有派上用場,緣由何在?

2. 重啓zygote

根據名字,就可猜到onrestart應該是在zygote重啓時用的。下面先看在zygote死後,它的父進程init會有什麼動做:

[-->init.c]

static void sigchld_handler(int s)

{  //當子進程退出時,init的這個信號處理函數會被調用

   write(signal_fd, &s, 1); //往signal_fd write數據

}

signal_fd,就是在init中經過socketpair建立的兩個socket中的一個,既然會往這個signal_fd中發送數據,那麼另一個socket就必定能接收到,這樣就會致使init從poll函數中返回:

[-->init.rc::main函數代碼片段]

 nr =poll(ufds, fd_count, timeout);

 ......

 if(ufds[2].revents == POLLIN) {

   read(signal_recv_fd, tmp, sizeof(tmp));

       while (!wait_for_one_process(0))//調用wait_for_one_process函數處理

         ;

       continue;

 }

 ......

//直接看這個wait_for_one_process函數:

static int wait_for_one_process(int block)

{

    pid_tpid;

    intstatus;

    structservice *svc;

    structsocketinfo *si;

    time_tnow;

    structlistnode *node;

    structcommand *cmd;

 

while( (pid = waitpid(-1, &status, block ? 0 : WNOHANG)) == -1 &&

errno == EINTR );

    if(pid <= 0) return -1;

    //找到死掉的那個service,如今應該找到了表明zygote的那個service。

svc = service_find_by_pid(pid);

   ......

 

if(!(svc->flags & SVC_ONESHOT)) {

    //殺掉zygote建立的全部子進程,這就是zygote死後,Java世界崩潰的緣由。

       kill(-pid, SIGKILL);

   }

 

    //清理socket信息,不清楚的讀者能夠經過命令man 7 AF_UNIX查詢一下相關知識。

    for(si = svc->sockets; si; si = si->next) {

       char tmp[128];

       snprintf(tmp, sizeof(tmp), ANDROID_SOCKET_DIR"/%s",si->name);

        unlink(tmp);

    }

 

   svc->pid = 0;

   svc->flags &= (~SVC_RUNNING);

 

   if(svc->flags & SVC_ONESHOT) {

       svc->flags |= SVC_DISABLED;

    }

   ......

now= gettime();

/*

若是設置了SVC_CRITICAL標示,則4分鐘內該服務重啓次數不能超過4次,不然

機器會重啓進入recovery模式。根據init.rc的配置,只有servicemanager進程

享有此種待遇。

*/

    if(svc->flags & SVC_CRITICAL) {

        if(svc->time_crashed + CRITICAL_CRASH_WINDOW >= now) {

           if (++svc->nr_crashed > CRITICAL_CRASH_THRESHOLD) {

              ......

               sync();

               __reboot(LINUX_REBOOT_MAGIC1,LINUX_REBOOT_MAGIC2,

                        LINUX_REBOOT_CMD_RESTART2, "recovery");

               return 0;

           }

        }else {

           svc->time_crashed = now;

           svc->nr_crashed = 1;

        }

    }

 

   svc->flags |= SVC_RESTARTING;

//設置標示爲SVC_RESTARTING,而後執行該service onrestart中的COMMAND,這些內容就

//很是簡單了,讀者能夠自行學習。

   list_for_each(node, &svc->onrestart.commands) {

       cmd = node_to_item(node, struct command, clist);

       cmd->func(cmd->nargs, cmd->args);

}

//設置init.svc.zygote的值爲restarting。

   notify_service_state(svc->name, "restarting");

    return0;

}

經過上面的代碼,可知道onrestart的做用了,但zygote自己又在哪裏重啓的呢?答案就在下面的代碼中:

[-->init.c::main函數代碼片段]

for(;;) {

       int nr, i, timeout = -1;

       for (i = 0; i < fd_count; i++)

           ufds[i].revents = 0;

       drain_action_queue(); //poll函數返回後,會進入下一輪的循環

       restart_processes(); //這裏會重啓全部flag標誌爲SVC_RESTARTING的service。

       ......

}

這樣,zygote又回來了!

3.2.4  屬性服務

咱們知道,Windows平臺上有一個叫註冊表的東西。註冊表能夠存儲一些相似key/value的鍵值對。通常而言,系統或某些應用程序會把本身的一些屬性存儲在註冊表中,即便下次系統重啓或應用程序重啓,它還可以根據以前在註冊表中設置的屬性,進行相應的初始化工做。Android平臺也提供了一個類型機制,可稱之爲屬性服務(property service)。應用程序可經過這個屬性機制,查詢或設置屬性。讀者能夠用adb shell登陸到真機或模擬器上,而後用getprop命令查看當前系統中有哪些屬性。即如個人HTC G7測試結果,如圖3-2所示:(圖中只顯示了部分屬性)

圖3-2  HTC G7屬性示意圖

這個屬性服務是怎麼實現的呢?下面來看代碼,其中與init.c和屬性服務有關的代碼有下面兩行:

property_init();

property_set_fd = start_property_service();

分別來看看它們。

1. 屬性服務初始化

(1)建立存儲空間

先看property_init函數,代碼以下所示:

[-->property_service.c]

void property_init(void)

{

init_property_area();//初始化屬性存儲區域

//加載default.prop文件

   load_properties_from_file(PROP_PATH_RAMDISK_DEFAULT);

}

在properyty_init函數中,先調用init_property_area函數,建立一塊用於存儲屬性的存儲區域,而後加載default.prop文件中的內容。再看init_property_area是如何工做的,它的代碼以下所示:

[-->property_service.c]

static int init_property_area(void)

{

   prop_area *pa;

 

   if(pa_info_array)

       return -1;

/*

初始化存儲空間,PA_SIZE是這塊存儲空間的總大小,爲32768字節,pa_workspace

爲workspace類型的結構體,下面是它的定義:

typedef struct {

    void *data;   //存儲空間的起始地址

    size_tsize;  //存儲空間的大小

    int fd;   //共享內存的文件描述符

} workspace;

init_workspace函數調用Android系統提供的ashmem_create_region函數建立一塊

共享內存。關於共享內存的知識咱們在第7章會接觸,這裏,只需把它當作一塊普通的內存就

能夠了。

    */

   if(init_workspace(&pa_workspace, PA_SIZE))

       return -1;

 

   fcntl(pa_workspace.fd, F_SETFD, FD_CLOEXEC);

  

//在32768個字節的存儲空間中,有PA_INFO_START(1024)個字節用來存儲頭部信息

   pa_info_array = (void*) (((char*) pa_workspace.data) + PA_INFO_START);

 

    pa =pa_workspace.data;

   memset(pa, 0, PA_SIZE);

   pa->magic = PROP_AREA_MAGIC;

   pa->version = PROP_AREA_VERSION;

//__system_property_area__這個變量由bionic libc庫輸出,有什麼用呢?

       __system_property_area__ = pa;

 

    return0;

}

上面的內容比較簡單,不過最後的賦值語句但是大有來頭。__system_property_area__是bionic libc庫中輸出的一個變量,爲何這裏要給它賦值呢?

原來,雖然屬性區域是由init進程建立,但Android系統但願其餘進程也能讀取這塊內存裏的東西。爲作到這一點,它便作了如下兩項工做:

·  把屬性區域建立在共享內存上,而共享內存是能夠跨進程的。這一點,已經在上面的代碼中見到了,init_workspace函數內部將建立這個共享內存。

·  如何讓其餘進程知道這個共享內存呢?Android利用了gcc的constructor屬性,這個屬性指明瞭一個__libc_prenit函數,當bionic libc庫被加載時,將自動調用這個__libc_prenit,這個函數內部就將完成共享內存到本地進程的映射工做。

(2)客戶端進程獲取存儲空間

關於上面的內容,來看相關代碼:

[-->libc_init_dynamic.c]

//constructor屬性指示加載器加載該庫後,首先調用__libc_prenit函數。這一點和Windows上

//動態庫的DllMain函數相似

void __attribute__((constructor))__libc_prenit(void);

void __libc_prenit(void)

{

    ......

     __libc_init_common(elfdata); //調用這個函數

    ......

}

__libc_init_common函數爲:

[-->libc_init_common.c]

void __libc_init_common(uintptr_t *elfdata)

{

   ......

   __system_properties_init();//初始化客戶端的屬性存儲區域

}

[-->system_properties.c]

int __system_properties_init(void)

{

   prop_area *pa;

    int s,fd;

   unsigned sz;

    char*env;

 

.....

//還記得在啓動zygote一節中提到的添加環境變量的地方嗎?屬性存儲區域的相關信息

//就是在那兒添加的,這裏須要取出來使用了。

    env =getenv("ANDROID_PROPERTY_WORKSPACE");

    //取出屬性存儲區域的文件描述符。關於共享內存的知識,第7章中將會進行介紹。

    fd =atoi(env);

    env =strchr(env, ',');

    if(!env) {

       return -1;

    }

    sz =atoi(env + 1);

//映射init建立的那塊內存到本地進程空間,這樣本地進程就可使用這塊共享內存了。

//注意,映射的時候指定了PROT_READ屬性,因此客戶端進程只能讀屬性,而不能設置屬性。

    pa =mmap(0, sz, PROT_READ, MAP_SHARED, fd, 0);

   

    if(pa== MAP_FAILED) {

       return -1;

    }

 

   if((pa->magic != PROP_AREA_MAGIC) || (pa->version !=PROP_AREA_VERSION)) {

       munmap(pa, sz);

       return -1;

    }

 

   __system_property_area__ = pa;

    return0;

}

上面代碼中不少地方和共享內存有關,在第7章中會對與共享內存有關問題進行介紹,讀者也可先行學習有關共享內存的知識。

總之,經過這種方式,客戶端進程能夠直接讀取屬性空間,但沒有權限設置屬性。客戶端進程又是如何設置屬性呢?

2. 啓動屬性服務器

(1)啓動屬性服務器

init進程會啓動一個屬性服務器,而客戶端只能經過和屬性服務器交互才能設置屬性。先來看屬性服務器的內容,它由start_property_service函數啓動,代碼以下所示:

[-->Property_servie.c]

int start_property_service(void)

{

    intfd;

  

   /*

       加載屬性文件,其實就是解析這些文件中的屬性,而後把它設置到屬性空間中去。Android系統

      一共提供了四個存儲屬性的文件,它們分別是:

     #definePROP_PATH_RAMDISK_DEFAULT "/default.prop"

#define PROP_PATH_SYSTEM_BUILD     "/system/build.prop"

#define PROP_PATH_SYSTEM_DEFAULT   "/system/default.prop"

#define PROP_PATH_LOCAL_OVERRIDE   "/data/local.prop"

*/

  

   load_properties_from_file(PROP_PATH_SYSTEM_BUILD);

   load_properties_from_file(PROP_PATH_SYSTEM_DEFAULT);

load_properties_from_file(PROP_PATH_LOCAL_OVERRIDE);

//有一些屬性是須要保存到永久介質上的,這些屬性文件則由下面這個函數加載,這些文件

//存儲在/data/property目錄下,而且這些文件的文件名必須以persist.開頭。這個函數

//很簡單,讀者可自行研究。

    load_persistent_properties();

   //建立一個socket,用於IPC通訊。

    fd =create_socket(PROP_SERVICE_NAME, SOCK_STREAM, 0666, 0, 0);

    if(fd< 0) return -1;

   fcntl(fd, F_SETFD, FD_CLOEXEC);

   fcntl(fd, F_SETFL, O_NONBLOCK);

   listen(fd, 8);

    returnfd;

}

屬性服務建立了一個用來接收請求的socket,可這個請求在哪裏被處理呢?事實上,在init中的for循環那裏已經進行相關處理了。

(2)處理設置屬性請求

接收請求的地方是在init進程中,代碼以下所示:

[-->init.c::main函數片段]

if (ufds[1].revents == POLLIN)

           handle_property_set_fd(property_set_fd);

當屬性服務器收到客戶端請求時,init會調用handle_property_set_fd進行處理。這個函數的代碼以下所示:

[-->property_service.c]

void handle_property_set_fd(int fd)

{

   prop_msg msg;

    int s;

    int r;

    intres;

    structucred cr;

    structsockaddr_un addr;

   socklen_t addr_size = sizeof(addr);

   socklen_t cr_size = sizeof(cr);

    //先接收TCP鏈接

    if ((s= accept(fd, (struct sockaddr *) &addr, &addr_size)) < 0) {

       return;

    }

 

    //取出客戶端進程的權限等屬性。

    if(getsockopt(s, SOL_SOCKET, SO_PEERCRED, &cr, &cr_size) < 0) {

        ......

       return;

    }

   //接收請求數據

    r = recv(s,&msg, sizeof(msg), 0);

   close(s);

    ......

 

   switch(msg.cmd) {

    casePROP_MSG_SETPROP:

       msg.name[PROP_NAME_MAX-1] = 0;

       msg.value[PROP_VALUE_MAX-1] = 0;

        /*

若是是ctl開頭的消息,則認爲是控制消息,控制消息用來執行一些命令,例如用

adb shell登陸後,輸入setprop ctl.start bootanim就能夠查看開機動畫了,

關閉的話就輸入setpropctl.stop bootanim,是否是頗有意思呢?

        */

       if(memcmp(msg.name,"ctl.",4) == 0) {

           if (check_control_perms(msg.value, cr.uid, cr.gid)) {

               handle_control_message((char*) msg.name + 4, (char*) msg.value);

           }

           ......

        }else {

           //檢查客戶端進程是否有足夠的權限

           if (check_perms(msg.name, cr.uid, cr.gid)) {

               //而後調用property_set設置。

               property_set((char*) msg.name, (char*) msg.value);

           }

           ......

        }

       break;

 

   default:

       break;

    }

}

當客戶端的權限知足要求時,init就調用property_set進行相關處理,這個函數比較簡單,代碼以下所示:

[-->property_service.c]

int property_set(const char *name, const char*value)

{

   prop_area *pa;

   prop_info *pi;

 

    intnamelen = strlen(name);

    intvaluelen = strlen(value);

    ......

    //從屬性存儲空間中尋找是否已經存在該屬性

    pi =(prop_info*) __system_property_find(name);

 

if(pi!= 0) {

    //若是屬性名以ro.開頭,則表示是隻讀的,不能設置,因此直接返回。

       if(!strncmp(name, "ro.", 3)) return -1;

 

        pa= __system_property_area__;

        //更新該屬性的值

       update_prop_info(pi, value, valuelen);

       pa->serial++;

       __futex_wake(&pa->serial, INT32_MAX);

}else {

   //若是沒有找到對應的屬性,則認爲是增長屬性,因此須要新建立一項。注意,Android支持

   //最多247項屬性,若是目前屬性的存儲空間中已經有247項,則直接返回。

        pa= __system_property_area__;

       if(pa->count == PA_COUNT_MAX) return -1;

 

        pi= pa_info_array + pa->count;

       pi->serial = (valuelen << 24);

       memcpy(pi->name, name, namelen + 1);

        memcpy(pi->value, value, valuelen +1);

 

       pa->toc[pa->count] =

           (namelen << 24) | (((unsigned) pi) - ((unsigned) pa));

 

       pa->count++;

       pa->serial++;

       __futex_wake(&pa->serial, INT32_MAX);

    }

    //有一些特殊的屬性須要特殊處理,這裏,主要是以net.change開頭的屬性。

    if(strncmp("net.", name, strlen("net.")) == 0)  {

        if(strcmp("net.change", name) == 0) {

           return 0;

        }

       property_set("net.change", name);

    } elseif (persistent_properties_loaded &&

       strncmp("persist.", name,strlen("persist.")) == 0) {

       //若是屬性名以persist.開頭,則須要把這些值寫到對應文件中去。

      write_persistent_property(name, value);

}

/*

還記得init.rc中的下面這句話嗎?

on property:persist.service.adb.enable=1

         startadbd

當persist.service.adb.enable屬性置爲1後,就會執行start adbd這個command,

這是經過property_changed函數來完成的,它很是簡單,讀者能夠本身閱讀。

*/

   property_changed(name, value);

    return0;

}

好,屬性服務端的工做已經瞭解了,下面看客戶端是如何設置屬性的。

(3)客戶端發送請求

客戶端經過property_set發送請求,property_set由libcutils庫提供,代碼以下所示:

[-->properties.c]

int property_set(const char *key, const char*value)

{

   prop_msg msg;

   unsigned resp;

 

   ......

   msg.cmd = PROP_MSG_SETPROP;//設置消息碼爲PROP_MSG_SETPROP。

   strcpy((char*) msg.name, key);

   strcpy((char*) msg.value, value);

    //發送請求

    returnsend_prop_msg(&msg);

}

 

static int send_prop_msg(prop_msg *msg)

{

    int s;

    int r;

    //創建和屬性服務器的socket鏈接

    s =socket_local_client(PROP_SERVICE_NAME,

                           ANDROID_SOCKET_NAMESPACE_RESERVED,

                            SOCK_STREAM);

    if(s< 0) return -1;

    //經過socket發送出去

   while((r = send(s, msg, sizeof(prop_msg), 0)) < 0) {

       if((errno == EINTR) || (errno == EAGAIN)) continue;

       break;

    }

 

    if(r== sizeof(prop_msg)) {

        r= 0;

    } else{

        r= -1;

    }

 

   close(s);

    returnr;

}

至此,屬性服務器就介紹完了。整體來講,還算比較簡單。

3.3  本章小結

本章講解了init進程如何解析zygote,以及屬性服務器的工做原理,旨在幫助讀者認識這個天字號第一進程。從總體來講,init.rc的解析難度相對最大。相信讀者經過以上實例分析,已經理解了init.rc的解析原理。另外,inti涉及不少和Linux系統相關的知識,有興趣的讀者能夠自行研究。

相關文章
相關標籤/搜索