【Binder通信】第二篇:ServiceManager启动过程

【Binder通信】第二篇:ServiceManager启动过程

consumedServiceManager进程是Binder进程间通信机制中一个非常重要的守护进程,它是由init进程解析init.rc文件而创建出来的。
其作为binder服务的大管家,用于管理系统中的各种服务。

ServiceManager最核心的两个功能为查询和注册服务:
1.注册服务:记录服务名和handle信息,保存到svcinfo链表中;
2.查询服务:根据服务名查询相应的的handle信息。

ServiceManager进程的启动过程分为三步走:

  1. 打开binder驱动:调用了驱动层的binder_open方法
  2. 想成为binder驱动管理员:binder_become_context_manager
  3. 成为binder管理员之后,就进入无限循环,不断处理 client
    端发来的请求:调用binder_loop。(这一步是最重要的一步,是本文重点介绍的一步)
    init进程解析服务之后,调用service_manager.c的main()方法开始ServiceManager进程的创建
service_manager.c
int main(int argc, char **argv)
{
//binder_state结构体,用来描述binder驱动的状态。通过binder_state可以得到binder驱动的fd用以操作binder驱动。其中包含: int fd; void *mapped; size_t mapsize;
    struct binder_state *bs;
 
//1:打开binder驱动:调用了自己实现的binder_open方法。申请 128k 字节大小的内存空间。
    bs = binder_open(128*1024);
    if (!bs) {
        ALOGE("failed to open binder driver\n");
        return -1;
    }
 
//2:注册成为binder服务大管家,成为其守护进程:binder_become_context_manager
    if (binder_become_context_manager(bs)) {
        ALOGE("cannot become context manager (%s)\n", strerror(errno));
        return -1;
    }
 
...
 
//3:进入无限循环,处理 client 端发来的请求:调用binder_loop。
    binder_loop(bs, svcmgr_handler);
 
    return 0;
}

1、打开binder驱动

../servicemanager/binder.c
struct binder_state *binder_open(size_t mapsize)
{
//binder_state结构体,其中包含binder驱动的文件fd,用以操作binder驱动。
    struct binder_state *bs;
//binder_version结构体,在驱动层以外用以从驱动层获取bidner驱动版本并记录
    struct binder_version vers;
 
//1:通过malloc开辟内存空间。
    bs = malloc(sizeof(*bs));
 
//2:使用open()系统调用打开binder设备,获取binder驱动的fd。并将此fd给到binder_state结构体bs中的fd。
//linux在操作硬件设备时,屏蔽了硬件的基本细节,只把硬件当做文件来进行操作。
//open函数是标准的系统调用,在每一个kernel driver中都有实现这个接口.
 
    bs->fd = open("/dev/binder", O_RDWR);
...
 
//获取驱动版本,并判断版本是否一致。从kernel获取当前binder驱动的版本,如果
     //binder驱动上层和kernel使用的不是同一个版本,那么就无法binder设备
    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_versmapsizeion, BINDER_CURRENT_PROTOCOL_VERSION);
        goto fail_open;
    }
 
//3:binder_state结构体bs中的mapsize设置为128K
    bs->mapsize = mapsize;
 
//4:调用binder_mmap进行内存映射,PROT_READ(仅可读)
    bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);
 
    return bs;
 
fail_map:
    close(bs->fd);
fail_open:
    free(bs);
    return NULL;
}
在这里插入图片描述

这里随便用手边的红米K20pro看了一下,确实servicemanager映射的大小是128K。
7221293000-72212b3000 = 20000,

20000转换为16进制就是131072,131072/1024=128K

2、注册成为binder服务大管家

这里调用的是驱动层的 binder_ioctl 方法,会在bidner_init驱动初始化的时候进行映射。将.ioctl映射到binder_ioctl。从而调用到驱动层的binder_ioctl。最主要的是在binder驱动里将servicemanager中的代表context_manager的静态变量赋值。
该部分比较重要,放在binder驱动介绍的时候进行说明。

int binder_become_context_manager(struct binder_state *bs)
{
    return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
}

3、无限循环守护binder驱动,等待客户端发来请求

