Android Binder機制學習總結(三)-ServiceManager部分
接上篇的內(nèi)容，分析下ServiceManager的實現(xiàn)。
??????? ServiceManager的實現(xiàn)位于：
??????? 4.2：/frameworks/base/cmds/servicemanager/
??????? 4.3：frameworks/native/cmds/servicemanager/
ServiceManager的啟動 ? ? ? ? ServiceManager的的啟動由init進程根據(jù)init.rc文件的配置執(zhí)行，從時間順序上來說，ServiceManager的啟動優(yōu)先于Zygote進程
service?servicemanager?/system/bin/servicemanager ????class?core????????????//core類服務 ????user?system???????????//用戶名 ????group?system??????????//用戶組 ????critical??????????????//重要service，?如果4分鐘內(nèi)crush4次以上，則重啟系統(tǒng)并進入recovery ????onrestart?restart?zygote??????????//servicemanager重啟以后，自動重啟zygote ????onrestart?restart?media???????????//同上 ????onrestart?restart?surfaceflinger??//同上 ????onrestart?restart?drm?????????????//同上
? ? ? ? ServiceManager是一個可執(zhí)行文件,所以，我們從main函數(shù)看起（frameworks/base/cmds/servicemanager/servicemanager.c)：
int?main(int?argc,?char?**argv)
{
????struct?binder_state?*bs;
????void?*svcmgr?=?BINDER_SERVICE_MANAGER;
????bs?=?binder_open(128*1024);
????if?(binder_become_context_manager(bs))?{
????????ALOGE("cannot?become?context?manager?(%s)n",?strerror(errno));
????????return?-1;
????}
????svcmgr_handle?=?svcmgr;
????binder_loop(bs,?svcmgr_handler);//svcmgr_handle為具體的請求處理邏輯
????return?0;
}? ? ? ? 簡單來說，ServiceManager的啟動分為三個步驟： 打開dev/binder，并創(chuàng)建binder緩沖區(qū)注冊當前進程為上下文管理者（ServiceManager)進入處理循環(huán)，等待Service/Client的請求 步驟一 ? ? ? ? 步驟一，由binder_open函數(shù)實現(xiàn)（frameworks/base/cmds/servicemanager/binder.c):
struct?binder_state?*binder_open(unsigned?mapsize)
{
????struct?binder_state?*bs;
????bs?=?malloc(sizeof(*bs));
????if?(!bs)?{
????????errno?=?ENOMEM;
????????return?0;
????}
????bs->fd?=?open("/dev/binder",?O_RDWR);//上一節(jié)講過，這里會轉入內(nèi)核態(tài)，執(zhí)行binder_open,創(chuàng)建binder_proc
????if?(bs->fd?<?0)?{
????????fprintf(stderr,"binder:?cannot?open?device?(%s)n",
????????????????strerror(errno));
????????goto?fail_open;
????}
????bs->mapsize?=?mapsize;//mapsize?=?128KB
????bs->mapped?=?mmap(NULL,?mapsize,?PROT_READ,?MAP_PRIVATE,?bs->fd,?0);//上一節(jié)講過，這里會轉入內(nèi)核態(tài)，執(zhí)行binder_mmap
????????????????????????????????????????????????????????????????????????//在內(nèi)核態(tài)創(chuàng)建相同size的緩沖區(qū)，并分配第一個物理頁面，計算內(nèi)核緩沖區(qū)地址和用戶緩沖區(qū)地址的偏移量
????if?(bs->mapped?==?MAP_FAILED)?{
????????fprintf(stderr,"binder:?cannot?map?device?(%s)n",
????????????????strerror(errno));
????????goto?fail_map;
????}
????????/*?TODO:?check?version?*/
????return?bs;
fail_map:
????close(bs->fd);
fail_open:
????free(bs);
????return?0;
}? ? ? ? 如果上一節(jié)binder driver部分的內(nèi)容有比較好的理解的話，這邊的代碼應該比較好理解的，順便看看binder_state的實現(xiàn)：
struct?binder_state
{
????int?fd;
????void?*mapped;
????unsigned?mapsize;
};步驟二 ? ? ? ? 步驟二，由binder_become_context_manager函數(shù)實現(xiàn)：
int?binder_become_context_manager(struct?binder_state?*bs)
{
????return?ioctl(bs->fd,?BINDER_SET_CONTEXT_MGR,?0);
}? ? ? ? 灰常簡單的實現(xiàn)，有木有? 讓我們來回憶一下，上一節(jié)的內(nèi)容，ioctl的調用會轉入到binder driver的binder_ioctl函數(shù)來處理BINDER_SET_CONTEXT_MGR:
????????case?BINDER_SET_CONTEXT_MGR:
if?(binder_context_mgr_node?!=?NULL)?{
printk(KERN_ERR?"binder:?BINDER_SET_CONTEXT_MGR?already?setn");
ret?=?-EBUSY;
goto?err;
}
ret?=?security_binder_set_context_mgr(proc->tsk);
if?(ret?<?0)
goto?err;
if?(binder_context_mgr_uid?!=?-1)?{
if?(binder_context_mgr_uid?!=?current->cred->euid)?{
printk(KERN_ERR?"binder:?BINDER_SET_"
???????"CONTEXT_MGR?bad?uid?%d?!=?%dn",
???????current->cred->euid,
???????binder_context_mgr_uid);
ret?=?-EPERM;
goto?err;
}
}?else
binder_context_mgr_uid?=?current->cred->euid;
binder_context_mgr_node?=?binder_new_node(proc,?NULL,?NULL);//binder_context_mgr_node->proc?=?servicemanager
if?(binder_context_mgr_node?==?NULL)?{
ret?=?-ENOMEM;
goto?err;
}
binder_context_mgr_node->local_weak_refs++;
binder_context_mgr_node->local_strong_refs++;
binder_context_mgr_node->has_strong_ref?=?1;
binder_context_mgr_node->has_weak_ref?=?1;
break;? ? ? ? 忽略安全檢查等代碼，上面的代碼就是設定了全局變量binder_context_mgr_node，并增加引用計數(shù)。 步驟三 ? ? ? ? 處理循環(huán)的實現(xiàn)在binder_loop函數(shù)中：
void?binder_loop(struct?binder_state?*bs,?binder_handler?func)
{
????int?res;
????struct?binder_write_read?bwr;
????unsigned?readbuf[32];
????bwr.write_size?=?0;
????bwr.write_consumed?=?0;
????bwr.write_buffer?=?0;
????
????readbuf[0]?=?BC_ENTER_LOOPER;
????binder_write(bs,?readbuf,?sizeof(unsigned));//binder?driver會通過binder_thread_write函數(shù)處理BC_ENTER_LOOPER指令
????for?(;;)?{
????????bwr.read_size?=?sizeof(readbuf);
????????bwr.read_consumed?=?0;
????????bwr.read_buffer?=?(unsigned)?readbuf;
????????res?=?ioctl(bs->fd,?BINDER_WRITE_READ,?&bwr);//讀取client/service的請求
????????if?(res?<?0)?{
????????????ALOGE("binder_loop:?ioctl?failed?(%s)n",?strerror(errno));
????????????break;
????????}
????????res?=?binder_parse(bs,?0,?readbuf,?bwr.read_consumed,?func);//處理請求
????????if?(res?==?0)?{
????????????ALOGE("binder_loop:?unexpected?reply?!n");
????????????break;
????????}
????????if?(res?<?0)?{
????????????ALOGE("binder_loop:?io?error?%d?%sn",?res,?strerror(errno));
????????????break;
????????}
????}
}ServiceManager客戶端代理 ? ? ? ? ServiceManager運行在自己的進程中，為了向Client/Service進程提供服務，ServiceManager為自己準備了客戶端代理，方便Client/Service調用。 IServiceManager和BpServiceManager ? ? ? ? IServiceManager是ServiceManager在native層的接口（framework/native/include/binder/IServiceManager.h）：
class?IServiceManager?:?public?IInterface
{
public:
????DECLARE_META_INTERFACE(ServiceManager);
????/**
?????*?Retrieve?an?existing?service,?blocking?for?a?few?seconds
?????*?if?it?doesn't?yet?exist.
?????*/
????virtual?spgetService(?const?String16&?name)?const?=?0;
????/**
?????*?Retrieve?an?existing?service,?non-blocking.
?????*/
????virtual?spcheckService(?const?String16&?name)?const?=?0;
????/**
?????*?Register?a?service.
?????*/
????virtual?status_t????????????addService(?const?String16&?name,
????????????????????????????????????????????const?sp&?service,
????????????????????????????????????????????bool?allowIsolated?=?false)?=?0;
????/**
?????*?Return?list?of?all?existing?services.
?????*/
????virtual?VectorlistServices()?=?0;
????enum?{
????????GET_SERVICE_TRANSACTION?=?IBinder::FIRST_CALL_TRANSACTION,
????????CHECK_SERVICE_TRANSACTION,
????????ADD_SERVICE_TRANSACTION,
????????LIST_SERVICES_TRANSACTION,
????};
};? ? ? ? 從接口中，我們看到SeviceManager提供了4個功能： getService，同checkServicecheckService，供Client獲取Service的binderaddService, 供Service注冊binderlistService，用于枚舉所有已經(jīng)注冊的binder ? ? ? ? 而BpServiceManager是IServiceManager的一個子類，提供了IServiceManager的實現(xiàn)（frameworks/native/libs/binder/IServiceManager.cpp)：
class?BpServiceManager?:?public?BpInterface{
public:
????BpServiceManager(const?sp&?impl)
????????:?BpInterface(impl)
????{
????}
????virtual?spgetService(const?String16&?name)?const
????{
??????????......?//實現(xiàn)啥的，我們后面再看
????}
????virtual?spcheckService(?const?String16&?name)?const
????{
??????????......
????}
????virtual?status_t?addService(const?String16&?name,?const?sp&?service,
????????????bool?allowIsolated)
????{
??????????......
????}
????virtual?VectorlistServices()
????{
??????????......
????}
};? ? ? ? 前綴Bp可以理解為Binder Proxy，即BpServiceManager實際上是ServiceManager在客戶進程中的一個代理，所以BpServiceManager并不負責實現(xiàn)真正的功能，而是通過Binder通信發(fā)送請求到前面啟動的ServiceManager進程。上一節(jié)中我們講到過，Binder通信的前提是客戶端進程需要有BpBinder，那么BpBinder從何而來呢？ defaultServiceManager ? ? ? ? 作為一個特殊的“Service”，Android系統(tǒng)為ServiceManager準備了“快捷方式”，這個快捷方式就是defaultServiceManager（frameworks/native/libs/binder/IServiceManager.cpp):
spdefaultServiceManager()
{
????if?(gDefaultServiceManager?!=?NULL)?return?gDefaultServiceManager;//單例模式
????
????{
????????AutoMutex?_l(gDefaultServiceManagerLock);
????????if?(gDefaultServiceManager?==?NULL)?{
????????????gDefaultServiceManager?=?interface_cast(
????????????????ProcessState::self()->getContextObject(NULL));
????????}
????}
????
????return?gDefaultServiceManager;
}? ? ? ? 這里可以把defaultServiceManager分解為三個步驟： ProcessState::self()ProcessState->getContextObject(NULL)interface_cast
下載文檔
