红茶一杯话Binder （ServiceManager篇）

1.先说一个大概

Android平台的一个基本设计理念是构造一个相对平坦的功能集合，这些功能可能会身处于不同的进程中，然而却可以高效地整合到一起，实现不同的用户需求。这就必须打破过去各个孤立App所形成的天然藩篱。为此，Android提供了Binder机制。

在Android中，系统提供的服务被包装成一个个系统级service，这些service往往会在设备启动之时添加进Android系统。在上一篇文档中，我们已经了解了BpBinder和BBinder的概念，而service实体的底层说到底就是一个BBinder实体。

我们知道，如果某个程序希望享受系统提供的服务，它就必须调用系统提供的外部接口，向系统发出相应的请求。因此，Android中的程序必须先拿到和某个系统service对应的代理接口，然后才能通过这个接口，享受系统提供的服务。说白了就是我们得先拿到一个和目标service对应的合法BpBinder。

然而，该怎么获取和系统service对应的代理接口呢？Android是这样设计的：先启动一个特殊的系统服务，叫作Service Manager Service（简称SMS），它的基本任务就是管理其他系统服务。其他系统服务在系统启动之时，就会向SMS注册自己，于是SMS先记录下与那个service对应的名字和句柄值。有了句柄值就可以用来创建合法的BpBinder了。只不过在实际的代码中，SMS并没有用句柄值创建出BpBinder，这个其实没什么，反正指代目标service实体的目的已经达到了。后续当某程序需要享受某系统服务时，它必须先以“特定手法”获取SMS代理接口，并经由这个接口查询出目标service对应的合法Binder句柄，然后再创建出合法的BpBinder对象。

在此，我们有必要交代一下“Binder句柄”的作用。句柄说穿了是个简单的整数值，用来告诉Binder驱动我们想找的目标Binder实体是哪个。但是请注意，句柄只对发起端进程和Binder驱动有意义，A进程的句柄直接拿到B进程，是没什么意义的。也就是说，不同进程中指代相同Binder实体的句柄值可能是不同的。示意图如下：

SMS记录了所有系统service所对应的Binder句柄，它的核心功能就是维护好这些句柄值。后续，当用户进程需要获取某个系统service的代理时，SMS就会在内部按service名查找到合适的句柄值，并“逻辑上”传递给用户进程，于是用户进程会得到一个新的合法句柄值，这个新句柄值可能在数值上和SMS所记录的句柄值不同，然而，它们指代的却是同一个Service实体。句柄的合法性是由Binder驱动保证的，这一点我们不必担心。

前文我们提到要以“特定手法”获取SMS代理接口，这是什么意思呢？在IServiceManager.cpp文件中，我们可以看到一个defaultServiceManager()函数，代码如下：

【frameworks/native/libs/binder/IServiceManager.cpp】

sp<IServiceManager> defaultServiceManager()
{
    if (gDefaultServiceManager != NULL)
        return gDefaultServiceManager;
    {
        AutoMutex _l(gDefaultServiceManagerLock);
        if (gDefaultServiceManager == NULL)
        {
            gDefaultServiceManager = interface_cast<IServiceManager>(
                ProcessState::self()->getContextObject(NULL));
        }
    }

    return gDefaultServiceManager;
}

这个函数里调用interface_cast的地方是用一句getContextObject(NULL)来获取BpBinder对象的。我们先不深入讲解这个函数，只需要知道这一句里的getContextObject(NULL)实际上相当于new BpBinder(0)就可以了。噢，看来要得到BpBinder对象并不复杂嘛，直接new就好了。然而，我之所以使用“特定手法”一词，是因为这种直接new BpBinder(xxx)的做法，只能用于获取SMS的代理接口。大家可不要想当然地随便用这种方法去创建其他服务的代理接口噢。

在Android里，对于Service Manager Service这个特殊的服务而言，其对应的代理端的句柄值已经预先定死为0了，所以我们直接new BpBinder(0)拿到的就是个合法的BpBinder，其对端为“Service Manager Service实体”（至少目前可以先这么理解）。那么对于其他“服务实体”对应的代理，句柄值又是多少呢？使用方又该如何得到这个句柄值呢？我们总不能随便蒙一个句柄值吧。正如我们前文所述，要得到某个服务对应的BpBinder，主要得借助Service Manager Service系统服务，查询出一个合法的Binder句柄，并进而创建出合法的BpBinder。

