Android - Binder机制 - ServiceManager

以下几篇文章是较深入分析binder机制。

目录

1. Android - Binder机制 - ServiceManager

2. Android - Binder机制 - 普通service注册

3. Android - Binder机制 - 获得普通service

4. Android - Binder机制 - client和普通service交互

5. Android - Binder机制 - Binder框架总结

6. Android - Binder机制 - ProcessState和IPCThreadState

7. Android - Binder机制 - 驱动

Android - Binder机制 - ServiceManager

UML及说明

代码路径：frameworks/base/cmds/servicemanager/service_manager.c

虽然service_manager并不是用类来写的，但是为了好看，还是用类图来表示。

ServiceManager主要有两大功能，一个是监听其他service的addservice请求，一个是监听client的getservice服务。下面分析ServiceManager主要代码和工作。

初始化

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)) {
        LOGE("cannot become context manager (%s)\n", strerror(errno));
        return -1;
    }

    svcmgr_handle = svcmgr;
    binder_loop(bs, svcmgr_handler);
    return 0;
}

ServiceManager以一个独立的进程存在，以上代码主要完成三步工作：

1. binder_open打开binder设备；

2. binder_become_context_manager通过ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0)设置为ServiceManager服务，该服务的handle索引值为0；

3. binder_loop进行循环监听；

binder_loop是最重要的部分，代码就不贴了，binder_loop每次循环都进行如下几步：

1. 通过ioctl(bs->fd, BINDER_WRITE_READ, &bwr)读取binder驱动数据（请求数据）；

2. binder_parse解析数据，数据包的第4至7字节是该数据包的类型，常用的包括BR_TRANSACTION（请求转发）和BR_DEAD_BINDER（服务死亡），解析完数据，然后调用相应的处理；

3. 如BR_TRANSACTION请求，通过调用ServiceManager注册的svcmgr_handler回调函数，来处理具体的请求，这些请求包括（SVC_MGR_GET_SERVICE、SVC_MGR_CHECK_SERVICE、SVC_MGR_ADD_SERVICE、SVC_MGR_LIST_SERVICES）；

ServiceManager的主要任务就是监听AddService和GetService请求，以下是对这两个请求的具体分析。

AddService请求

svcmgr_handler调用do_add_service函数进行具体处理：

1. svc_can_register判断是否能够注册该服务，有一个allowed数组，定义了可以注册的服务，如果这个服务是自定义的，要在allowed数组添加上这个服务的名称；

2. find_svc检测这个服务是否已经注册过了，如果注册过了，就返回错误；

3. 创建一个新的svcinfo节点，然后将节点添加到svclist中，到此为止，服务只是在ServiceManager进程中注册了，还没有向binder驱动中注册；

4. binder_acquire通过BC_ACQUIRE指令将服务注册到binder中；

5. binder_link_to_death待研究。。。

经过简单的几步，服务就注册到binder了，如果要研究很详细的机制，必须研究binder驱动，binder驱动会在以后篇章深入分析，在此就不做说明了。

GetService请求

当一个client要获得某个服务时，要通过GetService请求获得某个服务，svcmgr_handler调用do_find_service函数进行具体处理：

1. do_find_service只是到svclist查找，如果找不到，就返回NULL，如果找到了就返回svcinfo.ptr；

2. svcinfo的ptr是void *，是一个地址，具体里面放的什么东西，看来还得需要分析驱动，所以我们看到binder真正的机制其实是在驱动里面实现的；

很简单，没有和binder驱动打交道就获得了服务，只是这个ptr确实需要研究明白；

svcinfo结构体

struct svcinfo 
{
    struct svcinfo *next;
    void *ptr;
    struct binder_death death;
    unsigned len;
    uint16_t name[0];
};

待研究。。。