Android系统源码分析-进程间通信机制binder(一)：守护进程servicemanager

谁借莪１个温暖的怀抱￠ 2023-10-16 21:58 0阅读 0赞

#### 1.简介： ####

在上一篇（[Android系统源码分析-从init进程开始][Android_-_init] ）中，我们已经看到，servicemanager是init进程通过init.rc的service指令来启动的守护进程。用linux的ps命令也可以看到servicemanager进程是init进程的子进程。那么，这个进程的作用是什么？他的初始化过程又是怎样被执行的？本节我们一起来分析一下。

Binder源码分析系列文章：

[Android系统源码分析-进程间通信机制binder(一)：守护进程servicemanager][Android_-_binder_servicemanager]

[Android系统源码分析-进程间通信机制binder(二)：binder内存映射][Android_-_binder_binder]

[Android系统源码分析-进程间通信机制binder(三)：从framework层到Native层][Android_-_binder_framework_Native]

[Android系统源码分析-进程间通信机制binder(四)：从Native层到Driver层][Android_-_binder_Native_Driver]

#### 2.servicemanager进程的作用-Android进程间通信的基石： ####

Android系统是基于Linux系统的，从进程的角度来说，Android继承了Linux的进程间通信机制，例如共享内存，信号量，管道，socket等，除此之外，Android系统的最大特点之一就是提供了独有的进程间通信机制，即binder机制。而servicemanager进程正是支持binder机制的基石。

在应用开发时，经常通过mContext.getSystemService（xxx）来获取一个系统服务，其实，在Android系统底层（kernel之上），就是通过servicemanager进程来获取的这个服务。例如，

获取输入法服务的代码如下：

>     (InputMethodManager) mContext.getSystemService(Context.INPUT_METHOD_SERVICE);

**servicemanager进程的作用：**

servicemanger提供了注册服务，查询服务等功能。

#### 3.servicemanager进程的代码分析（初始化）： ####

在代码分析过程中，主要从一下几个角度去看待：

初始化流程

注册一个service的流程

binder的底层数据存储结构

servicemanager进程的代码位置：

servicemanager进程是一个守护进程，核心代码都是用c语言编写的，代码目录是：

frameworks/base/cmds/servicemanager

代码：

![05ae39ae4cc34dda94dd07ec39266d3a.png][]

#### 3.1从service\_manager.c文件的main函数开始开始 ####

service\_manager.c文件的main韩式是整个进程的入口函数。代码如下：

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);
        return 0;
    }

可以看到，仅仅十几行代码，看起来也非常精美。

代码分析：

**1. BINDER\_SERVICE\_MANAGER的值的定义**（在binder.h）如下：

#define BINDER_SERVICE_MANAGER ((void*) 0)

这个值有什么意义呢？

每一个service都需要注册到servicemanager中，都对应有一个handler，这些service就是通过这个handler来区分的。而servicemanager本省也是一个service，它的handler是0，即BINDER\_SERVICE\_MANAGER。要查找一个service，都是从servicemanager开始进行查询。

**2. binder\_open(128\*1024)**

非常重要的一个函数。这个函数主要功能就是初始化binder。即打开binder驱动并且映射到一块128\*1024大小的内存中。

binder\_open的代码如下：

在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);
        if (bs->fd < 0) {
            fprintf(stderr,"binder: cannot open device (%s)\n",
                    strerror(errno));
            goto fail_open;
        }
    
        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;
        }
    
            /* TODO: check version */
    
        return bs;
    
    fail_map:
        close(bs->fd);
    fail_open:
        free(bs);
        return 0;
    }

分析：

1）. bs->fd = open("/dev/binder", O\_RDWR);

打开 了驱动/dev/binder。可以看出，原理binder最底层是有一个/dev/binder存在的。

2）. mmap：通过mmap系统调用把/dev/binder映射在一块内存中，大小就是128\*1024byters。

3）.返回的是 struct binder\_state 类型的一个指针，这个结构体中保存了binder驱动的文件句柄，内存映射大小，以及这块内存区域的地址等。

struct binder\_state的定义：

struct binder_state
    {
        int fd;
        void *mapped;
        unsigned mapsize;
    };

另外一个非常重要的数据结构是：struct svcinfo

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

这是一个列表，存放的就是所有注册的service。

通过这个列表就能遍历到所有的service。

**3. binder\_become\_context\_manager函数：**

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

分析：

通过ioctl servicemanaer就成为了service的服务管理者。

**4.binder\_loop函数：**

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));
    
        for (;;) {
            bwr.read_size = sizeof(readbuf);
            bwr.read_consumed = 0;
            bwr.read_buffer = (unsigned) readbuf;
    
            res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
    
            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 %s\n", res, strerror(errno));
                break;
            }
        }
    }

分析：

在loop中，不停地通过ioctl对/dev/binder驱动进行访问，

readbuf用于存储读取到的消息数据；

BINDER\_WRITE\_READ用于读取消息数据。