这里有必要澄清一下，利用SMS获取合法BpBinder的方法，并不是Android中得到BpBinder的唯一方法。另一种方法是，“起始端”经由一个已有的合法BpBinder，将某个binder实体或代理对象作为跨进程调用的参数，“传递”给“目标端”，这样目标端也可以拿到一个合法的BpBinder。

我们把以上介绍的知识绘制成示意图，如下：

 

请顺着图中标出的1）、2）、3）、4）序号，读一下图中的说明。

在跨进程通信方面，所谓的“传递”一般指的都是逻辑上的传递，所以应该打上引号。事实上，binder实体对象是不可能完全打包并传递到另一个进程的，而且也没有必要这么做。目前我们只需理解，binder架构会保证“传递”动作的目标端可以拿到一个和binder实体对象对应的代理对象即可。详细情况，要到分析binder驱动的部分再阐述。

既然SMS承担着让客户端获取合法BpBinder的责任，那么它的重要性就不言而喻了。现在我们就来详细看看具体如何使用它。

2. 具体使用Service Manager Service

2.1 必须先得到IServiceManager代理接口

要获取某系统service的代理接口，必须先得到IServiceManager代理接口。还记得前文C++代码中获取IServiceManager代理接口的句子吗？

            gDefaultServiceManager = interface_cast<IServiceManager>(
                ProcessState::self()->getContextObject(NULL));

我们在前一篇文档中已经介绍过interface_cast了，现在再贴一下这个函数的代码：

template<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
    return INTERFACE::asInterface(obj);
}

也就是说，其实调用的是IServiceManager::asInterface(obj)，而这个obj参数就是new BpBinder(0)得到的对象。当然，这些都是C++层次的概念，Java层次把这些概念都包装起来了。

在Java层次，是这样获取IServiceManager接口的：

【frameworks/base/core/java/android/os/ServiceManager.java】

private static IServiceManager getIServiceManager()
{
    if (sServiceManager != null) {
        return sServiceManager;
    }

    // Find the service manager
    sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
    return sServiceManager;
}

噢，又出现了一个asInterface，看来Java层次和C++层的代码在本质上是一致的。

ServiceManagerNative的asInterface()代码如下：

static public IServiceManager asInterface(IBinder obj)
{
    if (obj == null)
    {
        return null;
    }

    IServiceManager in = (IServiceManager)obj.queryLocalInterface(descriptor);
    if (in != null)
    {
        return in;
    }

    return new ServiceManagerProxy(obj);
}

目前我们只需了解，用户进程在调用到getIServiceManager()时，最终会走到return new ServiceManagerProxy(obj)即可。

哎呀，又出现了两个名字：ServiceManagerProxy和ServiceManagerNative。简单地说：

1） ServiceManagerProxy就是IServiceManager代理接口；

2） ServiceManagerNative显得很鸡肋；

它们的继承关系图如下：

下面我们分别来说明。

2.1.1 ServiceManagerProxy就是IServiceManager代理接口

用户要访问Service Manager Service服务，必须先拿到IServiceManager代理接口，而ServiceManagerProxy就是代理接口的实现。这个从前文代码中的new ServiceManagerProxy(obj)一句就可以看出来了。ServiceManagerProxy的构造函数内部会把obj参数记录到mRemote域中：

public ServiceManagerProxy(IBinder remote)
{
    mRemote = remote;
}

mRemote的定义是：

private IBinder mRemote;

其实说白了，mRemote的核心包装的就是句柄为0的BpBinder对象，这个应该很容易理解。

日后，当我们通过IServiceManager代理接口访问SMS时，其实调用的就是ServiceManagerProxy的成员函数。比如getService()、checkService()等等。

2.1.2 ServiceManagerNative显得很鸡肋

另一方面，ServiceManagerNative就显得很鸡肋了。

ServiceManagerNative是个抽象类：

public abstract class ServiceManagerNative extends Binder implements IServiceManager

它继承了Binder，实现了IServiceManager，然而却是个虚有其表的class。它唯一有用的大概就是前文列出的那个静态成员函数asInterface()了，而其他成员函数（像onTransact()）就基本上没什么用。

如果我们花点儿时间在工程里搜索一下ServiceManagerNative，会发现根本找不到它的子类。一个没有子类的抽象类不就是虚有其表吗。到头来我们发现，关于ServiceManagerNative的用法只有一种，就是：

