因爲《深刻理解Android 卷一》和《深刻理解Android卷二》再也不出版,而知識的傳播不該該由於紙質媒介的問題而中斷,因此我將在OSC博客中全文轉發這兩本書的所有內容。 node
本章主要內容 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
init是一個進程,確切地說,它是Linux系統中用戶空間的第一個進程。因爲Android是基於Linux內核的,因此init也是Android系統中用戶空間的第一個進程,它的進程號是1。做爲天字第一號的進程,init被賦予了不少極其重要的工做職責,本章將關注其中兩個比較重要的職責:
· init進程負責建立系統中的幾個關鍵進程,尤爲是下一章要介紹的Zygote,它更是Java世界的開創者。那麼,init進程是如何建立Zygote的呢?
· Android系統有不少屬性,因而init就提供了一個property service(屬性服務)來管理它們。那麼這個屬性服務是怎麼工做的呢?
如上所述,本章將經過下面兩方面內容來分析init:
· init如何建立zygote。
· 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和來自屬性服務器相關的事情。
精簡工做流程,是之後分析代碼時經常使用的方法。讀者在分析代碼的過程當中,也可以使用這種方法。
根據上面的代碼可知,在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,仍是先到代碼中去尋找答案。
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的內容。
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是如何解析的。
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的。
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的做用了呢?立刻就來看它們。
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。
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的。
先看service是如何啓動的。
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好像沒有派上用場,緣由何在?
根據名字,就可猜到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又回來了!
咱們知道,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();
分別來看看它們。
先看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,這個函數內部就將完成共享內存到本地進程的映射工做。
關於上面的內容,來看相關代碼:
[-->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章中會對與共享內存有關問題進行介紹,讀者也可先行學習有關共享內存的知識。
總之,經過這種方式,客戶端進程能夠直接讀取屬性空間,但沒有權限設置屬性。客戶端進程又是如何設置屬性呢?
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循環那裏已經進行相關處理了。
接收請求的地方是在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;
}
好,屬性服務端的工做已經瞭解了,下面看客戶端是如何設置屬性的。
客戶端經過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;
}
至此,屬性服務器就介紹完了。整體來講,還算比較簡單。
本章講解了init進程如何解析zygote,以及屬性服務器的工做原理,旨在幫助讀者認識這個天字號第一進程。從總體來講,init.rc的解析難度相對最大。相信讀者經過以上實例分析,已經理解了init.rc的解析原理。另外,inti涉及不少和Linux系統相關的知識,有興趣的讀者能夠自行研究。