然后，再进行解析，即

res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func);

再看binder\_parse是如何工作的：

int binder_parse(struct binder_state *bs, struct binder_io *bio,
                     uint32_t *ptr, uint32_t size, binder_handler func)
    {
        int r = 1;
        uint32_t *end = ptr + (size / 4);
    
        while (ptr < end) {
            uint32_t cmd = *ptr++;
    #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,"  %08x %08x\n", ptr[0], ptr[1]);
    #endif
                ptr += 2;
                break;
            case BR_TRANSACTION: {
                struct binder_txn *txn = (void *) ptr;
                if ((end - ptr) * sizeof(uint32_t) < sizeof(struct binder_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, res);
                }
                ptr += sizeof(*txn) / sizeof(uint32_t);
                break;
            }
            case BR_REPLY: {
                struct binder_txn *txn = (void*) ptr;
                if ((end - ptr) * sizeof(uint32_t) < sizeof(struct binder_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) / sizeof(uint32_t));
                r = 0;
                break;
            }
            case BR_DEAD_BINDER: {
                struct binder_death *death = (void*) *ptr++;
                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;
    }

分析：

1）. 解析以BR开头的这些命令；

2）. 以case BR\_TRANSACTION为例子：

case BR_TRANSACTION: {
                ...
                res = func(bs, txn, &msg, &reply); //处理消息
                //返回处理结果
                inder_send_reply(bs, &reply, txn->data.ptr.buffer, res); 
                ...
                break;
            }

res = func(bs, txn, &msg, &reply);

作用：用于处理消息；func就是在前面已经注册的service的handler，可以认为是具体的service。通过func，就回调到了具体的service中的对应函数中。

inder\_send\_reply(bs, &reply, txn->data.ptr.buffer, res); ：

作用：返回处理结果。

#### 4. 注册service： ####

在binder\_loop中的第二个参数，即svcmgr\_handler，

这个就是service的注册函数，具体代码如下：

int svcmgr_handler(struct binder_state *bs,
                       struct binder_txn *txn,
                       struct binder_io *msg,
                       struct binder_io *reply)
    {
        struct svcinfo *si;
        uint16_t *s;
        unsigned len;
        void *ptr;
        uint32_t strict_policy;
        int allow_isolated;
    
    //    ALOGI("target=%p code=%d pid=%d uid=%d\n",
    //         txn->target, txn->code, txn->sender_pid, txn->sender_euid);
    
        if (txn->target != svcmgr_handle)
            return -1;
    
        // 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).
        strict_policy = bio_get_uint32(msg);
        s = bio_get_string16(msg, &len);
        if ((len != (sizeof(svcmgr_id) / 2)) ||
            memcmp(svcmgr_id, s, sizeof(svcmgr_id))) {
            fprintf(stderr,"invalid id %s\n", str8(s));
            return -1;
        }
    
        switch(txn->code) {
        case SVC_MGR_GET_SERVICE:
        case SVC_MGR_CHECK_SERVICE:
            s = bio_get_string16(msg, &len);
            ptr = do_find_service(bs, s, len, txn->sender_euid);
            if (!ptr)
                break;
            bio_put_ref(reply, ptr);
            return 0;
    
        case SVC_MGR_ADD_SERVICE:
            s = bio_get_string16(msg, &len);
            ptr = bio_get_ref(msg);
            allow_isolated = bio_get_uint32(msg) ? 1 : 0;
            if (do_add_service(bs, s, len, ptr, txn->sender_euid, allow_isolated))
                return -1;
            break;
    
        case SVC_MGR_LIST_SERVICES: {
            unsigned n = bio_get_uint32(msg);
    
            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;
    }

分析：

1）case SVC\_MGR\_ADD\_SERVICE:的执行就是service的注册；

2）case SVC\_MGR\_CHECK\_SERVICE:的执行就是service的查询；

3）case SVC\_MGR\_LIST\_SERVICES:的执行就是列出所有service。

do\_add\_service函数：

如果已经注册了对应的service，就不再注册。否则，将新的节点添加到svclist中。

这样，整个servicemangar进程就初始化完成了。再总结一下：

打开binder驱动->注册servicemanager（handler为0）->binder loop。

--------------------

Android进程间通信之binder，必须掌握的底层代码。

[Android_-_init]: https://blog.csdn.net/liranke/article/details/4720349
[Android_-_binder_servicemanager]: https://blog.csdn.net/liranke/article/details/4720689
[Android_-_binder_binder]: https://blog.csdn.net/liranke/article/details/4723360
[Android_-_binder_framework_Native]: https://blog.csdn.net/liranke/article/details/4727335
[Android_-_binder_Native_Driver]: https://blog.csdn.net/liranke/article/details/4727339
[05ae39ae4cc34dda94dd07ec39266d3a.png]: https://img-blog.csdnimg.cn/05ae39ae4cc34dda94dd07ec39266d3a.png