ServiceManagerNative.asInterface(BinderInternal.getContextObject());

用一下它的asInterface()静态函数而已。

为什么会这样呢？我想这可能是某种历史的遗迹吧。同理，我们看它的onTransact()函数，也会发现里面调用的类似addService()那样的函数，也都是找不到对应的实现体的。当然，因为ServiceManagerNative本身是个抽象类，所以即便它没有实现IServiceManager的addService()等成员函数，也是可以编译通过的。

这里透出一个信息，既然Java层的ServiceManagerNative没什么大用处，是不是表示C++层也缺少对应的SMS服务实体呢？在后文我们可以看到，的确是这样的，Service Manager Service在C++层被实现成一个独立的进程，而不是常见的Binder实体。

2.2 通过addService()来注册系统服务

我们还是回过头接着说对于IServiceManager接口的使用吧。最重要的当然是注册系统服务。比如在System Server进程中，是这样注册PowerManagerService系统服务的：

public void run()
{
    . . . . . .
    power = new PowerManagerService();
    ServiceManager.addService(Context.POWER_SERVICE, power);
    . . . . . .

addService()的第一个参数就是所注册service的名字，比如上面的POWER_SERVICE对应的字符串就是"power"。第二个参数传入的是service Binder实体。Service实体在Service Manager Service一侧会被记录成相应的句柄值，如图：

有关addService()内部机理，我们会在后文讲述，这里先不细说。

2.3 通过getService()来获取某系统服务的代理接口

除了注册系统服务，Service Manager Service的另一个主要工作就是让用户进程可以获取系统service的代理接口，所以其getService()函数就非常重要了。

其实，ServiceManagerProxy中的getService()等成员函数，仅仅是把语义整理进parcel，并通过mRemote将parcel传递到目标端而已。所以我们只看看getService()就行了，其他的函数都大同小异。

public IBinder getService(String name) throws RemoteException
{
    Parcel data = Parcel.obtain();
    Parcel reply = Parcel.obtain();
    data.writeInterfaceToken(IServiceManager.descriptor);
    data.writeString(name);

    mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);

    IBinder binder = reply.readStrongBinder();
    reply.recycle();
    data.recycle();
    return binder;
}

传递的语义就是GET_SERVICE_TRANSACTION，非常简单。mRemote从本质上看就是句柄为0的BpBinder，所以binder驱动很清楚这些语义将去向何方。

关于Service Manager Service的使用，我们就先说这么多。下面我们要开始探索SMS内部的运作机制了。

3.Service Manager Service的运作机制

3.1 Service Manager Service服务的启动

既然前文说ServiceManagerNative虚有其表，而且没有子类，那么Service Manager Service服务的真正实现代码位于何处呢？答案就在init.rc脚本里。关于init.rc的详细情况，可参考其他阐述Android启动流程的文档，此处不再赘述。

init.rc脚本中，在描述zygote service之前就已经写明service manager service的信息了：

service servicemanager /system/bin/servicemanager
    user system
    critical
    onrestart restart zygote
    onrestart restart media

可以看到，servicemanager是一种native service。这种native service都是需要用C/C++编写的。Service Manager Service对应的实现代码位于frameworks/base/cmds/servicemanager/Service_manager.c文件中。这个文件中有每个C程序员都熟悉的main()函数，其编译出的可执行程序就是/system/bin/servicemanager。

另外，还有一个干扰我们视线的cpp文件，名为IServiceManager.cpp，位于frameworks/base/libs/binder/目录中，这个文件里的BnServiceManager应该和前文的ServiceManagerNative类似，它的onTransact()也不起什么作用。

3.2 Service Manager Service是如何管理service句柄的？

在C语言层次，简单地说并不存在一个单独的ServiceManager结构。整个service管理机制都被放在一个独立的进程里了，该进程对应的实现文件就是Service_manager.c。

进程里有一个全局性的svclist变量：

struct svcinfo *svclist = 0;

它记录着所有添加进系统的“service代理”信息，这些信息被组织成一条单向链表，我们不妨称这条链表为“服务向量表”。示意图如下：

链表节点类型为svcinfo。

因为svcinfo里要记录下service的名字字符串，所以它需要的buffer长度是(len + 1) * sizeof(uint16_t)，记得要留一个’\0’的结束位置。另外，svcinfo的ptr域，实际上记录的就是系统service对应的binder句柄值。