上层通过binder_write_read结构体 bwr与binder驱动进行数据交换。其中,输出缓冲区用以保存将要发送给binder驱动的命令协议,输出缓冲区用以保存binder驱动发送给进程的返回协议。

当bwr中write_size等变量值为0时,代表不会向binder驱动中写入数据。

binder_loop() 方法中有以下步骤较为重要:

  1. 将BC_ENTER_LOOPER写入binder驱动,告诉驱动当前进程ServiceManager进入循环:binder_write()
  2. 不停循环等待读取binder驱动的数据: ioct()
  3. 解析远程进程的binder驱动信息: binder_parse()
../servicemanager/binder.c
void binder_loop(struct binder_state *bs, binder_handler func)
{
    int res;
//bwr中,输出缓冲区用以保存将要发送给binder驱动的命令协议,输出缓冲区用以保存binder驱动发送给进程的返回协议。
    struct binder_write_read bwr;
//要读的数据大小
    uint32_t readbuf[32];
 
//bwr以下三个write设为0。目的是保证只读从binder中读数据,不往里面写数据。
    bwr.write_size = 0;
    bwr.write_consumed = 0;
    bwr.write_buffer = 0;
 
//1:将BC_ENTER_LOOPER写入binder驱动,告诉驱动当前进程进入循环。最终也是系统调用ioctl(),弄一个bwr,把BC_ENTER_LOOPER写入驱动。
    readbuf[0] = BC_ENTER_LOOPER;
    binder_write(bs, readbuf, sizeof(uint32_t));
 
    for (;;) {
        bwr.read_size = sizeof(readbuf);
//read_consumed为本次通信已经读取的字节数
        bwr.read_consumed = 0;
        bwr.read_buffer = (uintptr_t) readbuf;
 
//2:不停循环等待读取binder驱动的数据,系统调用ioctl()
        res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
 
//3:解析远程进程的binder驱动信息
        res = binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func);
  
    }
}

3.1 将BC_ENTER_LOOPER写入binder驱动

这一步比较简单,告诉binder驱动当前进程进入循环。

.../servicemanager/binder.c
int binder_write(struct binder_state *bs, void *data, size_t len)
{
//将BC_ENTER_LOOPER写入binder驱动,告诉驱动当前进程进入循环
    struct binder_write_read bwr;
    int res;
//只写不读
    bwr.write_size = len;
    bwr.write_consumed = 0;
    bwr.write_buffer = (uintptr_t) data;
    bwr.read_size = 0;
    bwr.read_consumed = 0;
    bwr.read_buffer = 0;
    res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
    return res;
}

3.2 从Binder驱动不停的读取数据

3.3 解析远程进程通过binder驱动传来的信息(这一步最为关键)

