Android Binder機制之 ServiceManager的啟動
Android Binder機制的ServiceManager
對於Android 來說，Binder程序間的通訊機制幾乎無處不在，可以說是整個Android系統中各個元件之間互動的靈魂。所以，想要深入的理解Android 中程序間通訊的機制，還是需要對Binder機制有一個深入的研究的。
Binder機制很複雜，設計到的東西特別多，很難一下將這些東西說清楚，到期該從何說起呢？不防就從Binder服務的管理者ServiceManger開始說起吧。
servicemanager是一個獨立的程序，在Android系統啟動的時候有init.rc指令碼，啟動指令碼如下：
service servicemanager /system/bin/servicemanager class core user system group system critical onerestart zygote onerestart media onerestart surfaceflinger ...
有必要對上面的啟動指令碼進行解釋一下子：
service servicemanager 表示該程序是以服務的形式執行的
class core 表示這個是核心服務
critical 表示很重要
onerestart zygote 表示該服務重啟，需要重啟zygote程序(後面的含義是一樣的)。
Android 系統啟動servicemanager之後，是讓它不停地幹活的，具體幹什麼活呢？既然是名字叫做ServiceManager，那麼它既是用來管理系統service的，具體來說有兩個功能1. addService ,即註冊一個服務到系統中 2. getService，即返回服務的代理物件。對於這個兩個功能的實現，且看servicemanager的main函式
程式碼路徑為：frameworks/base/cmds/servicemanager/service_manager.c
int main(int argc, char **argv) { struct binder_state *bs; //ServiceManager的描述 bs = binder_open(128*1024); //關鍵點1 if (!bs) { ALOGE("failed to open binder driver\n"); return -1; } if (binder_become_context_manager(bs)) { //關鍵點2 ALOGE("cannot become context manager (%s)\n", strerror(errno)); return -1; }
... //中間為selinux相關程式碼, 和主題無關
//進入Binder 的loop中
binder_loop(bs, svcmgr_handler); //關鍵點3
return 0;
}
對於main函式中標記的關鍵點做出解釋:
1. binder_open:
總的來說binder_open 幹了三件事情：1. 開啟/dev/binder 獲得控制代碼值 2. 通過ioctl 查詢Binder版本 3.對映地址空間
且看原始碼:
struct binder_state *binder_open(size_t mapsize)
{
struct binder_state *bs;
struct binder_version vers;
bs = malloc(sizeof(*bs));
if (!bs) {
errno = ENOMEM;
return NULL;
}
//1. 開啟驅動
bs->fd = open("/dev/binder", O_RDWR);
if (bs->fd < 0) {
fprintf(stderr,"binder: cannot open device (%s)\n",
strerror(errno));
goto fail_open;
}
//2. ioctl
if ((ioctl(bs->fd, BINDER_VERSION, &vers) == -1) ||
(vers.protocol_version != BINDER_CURRENT_PROTOCOL_VERSION)) {
fprintf(stderr,
"binder: kernel driver version (%d) differs from user space version (%d)\n",
vers.protocol_version, BINDER_CURRENT_PROTOCOL_VERSION);
goto fail_open;
}
//通過mmap將空間對映到使用者空間
bs->mapsize = mapsize;
bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);
if (bs->mapped == MAP_FAILED) {
fprintf(stderr,"binder: cannot map device (%s)\n",
strerror(errno));
goto fail_map;
}
return bs;
fail_map:
close(bs->fd);
fail_open:
free(bs);
return NULL;
}2. binder_become_context_manager
int binder_become_context_manager(struct binder_state *bs)
{
return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
}上面程式碼比較明顯，即是通過ioctl來讓servicemanger成為服務管理中心，並設定handle為0(這個0很重要，後續分析)
3. binder_loop
servicemanager將在這裡完成系統交給它的使命：對service進行註冊和返回其代理物件。
binder_loop(bs, svcmgr_handler); //bs攜帶者servicemanager的資訊，svcmgr_handler則是一個回撥函式void binder_loop(struct binder_state *bs, binder_handler func)
{
int res;
struct binder_write_read bwr;
uint32_t readbuf[32];
bwr.write_size = 0;
bwr.write_consumed = 0;
bwr.write_buffer = 0;
readbuf[0] = BC_ENTER_LOOPER;
binder_write(bs, readbuf, sizeof(uint32_t)); //告知binder驅動，servicemanager進入loop迴圈
for (;;) {
bwr.read_size = sizeof(readbuf);
bwr.read_consumed = 0;
bwr.read_buffer = (uintptr_t) readbuf;
res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr); //從binder驅動中讀取資料
if (res < 0) {
ALOGE("binder_loop: ioctl failed (%s)\n", strerror(errno));
break;
}
res = binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func); //解析資料，並傳遞func回撥函式
if (res == 0) {
ALOGE("binder_loop: unexpected reply?!\n");
break;
}
if (res < 0) {
ALOGE("binder_loop: io error %d %s\n", res, strerror(errno));
break;
}
}
}上面的binder_loop迴圈會不斷的通過ioctl從binder驅動中讀取資料，並解析執行。在binder_parse中會解析出從binder驅動中讀取的命令，然後通過servicemanager中註冊的回撥函式svcmgr_handler來執行具體的指令
int svcmgr_handler(struct binder_state *bs,
struct binder_transaction_data *txn,
struct binder_io *msg,
struct binder_io *reply)
{
struct svcinfo *si;
uint16_t *s;
size_t len;
uint32_t handle;
uint32_t strict_policy;
int allow_isolated;
//一些條件判定的邏輯操作,這裡省略
switch(txn->code) {
case SVC_MGR_GET_SERVICE:
case SVC_MGR_CHECK_SERVICE: //Client元件請求獲取Service代理物件的請求
s = bio_get_string16(msg, &len);
if (s == NULL) {
return -1;
}
handle = do_find_service(bs, s, len, txn->sender_euid, txn->sender_pid); //執行getService操作
if (!handle)
break;
bio_put_ref(reply, handle); //將handle寫入驅動
return 0;
case SVC_MGR_ADD_SERVICE: //Service請求註冊到ServiceManager中
s = bio_get_string16(msg, &len);
if (s == NULL) {
return -1;
}
handle = bio_get_ref(msg);
allow_isolated = bio_get_uint32(msg) ? 1 : 0;
if (do_add_service(bs, s, len, handle, txn->sender_euid, //執行addService的操作
allow_isolated, txn->sender_pid))
return -1;
break;
case SVC_MGR_LIST_SERVICES: { //查詢所有的service操作
uint32_t n = bio_get_uint32(msg);
if (!svc_can_list(txn->sender_pid)) {
ALOGE("list_service() uid=%d - PERMISSION DENIED\n",
txn->sender_euid);
return -1;
}
si = svclist;
while ((n-- > 0) && si)
si = si->next;
if (si) {
bio_put_string16(reply, si->name);
return 0;
}
return -1;
}
default:
ALOGE("unknown code %d\n", txn->code);
return -1;
}
bio_put_uint32(reply, 0);
return 0;
}
首先看addService的請求操作
int do_add_service(struct binder_state *bs,
const uint16_t *s, size_t len,
uint32_t handle, uid_t uid, int allow_isolated,
pid_t spid)
{//servicemanager中通過一個連結串列來維護所有註冊進來的service元件
struct svcinfo *si; //svcinfo 是service連結串列的一個節點
//ALOGI("add_service('%s',%x,%s) uid=%d\n", str8(s, len), handle,
// allow_isolated ? "allow_isolated" : "!allow_isolated", uid);
if (!handle || (len == 0) || (len > 127))
return -1;
if (!svc_can_register(s, len, spid, uid)) { //檢測該service是否可以進行註冊到ServiceManager
ALOGE("add_service('%s',%x) uid=%d - PERMISSION DENIED\n",
str8(s, len), handle, uid);
return -1;
}
si = find_svc(s, len);
if (si) { //如果已經註冊了，將不再註冊
if (si->handle) {
ALOGE("add_service('%s',%x) uid=%d - ALREADY REGISTERED, OVERRIDE\n",
str8(s, len), handle, uid);
svcinfo_death(bs, si);
}
si->handle = handle;
} else { //開始將service註冊到ServiceManager中
si = malloc(sizeof(*si) + (len + 1) * sizeof(uint16_t));
if (!si) {
ALOGE("add_service('%s',%x) uid=%d - OUT OF MEMORY\n",
str8(s, len), handle, uid);
return -1;
}
si->handle = handle;
si->len = len;
memcpy(si->name, s, (len + 1) * sizeof(uint16_t));
si->name[len] = '\0';
si->death.func = (void*) svcinfo_death;
si->death.ptr = si;
si->allow_isolated = allow_isolated;
si->next = svclist;
svclist = si;
}
binder_acquire(bs, handle); //將service註冊到binder驅動中, 通過binder_write 將命令寫入binder驅動
binder_link_to_death(bs, handle, &si->death);
return 0;
}getService和addService很相似，這裡就不再貼程式碼了。 getService時也是通過查詢ServiceManager維護的連結串列，然後返回其handle。好像getService時沒有和binder驅動進行互動(但是binder驅動的引用計數和這個也關係的)。
到這裡ServiceManager進行的啟動大的大致過程講完了，但是這裡還有很多細節問題的問題是沒有說到的。親愛的讀者，你有沒有發現，ServiceManager程序確實是實現了對service元件的管理，ServiceManager程序現在還沒有提供任何進行addService和getService的介面。在Native層要註冊addService或者getSerivce是通過IServiceManager介面進行的，IServiceManager介面到底是怎麼和servicemanager程序之間建立聯絡的。以及，當前僅僅介紹了servicemanager程序啟動，還沒有真正的進入binder的世界。
未完，待續。。。