日后，当应用调用getService()获取系统服务的代理接口时，SMS就会搜索这张“服务向量表”，查找是否有节点能和用户传来的服务名匹配，如果能查到，就返回对应的sp<IBinder>，这个接口在远端对应的实体就是“目标Service实体”。如此一来，系统中就会出现如下关系：

3.3 Service Manager Service的主程序（C++层）

要更加深入地了解Service Manager进程的运作，我们必须研究其主程序。参考代码是frameworks\base\cmds\servicemanager\Service_manager.c。

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;
}

main()函数一开始就打开了binder驱动，然后调用binder_become_context_manager()让自己成为整个系统中唯一的上下文管理器，其实也就是service管理器啦。接着main()函数调用binder_loop()进入无限循环，不断监听并解析binder驱动发来的命令。

binder_loop()中解析驱动命令的函数是binder_parse()，其最后一个参数func来自于binder_loop()的最后一个参数——svcmgr_handler函数指针。这个svcmgr_handler()应该算是Service Manager Service的核心回调函数了。

为了方便查看，我把main()函数以及其间接调用的ioctl()语句绘制成如下的调用关系图：

下面我们逐个分析其中调用的函数。

3.3.1 binder_open()

Service Manager Service必须先调用binder_open()来打开binder驱动，驱动文件为“/dev/binder”。binder_open()的代码截选如下：

struct binder_state * binder_open(unsigned mapsize)
{
    struct binder_state *bs;

    bs = malloc(sizeof(*bs));
    . . . . . .
    bs->fd = open("/dev/binder", O_RDWR);
    . . . . . .
    bs->mapsize = mapsize;
    bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);
    . . . . . .
    return bs;
. . . . . .
}

binder_open()的参数mapsize表示它希望把binder驱动文件的多少字节映射到本地空间。可以看到，Service Manager Service和普通进程所映射的binder大小并不相同。它把binder驱动文件的128K字节映射到内存空间，而普通进程则会映射binder文件里的BINDER_VM_SIZE（即1M减去8K）字节。

具体的映射动作由mmap()一句完成，该函数将binder驱动文件的一部分映射到进程空间。mmap()的函数原型如下：

void* mmap ( void * addr , size_t len , int prot , int flags , int fd , off_t offset );

该函数会把“参数fd所指代的文件”中的一部分映射到进程空间去。这部分文件内容以offset为起始位置，以len为字节长度。其中，参数offset表明从文件起始处开始算起的偏移量。参数prot表明对这段映射空间的访问权限，可以是PROT_READ（可读）、PROT_WRITE （可写）、PROT_EXEC （可执行）、PROT_NONE（不可访问）。参数addr用于指出文件应被映射到进程空间的起始地址，一般指定为空指针，此时会由内核来决定起始地址。

binder_open()的返回值类型为binder_state*，里面记录着刚刚打开的binder驱动文件句柄以及mmap()映射到的最终目标地址。

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

以后，SMS会不断读取这段映射空间，并做出相应的动作。

3.3.2 binder_become_context_manager()

我们前面已经说过，binder_become_context_manager()的作用是让当前进程成为整个系统中唯一的上下文管理器，即service管理器。其代码非常简单：

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

仅仅是把BINDER_SET_CONTEXT_MGR发送到binder驱动而已。驱动中与ioctl()对应的binder_ioctl()是这样处理的：

static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
     int ret;
    struct binder_proc *proc = filp->private_data;
    struct binder_thread *thread;
    unsigned int size = _IOC_SIZE(cmd);
    void __user *ubuf = (void __user *)arg;

    . . . . . .
    . . . . . .
    case BINDER_SET_CONTEXT_MGR:
        . . . . . .
        . . . . . .
            binder_context_mgr_uid = current->cred->euid;

        binder_context_mgr_node = binder_new_node(proc, NULL, NULL);
        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_node节点，并记入静态变量binder_context_mgr_node。

我们在这里多说两句，一般情况下，应用层的每个binder实体都会在binder驱动层对应一个binder_node节点，然而binder_context_mgr_node比较特殊，它没有对应的应用层binder实体。在整个系统里，它是如此特殊，以至于系统规定，任何应用都必须使用句柄0来跨进程地访问它。现在大家可以回想一下前文在获取SMS接口时说到的那句new BpBinder(0)，是不是能加深一点儿理解。