.../servicemanager/binder.c
int binder_parse(struct binder_state *bs, struct binder_io *bio,
                 uintptr_t ptr, size_t size, binder_handler func)
{
    int r = 1;
    uintptr_t end = ptr + (uintptr_t) size;
 
    while (ptr < end) {
        uint32_t cmd = *(uint32_t *) ptr;
        ptr += sizeof(uint32_t);
#if TRACE
        fprintf(stderr,"%s:\n", cmd_name(cmd));
#endif
        switch(cmd) {
        case BR_NOOP:
            break;
        case BR_TRANSACTION_COMPLETE:
            break;
        case BR_INCREFS:
        case BR_ACQUIRE:
        case BR_RELEASE:
        case BR_DECREFS:
#if TRACE
            fprintf(stderr,"  %p, %p\n", (void *)ptr, (void *)(ptr + sizeof(void *)));
#endif
            ptr += sizeof(struct binder_ptr_cookie);
            break;
        case BR_TRANSACTION: {
            struct binder_transaction_data *txn = (struct binder_transaction_data *) ptr;
            if ((end - ptr) < sizeof(*txn)) {
                ALOGE("parse: txn too small!\n");
                return -1;
            }
            binder_dump_txn(txn);
            if (func) {
                unsigned rdata[256/4];
                struct binder_io msg;
                struct binder_io reply;
                int res;
 
                bio_init(&reply, rdata, sizeof(rdata), 4);
                bio_init_from_txn(&msg, txn);
                res = func(bs, txn, &msg, &reply);
                binder_send_reply(bs, &reply, txn->data.ptr.buffer, res);
            }
            ptr += sizeof(*txn);
            break;
        }
        case BR_REPLY: {
            struct binder_transaction_data *txn = (struct binder_transaction_data *) ptr;
            if ((end - ptr) < sizeof(*txn)) {
                ALOGE("parse: reply too small!\n");
                return -1;
            }
            binder_dump_txn(txn);
            if (bio) {
                bio_init_from_txn(bio, txn);
                bio = 0;
            } else {
                /* todo FREE BUFFER */
            }
            ptr += sizeof(*txn);
            r = 0;
            break;
        }
        case BR_DEAD_BINDER: {
            struct binder_death *death = (struct binder_death *)(uintptr_t) *(binder_uintptr_t *)ptr;
            ptr += sizeof(binder_uintptr_t);
            death->func(bs, death->ptr);
            break;
        }
        case BR_FAILED_REPLY:
            r = -1;
            break;
        case BR_DEAD_REPLY:
            r = -1;
            break;
        default:
            ALOGE("parse: OOPS %d\n", cmd);
            return -1;
        }
    }
 
    return r;
}

然后回调service_manager.c 的svcmgr_handler方法。

.../servicemanager/service_manager.c
int svcmgr_handler(struct binder_state *bs,
                   struct binder_transaction_data *txn,
                   struct binder_io *msg,
                   struct binder_io *reply)
{
//准备svcinfo的结构体指针,service_manager通过这个结构体来管理服务。其实就是一个链表,*si为头指针。
    struct svcinfo *si;
    uint16_t *s;
    size_t len;
    uint32_t handle;
    uint32_t strict_policy;
    int allow_isolated;
 
 
    //ALOGI("target=%p code=%d pid=%d uid=%d\n",
    //      (void*) txn->target.ptr, txn->code, txn->sender_pid, txn->sender_euid);
 
//BINDER_SERVICE_MANAGER就是0,这里判断对端bwr结构体指定的目标进程是否为0。如果不为0直接反馈-1。
    if (txn->target.ptr != BINDER_SERVICE_MANAGER)
        return -1;
 
//对端在binder请求之前,一般会向binder驱动中写入一个Ping,先ping一下服务端。这里就是响应这个PING。
    if (txn->code == PING_TRANSACTION)
        return 0;
 
    // Equivalent to Parcel::enforceInterface(), reading the RPC
    // header with the strict mode policy mask and the interface name.
    // Note that we ignore the strict_policy and don't propagate it
    // further (since we do no outbound RPCs anyway).
 
//这里就是获取msg的前msg的前4个字节。
    strict_policy = bio_get_uint32(msg);
    s = bio_get_string16(msg, &len);
    if (s == NULL) {
        return -1;
    }
 
    if ((len != (sizeof(svcmgr_id) / 2)) ||
        memcmp(svcmgr_id, s, sizeof(svcmgr_id))) {
        fprintf(stderr,"invalid id %s\n", str8(s, len));
        return -1;
    }
 
    if (sehandle && selinux_status_updated() > 0) {
        struct selabel_handle *tmp_sehandle = selinux_android_service_context_handle();
        if (tmp_sehandle) {
            selabel_close(sehandle);
            sehandle = tmp_sehandle;
        }
    }
 
//根据对端bwr的code,设定的值。进行操作。
    switch(txn->code) {
    case SVC_MGR_GET_SERVICE:
//如果是查找服务
    case SVC_MGR_CHECK_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);
        if (!handle)
            break;
        bio_put_ref(reply, handle);
        return 0;
 
//如果是add服务
    case SVC_MGR_ADD_SERVICE:
        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,
            allow_isolated, txn->sender_pid))
            return -1;
        break;
 
    case SVC_MGR_LIST_SERVICES: {
        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;
}

你可能感兴趣的:(【Binder通信】第二篇:ServiceManager启动过程)