3.3.3 binder_loop()

我们再回到SMS的main()函数。

接下来的binder_loop()会先向binder驱动发出了BC_ENTER_LOOPER命令，接着进入一个for循环不断调用ioctl()读取发来的数据，接着解析这些数据。参考代码在：

【frameworks/base/cmds/servicemanager/Binder.c】（注意！这个Binder.c文件不是binder驱动层那个Binder.c文件噢。）

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) {
            LOGE("binder_loop: ioctl failed (%s)\n", strerror(errno));
            break;
        }

        res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func);
        if (res == 0) {
            LOGE("binder_loop: unexpected reply?!\n");
            break;
        }
        if (res < 0) {
            LOGE("binder_loop: io error %d %s\n", res, strerror(errno));
            break;
        }
    }
}

注意binder_loop()的参数func，它的值是svcmgr_handler()函数指针。而且这个参数会进一步传递给binder_parse()。

3.3.3.1 BC_ENTER_LOOPER

binder_loop()中发出BC_ENTER_LOOPER命令的目的，是为了告诉binder驱动“本线程要进入循环状态了”。在binder驱动中，凡是用到跨进程通信机制的线程，都会对应一个binder_thread节点。这里的BC_ENTER_LOOPER命令会导致这个节点的looper状态发生变化：

thread->looper |= BINDER_LOOPER_STATE_ENTERED;

有关binder_thread的细节，也会在阐述Binder驱动一节进行说明。

3.3.3.2 binder_parse()

在binder_loop()进入for循环之后，最显眼的就是那句binder_parse()了。binder_parse()负责解析从binder驱动读来的数据，其代码截选如下：

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++;
        . . . . . .
        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;
        }
        . . . . . .
        . . . . . .
    }

    return r;
}

从前文的代码我们可以看到，binder_loop()声明了一个128字节的buffer（即unsigned readbuf[32]），每次用BINDER_WRITE_READ命令从驱动读取一些内容，并传入binder_parse()。

binder_parse()在合适的时机，会回调其func参数（binder_handler func）指代的回调函数，即前文说到的svcmgr_handler()函数。

binder_loop()就这样一直循环下去，完成了整个service manager service的工作。

4.Service Manager Service解析收到的命令

现在，我们专门用一个小节来说说Service Manager Service内循环解析命令时的一些细节。我们要确定binder_loop()从驱动侧读到的数据到底如何解析？我们重贴一下binder_parse()的声明部分：

int binder_parse(struct binder_state *bs,
                 struct binder_io *bio,
                 uint32_t *ptr,
                 uint32_t size,
                 binder_handler func)

之前利用ioctl()读取到的数据都记录在第三个参数ptr所指的缓冲区中，数据大小由size参数记录。其实这个buffer就是前文那个128字节的buffer。

从驱动层读取到的数据，实际上是若干BR命令。每个BR命令是由一个命令号(uint32)以及若干相关数据组成的，不同BR命令的长度可能并不一样。如下表所示：

BR命令	需进一步读取的uint32数
BR_NOOP	0
BR_TRANSACTION_COMPLETE	0
BR_INCREFS	2
BR_ACQUIRE	2
BR_RELEASE	2
BR_DECREFS	2
BR_TRANSACTION	sizeof(binder_txn) / sizeof(uint32_t)
BR_REPLY	sizeof(binder_txn) / sizeof(uint32_t)
BR_DEAD_BINDER	1
BR_FAILED_REPLY	0
BR_DEAD_REPLY	0

每次ioctl()操作所读取的数据，可能会包含多个BR命令，所以binder_parse()需要用一个while循环来解析buffer中所有的BR命令。我们随便画个示意图，如下：

图中的buffer中含有3条BR命令，分别为BR_TRANSACTION、BR_TRANSACTION_COMPLETE、BR_NOOP命令。一般而言，我们最关心的就是BR_TRANSACTION命令啦，因此前文截选的binder_parse()代码，主要摘录了处理BR_TRANSACTION命令的代码，该命令的命令号之后跟着的是一个binder_txn结构。现在我们来详细看这个结构。

4.1 解析binder_txn信息

binder_txn的定义如下：

【frameworks/base/cmds/servicemanager/Binder.h】

struct binder_txn
{
    void *target;
    void *cookie;
    uint32_t code;        // 所传输的语义码
    uint32_t flags;

    uint32_t sender_pid;
    uint32_t sender_euid;

    uint32_t data_size;
    uint32_t offs_size;
    void *data;
    void *offs;
};

binder_txn说明了transaction到底在传输什么语义，而语义码就记录在其code域中。不同语义码需要携带的数据也是不同的，这些数据由data域指定。示意图如下：

简单地说，我们从驱动侧读来的binder_txn只是一种“传输控制信息”，它本身并不包含传输的具体内容，而只是指出具体内容位于何处。现在，工作的重心要转到如何解析传输的具体内容了，即binder_txn的data域所指向的那部分内容。

为了解析具体内容，binder_parse()声明了两个类型为binder_io的局部变量：msg和reply。从binder_io这个类型的名字，我们就可以看出要用它来读取binder传递来的数据了。其实，为了便于读取binder_io所指代的内容，工程提供了一系列以bio_打头的辅助函数。在读取实际数据之前，我们必须先调用bio_init_from_txn()，把binder_io变量（比如msg变量）和binder_txn所指代的缓冲区联系起来。示意图如下：

从图中可以看到，binder_io结构已经用binder_txn结构初始化了自己，以后我们就可以调用类似bio_get_uint32()、bio_get_string16()这样的函数，来读取这块buffer了。

4.2 svcmgr_handler()回调函数

初始化后的binder_io数据，就可以传给svcmgr_handler()回调函数做进一步的解析了。

此时我们可以调用下面这些辅助函数进行读写：

void bio_put_uint32(struct binder_io *bio, uint32_t n)
void bio_put_obj(struct binder_io *bio, void *ptr)
uint32_t bio_get_uint32(struct binder_io *bio)
uint16_t *bio_get_string16(struct binder_io *bio, unsigned *sz)
void *bio_get_ref(struct binder_io *bio)
. . . . . .

其中，bio_get_xxx()函数在读取数据时，是以binder_io的data域为读取光标的，每读取一些数据，data值就会增加，并且data_avail域会相应减少。而data0域的值则保持不变，一直指着数据区最开始的位置，它的作用就是作为计算偏移量的基准值。

bio_get_uint32()非常简单，会从binder_io.data所指的地方，读取4个字节的内容。bio_get_string16()就稍微复杂一点儿，先要读取一个32bits的整数，这个整数值就是字符串的长度，因为字符串都要包含最后一个’\0’，所以需要读取((len + 1) * sizeof(uint16_t))字节的内容。还有一个是bio_get_ref()，它会读取一个binder_object结构。binder_object的定义如下：

struct binder_object
{
    uint32_t type;
    uint32_t flags;
    void *pointer;
    void *cookie;
};

在svcmgr_handler()函数中，一个传输语义码（txn->code）可能会对应几次bio_get操作，比如后文我们要说的SVC_MGR_ADD_SERVICE语义码。具体情况请大家参考svcmgr_handler()的代码。svcmgr_handler()的调用示意图如下：

 

4.2.1 如何解析add service

我们先研究add service的动作。前文我们已经介绍过，service manager进程里有一个全局性的svclist变量，记录着所有添加进系统的“service代理”信息，这些信息被组织成一条单向链表，即“服务向量表”。现在我们要看service manager是如何向这张表中添加新节点的。

假设某个服务进程调用Service Manager Service接口，向其注册service。这个注册动作到最后就会走到svcmgr_handler()的case SVC_MGR_ADD_SERVICE分支。此时会先获取三个数据，而后再调用do_add_service()函数，代码如下：

uint16_t *    s;
void *        ptr;
. . . . . .
s = bio_get_string16(msg, &len);
ptr = bio_get_ref(msg);
allow_isolated = bio_get_uint32(msg) ? 1 : 0;
do_add_service(bs, s, len, ptr, txn->sender_euid);

也就是说，当binder_txn的code为SVC_MGR_ADD_SERVICE时，binder_txn所指的数据区域中应该包含一个字符串，一个binder对象以及一个uint32数据。示意图如下：

其中那个binder_object，记录的就是新注册的service所对应的代理信息。此时binder_object的pointer域实际上已经不是指针值了，而是一个binder句柄值。

do_add_service()的函数截选如下：

struct svcinfo *svclist = 0;    // 核心service链表（即服务向量表）

int do_add_service(struct binder_state *bs, uint16_t *s, unsigned len,
                       void *ptr, unsigned uid)
{
    struct svcinfo *si;

    if (!ptr || (len == 0) || (len > 127))
        return -1;

    if (!svc_can_register(uid, s)) {
        ALOGE("add_service('%s',%p) uid=%d - PERMISSION DENIED\n",
             str8(s), ptr, uid);
        return -1;
    }
    si = find_svc(s, len);
    if (si) {
        if (si->ptr) {
            svcinfo_death(bs, si);
        }
        si->ptr = ptr;
    } else {
        // 新创建一个svcinfo节点。
        si = malloc(sizeof(*si) + (len + 1) * sizeof(uint16_t));
        if (!si) {
            return -1;
        }
        si->ptr = ptr;    // 在svcinfo节点的ptr域中，记录下service对应的binder句柄值
        si->len = len;
        memcpy(si->name, s, (len + 1) * sizeof(uint16_t));
        si->name[len] = '\0';
        si->death.func = svcinfo_death;
        si->death.ptr = si;

        // 把新节点插入svclist链表
        si->next = svclist;
        svclist = si;
    }

    binder_acquire(bs, ptr);
    binder_link_to_death(bs, ptr, &si->death);
    return 0;
}

现在我们来解读这部分代码。首先，并不是随便找个进程就能向系统注册service噢。do_add_service()函数一开始先调用svc_can_register()，判断发起端是否可以注册service。如果不可以，do_add_service()就返回-1值。svc_can_register()的代码如下：

int svc_can_register(unsigned uid, uint16_t *name)
{
    unsigned n;

    if ((uid == 0) || (uid == AID_SYSTEM))
        return 1;

    for (n = 0; n < sizeof(allowed) / sizeof(allowed[0]); n++)
        if ((uid == allowed[n].uid) && str16eq(name, allowed[n].name))
            return 1;

    return 0;
}

上面的代码表示，如果发起端是root进程或者system server进程的话，是可以注册service的，另外，那些在allowed[]数组中有明确记录的用户进程，也是可以注册service的，至于其他绝大部分普通进程，很抱歉，不允许注册service。在以后的软件开发中，我们有可能需要编写新的带service的用户进程（uid不为0或AID_SYSTEM），并且希望把service注册进系统，此时不要忘了修改allowed[]数组。下面是allowed[]数组的一部分截选：

static struct {
    unsigned uid;
    const char *name;
} allowed[] = {
    { AID_MEDIA, "media.audio_flinger" },
    { AID_MEDIA, "media.player" },
    { AID_MEDIA, "media.camera" },
    . . . . . .

接下来，do_add_service()开始尝试在service链表里查询对应的service是否已经添加过了。如果可以查到，那么就不用生成新的service节点了。否则就需要在链表起始处再加一个新节点。节点类型为svcinfo。请注意上面代码的si->ptr = ptr一句，此时的ptr参数其实来自于前文所说的binder_object的pointer域。

为了说明问题，我们重新列一下刚刚的case SVC_MGR_ADD_SERVICE代码：

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;

那个ptr来自于bio_get_ref(msg)，而bio_get_ref()的实现代码如下：

void *bio_get_ref(struct binder_io *bio)
{
    struct binder_object *obj;

    obj = _bio_get_obj(bio);
    if (!obj)
        return 0;

    if (obj->type == BINDER_TYPE_HANDLE)
        return obj->pointer;

    return 0;
}

因为现在是要向service manager注册服务，所以obj->type一定是BINDER_TYPE_HANDLE，也就是说会返回binder_object的pointer域。这个域的类型虽为void*，实际上换成uint32可能更合适。通过这个binder句柄值，我们最终可以找到远端的具体service实体。

 

4.2.2 如何解析get service

现在我们接着来看get service动作。我们知道，在service被注册进service manager之后，其他应用都可以调用ServiceManager的getService()来获取相应的服务代理，并调用代理的成员函数。这个getService()函数最终会向service manager进程发出SVC_MGR_GET_SERVICE命令，并由svcmgr_handler()函数这样处理：

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;

一开始从msg中读取希望get的服务名，然后调用do_find_service()函数查询服务名对应的句柄值，最后把句柄值写入reply。do_find_service()的代码如下：

void *do_find_service(struct binder_state *bs, uint16_t *s, unsigned len, unsigned uid)
{
    struct svcinfo *si;
    si = find_svc(s, len);

    if (si && si->ptr)
    {
        if (!si->allow_isolated)
        {
            unsigned appid = uid % AID_USER;
            if (appid >= AID_ISOLATED_START && appid <= AID_ISOLATED_END)
            {
                return 0;
            }
        }
        return si->ptr;    // 返回service代理的句柄！
    }
    else
    {
        return 0;
    }
}

可以看到，do_find_service()返回的就是所找到的服务代理对应的句柄值（si->ptr）。而svcmgr_handler()在拿到这个句柄值后，会把它写入reply对象：

bio_put_ref(reply, ptr);

bio_put_ref()的代码如下：

void bio_put_ref(struct binder_io *bio, void *ptr)
{
    struct binder_object *obj;

    if (ptr)
        obj = bio_alloc_obj(bio);
    else
        obj = bio_alloc(bio, sizeof(*obj));

    if (!obj)
        return;

    obj->flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS;
    obj->type = BINDER_TYPE_HANDLE;
    obj->pointer = ptr;
    obj->cookie = 0;
}

bio_alloc_obj()一句说明会从reply所关联的buffer中划分出一个binder_object区域，然后开始对这个区域写值。于是BINDER_TYPE_HANDLE赋给了obj->type，句柄值赋给了obj->pointer。另外，reply所关联的buffer只是binder_parse()里的局部数组噢：

unsigned rdata[256/4];

大家应该还记得svcmgr_handler()是被binder_parse()回调的，当svcmgr_handler()返回后，会接着把整理好的reply对象send出去：

                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);

也就是把查找到的信息，发送给发起查找的一方。

binder_send_reply()的代码如下：

void binder_send_reply(struct binder_state *bs, struct binder_io *reply,
                            void *buffer_to_free, int status)
{
    struct
    {
        uint32_t cmd_free;
        void *buffer;
        uint32_t cmd_reply;
        struct binder_txn txn;
    } __attribute__((packed)) data;

    data.cmd_free = BC_FREE_BUFFER;
    data.buffer = buffer_to_free;
    data.cmd_reply = BC_REPLY;
    data.txn.target = 0;
    data.txn.cookie = 0;
    data.txn.code = 0;

    if (status)
    {
        data.txn.flags = TF_STATUS_CODE;
        data.txn.data_size = sizeof(int);
        data.txn.offs_size = 0;
        data.txn.data = &status;
        data.txn.offs = 0;
    }
    else
    {
        data.txn.flags = 0;
        data.txn.data_size = reply->data - reply->data0;
        data.txn.offs_size = ((char*) reply->offs) - ((char*) reply->offs0);
        data.txn.data = reply->data0;
        data.txn.offs = reply->offs0;
    }
    binder_write(bs, &data, sizeof(data));
}

观察代码中最后那几行，看来还是在摆弄reply所指代的那个buffer。当初binder_parse()在创建reply对象之时，就给它初始化了一个局部buffer，即前文所说的unsigned rdata[256/4]，在svcmgr_handler()中又调用bio_put_ref()在这个buffer中开辟了一块binder_object，并在其中赋予了ptr句柄。现在终于要向binder驱动传递reply信息了，此时调用的binder_write()的代码如下：

int binder_write(struct binder_state *bs, void *data, unsigned len)
{
    struct binder_write_read bwr;
    int res;
    bwr.write_size = len;
    bwr.write_consumed = 0;
    bwr.write_buffer = (unsigned) data;
    bwr.read_size = 0;
    bwr.read_consumed = 0;
    bwr.read_buffer = 0;
    res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
    if (res < 0) {
        fprintf(stderr,"binder_write: ioctl failed (%s)\n",
                strerror(errno));
    }
    return res;
}

噢，又见ioctl()，数据就在bwr.write_buffer，数据里打出了两个binder命令，BC_FREE_BUFFER和BC_REPLY。

这些数据被传递给get service动作的发起端，虽然这些数据会被binder驱动做少许修改，不过语义是不会变的，于是发起端就获得了所查service的合法句柄。

5.小结

至此，有关ServiceManager的基本知识就大体交代完毕了，文行于此，暂告段落。必须承认，受限于个人的认识和文章的篇幅，我不可能涉及其中所有的细节，这里只能摘其重点进行阐述。如果以后又发现什么有趣的东西，我还会补充进来。

转自http://blog.csdn.net/codefly/article/details/17058643