binder 从c到java_Binder机制情景分析之C服务应用

落日映苍穹つ 2022-11-07 14:47 241阅读 0赞

一. 概述

这里只讲下binder的实现原理，不牵扯到android的java层是如何调用;

涉及到的会有ServiceManager,led\_control\_server和test\_client的代码,这些都是用c写的.其中led\_control\_server和test\_client是

仿照bctest.c写的; 在linux平台下运行binder更容易分析binder机制实现的原理(可以增加大量的log,进行分析);

在Linux运行时.先运行ServiceManager,再运行led\_control\_server最后运行test\_client;

1.1 Binder通信模型

Binder通信采用C/S架构，从组件视角来说，包含Client、Server、ServiceManager以及binder驱动，其中ServiceManager用于管理系统中的各种服务。

1.2 运行环境

本文中的代码运行环境是在imx6ul上跑的，运行的是linux系统，内核版本4.10(非android环境分析);

1.3 文章代码

文章所有代码已上传

二. ServiceManager

涉及到的源码地址:

frameworks/native/cmds/servicemanager/sevice\_manager.c

frameworks/native/cmds/servicemanager/binder.c

frameworks/native/cmds/servicemanager/bctest.c

ServiceManager相当于binder通信过程中的守护进程，本身也是个binder服务、好比一个root管理员一样;

主要功能是查询和注册服务;接下来结合代码从main开始分析下serviceManager的服务过程;

2.1 main

源码中的sevice\_manager.c中主函数中使用了selinux，为了在我板子的linux环境中运行，把这些代码屏蔽，删减后如下：

int main(int argc, char \*\*argv)

struct binder\_state \*bs;

bs = binder\_open(128\*1024); ①

if (!bs) \{

ALOGE("failed to open binder driver\\n");

return -1;

if (binder\_become\_context\_manager(bs)) \{ ②

ALOGE("cannot become context manager (%s)\\n", strerror(errno));

return -1;

svcmgr\_handle = BINDER\_SERVICE\_MANAGER;

binder\_loop(bs, svcmgr\_handler); ③

return 0;

①: 打开binder驱动(详见2.2.1)

②: 注册为管理员(详见2.2.2)

③: 进入循环，处理消息(详见2.2.3)

从主函数的启动流程就能看出sevice\_manager的工作流程并不是特别复杂;

其实client和server的启动流程和manager的启动类似，后面再详细分析;

2.2 binder\_open

struct binder\_state \*binder\_open(size\_t mapsize)

struct binder\_state \*bs;

struct binder\_version vers;

bs = malloc(sizeof(\*bs));

if (!bs) \{

errno = ENOMEM;

return NULL;

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

if (bs->fd < 0) \{

fprintf(stderr,"binder: cannot open device (%s)\\n",

strerror(errno));

goto fail\_open;

if ((ioctl(bs->fd, BINDER\_VERSION, &vers) == -1) || ②

(vers.protocol\_version != BINDER\_CURRENT\_PROTOCOL\_VERSION)) \{

fprintf(stderr, "binder: driver version differs from user space\\n");

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;

return bs;

fail\_map:

close(bs->fd);

fail\_open:

free(bs);

return NULL;

①: 打开binder设备

②: 通过ioctl获取binder版本号

③: mmp内存映射

这里说明下为什么binder驱动是用ioctl来操作，是因为ioctl可以同时进行读和写操作；

2.2 binder\_become\_context\_manager

int binder\_become\_context\_manager(struct binder\_state \*bs)

return ioctl(bs->fd, BINDER\_SET\_CONTEXT\_MGR, 0);

还是通过ioctl请求类型BINDER\_SET\_CONTEXT\_MGR注册成manager;

2.3 binder\_loop

void binder\_loop(struct binder\_state \*bs, binder\_handler func)

int res;

struct binder\_write\_read bwr;

uint32\_t readbuf\[32\];

bwr.write\_size = 0;

bwr.write\_consumed = 0;

bwr.write\_buffer = 0;

readbuf\[0\] = BC\_ENTER\_LOOPER;

binder\_write(bs, readbuf, sizeof(uint32\_t)); ①

for (;;) \{

bwr.read\_size = sizeof(readbuf);

bwr.read\_consumed = 0;

bwr.read\_buffer = (uintptr\_t) 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, (uintptr\_t) 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;

①: 写入命令BC\_ENTER\_LOOPER通知驱动该线程已经进入主循环，可以接收数据;

②: 先读一次数据，因为刚才写过一次;

③: 然后解析读出来的数据(详见2.2.4);

binder\_loop函数的主要流程如下:

![5095c7134179129874aa55a36b824701.png][]

2.4 binder\_parse

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:

/\* check服务 \*/

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\_SPAWN\_LOOPER: \{

/\* create new thread \*/

//if (fork() == 0) \{

//\}

pthread\_t thread;

struct binder\_thread\_desc btd;

btd.bs = bs;

btd.func = func;

pthread\_create(&thread, NULL, binder\_thread\_routine, &btd);

/\* in new thread: ioctl(BC\_ENTER\_LOOPER), enter binder\_looper \*/

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;

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;

①: 按照一定的格式初始化rdata数据,请注意这里rdata是在用户空间创建的buf;

②: 调用设置进来的处理函数svcmgr\_handler(详见2.2.5);

③: 发送回复信息;

这个函数我们只重点关注下BR\_TRANSACTION其他的命令含义可以参考表格A;

2.5 svcmgr\_handler

int svcmgr\_handler(struct binder\_state \*bs,

struct binder\_transaction\_data \*txn,

struct binder\_io \*msg,

struct binder\_io \*reply)

struct svcinfo \*si;

uint16\_t \*s;

size\_t len;

uint32\_t handle;

uint32\_t strict\_policy;

int allow\_isolated;

//ALOGI("target=%x code=%d pid=%d uid=%d\\n",

// txn->target.handle, txn->code, txn->sender\_pid, txn->sender\_euid);

if (txn->target.handle != svcmgr\_handle)

return -1;

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

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;

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;

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;

①: 获取帧头数据,一般为0，因为发送方发送数据时都会在数据最前方填充4个字节0数据(分配数据空间的最小单位4字节);

②: 对比svcmgr\_id是否和我们原来定义相同\#define SVC\_MGR\_NAME "linux.os.ServiceManager"(我改写了);

③: 根据code 做对应的事情,就想到与根据编码去执行对应的fun(client请求服务后去执行服务，service也是根据不同的code来执行。接下来会举例说明);、

④: 从服务名在server链表中查找对应的服务，并返回handle(详见2.2.6);

⑤: 添加服务，一般都是service发起的请求。将handle和服务名添加到服务链表中(这里的handle是由binder驱动分配);

⑥: 查找server\_manager中链表中第n个服务的名字(该数值由查询端决定);

2.6 do\_find\_service

uint32\_t do\_find\_service(struct binder\_state \*bs, const uint16\_t \*s, size\_t len, uid\_t uid, pid\_t spid)

struct svcinfo \*si;

if (!svc\_can\_find(s, len, spid)) \{ ①

ALOGE("find\_service('%s') uid=%d - PERMISSION DENIED\\n",

str8(s, len), uid);

return 0;

si = find\_svc(s, len); ②

//ALOGI("check\_service('%s') handle = %x\\n", str8(s, len), si ? si->handle : 0);

if (si && si->handle) \{

if (!si->allow\_isolated) \{ ③

// If this service doesn't allow access from isolated processes,

// then check the uid to see if it is isolated.

uid\_t appid = uid % AID\_USER;

if (appid >= AID\_ISOLATED\_START && appid <= AID\_ISOLATED\_END) \{

return 0;

return si->handle; ④

\} else \{

return 0;

①: 检测调用进程是否有权限请求服务(这里用selinux管理权限,为了让代码可以方便允许,这里面的代码有做删减);

②: 遍历server\_manager服务链表;

③: 如果binder服务不允许服务从沙箱中访问,则执行下面检查;

④: 返回查询到handle;

do\_find\_service函数主要工作是搜索服务链表,返回查找到的服务

2.7 do\_add\_service

int do\_add\_service(struct binder\_state \*bs,

const uint16\_t \*s, size\_t len,

uint32\_t handle, uid\_t uid, int allow\_isolated,

pid\_t spid)

struct svcinfo \*si;

//ALOGI("add\_service('%s',%x,%s) uid=%d\\n", str8(s, len), handle,

// allow\_isolated ? "allow\_isolated" : "!allow\_isolated", uid);

if (!handle || (len == 0) || (len > 127))

return -1;

if (!svc\_can\_register(s, len, spid)) \{ ①

ALOGE("add\_service('%s',%x) uid=%d - PERMISSION DENIED\\n",

str8(s, len), handle, uid);

return -1;

si = find\_svc(s, len); ②

if (si) \{

if (si->handle) \{

ALOGE("add\_service('%s',%x) uid=%d - ALREADY REGISTERED, OVERRIDE\\n",

str8(s, len), handle, uid);

svcinfo\_death(bs, si);

si->handle = handle;

\} else \{ ③

si = malloc(sizeof(\*si) + (len + 1) \* sizeof(uint16\_t));

if (!si) \{

ALOGE("add\_service('%s',%x) uid=%d - OUT OF MEMORY\\n",

str8(s, len), handle, uid);

return -1;

si->handle = handle;

si->len = len;

memcpy(si->name, s, (len + 1) \* sizeof(uint16\_t));

si->name\[len\] = '\\0';

si->death.func = (void\*) svcinfo\_death;

si->death.ptr = si;

si->allow\_isolated = allow\_isolated;

si->next = svclist;

svclist = si;

ALOGI("add\_service('%s'), handle = %d\\n", str8(s, len), handle);

binder\_acquire(bs, handle); ④

binder\_link\_to\_death(bs, handle, &si->death); ⑤

return 0;

①: 判断请求进程是否有权限注册服务;

②: 查找ServiceManager的服务链表中是否已经注册了该服务,如果有则通知驱动杀死原先的binder服务,然后更新最新的binder服务;

③: 如果原来没有创建该binder服务,则进行一系列的赋值,再插入到服务链表的表头;

④: 增加binder服务的引用计数;

⑤: 告诉驱动接收服务的死亡通知;

2.8 调用时序图

从上面分析,可以知道ServiceManager的主要工作流程如下:

![a41e21fb1add36d03085baf50599ff16.png][]

三. led\_control\_server

3.1 main

int main(int argc, char \*\*argv)

int fd;

struct binder\_state \*bs;

uint32\_t svcmgr = BINDER\_SERVICE\_MANAGER;

uint32\_t handle;

int ret;

struct register\_server led\_control\[3\] = \{ ①

\[0\] = \{

.code = 1,

.fun = led\_on

\} ,

\[1\] = \{

.code = 2,

.fun = led\_off

\};

bs = binder\_open(128\*1024); ②

if (!bs) \{

ALOGE("failed to open binder driver\\n");

return -1;

ret = svcmgr\_publish(bs, svcmgr, LED\_CONTROL\_SERVER\_NAME, led\_control); ③

if (ret) \{

ALOGE("failed to publish %s service\\n", LED\_CONTROL\_SERVER\_NAME);

return -1;

binder\_set\_maxthreads(bs, 10); ④

binder\_loop(bs, led\_control\_server\_handler); ⑤

return 0;

①: led\_control\_server提供的服务函数;

②: 初始化binder组件( 详见2.2);

③: 注册服务,svcmgr是发送的目标, LED\_CONTROL\_SERVER\_NAME注册的服务名, led\_control注册的binder实体;

④: 设置创建线程最大数(详见3.5);

⑤: 进入线程循环(详见2.3);

3.2 svcmgr\_publish

int svcmgr\_publish(struct binder\_state \*bs, uint32\_t target, const char \*name, void \*ptr)

int status;

unsigned iodata\[512/4\];

struct binder\_io msg, reply;

bio\_init(&msg, iodata, sizeof(iodata), 4); ①

bio\_put\_uint32(&msg, 0); // strict mode header

bio\_put\_string16\_x(&msg, SVC\_MGR\_NAME);

bio\_put\_string16\_x(&msg, name);

bio\_put\_obj(&msg, ptr);

if (binder\_call(bs, &msg, &reply, target, SVC\_MGR\_ADD\_SERVICE)) ②

return -1;

status = bio\_get\_uint32(&reply); ③

binder\_done(bs, &msg, &reply); ④

return status;

①: 初始化用户空间的数据iodata,设置了四个字节的offs,接着按一定格式往buf里面填充数据;

②: 调用ServiceManager服务的SVC\_MGR\_ADD\_SERVICE功能;

③: 获取ServiceManager回复数据,成功返回0;

④: 结束注册过程,释放内核中刚才交互分配的buf;

3.2.1 bio\_init

void bio\_init(struct binder\_io \*bio, void \*data,

size\_t maxdata, size\_t maxoffs)

size\_t n = maxoffs \* sizeof(size\_t);

if (n > maxdata) \{

bio->flags = BIO\_F\_OVERFLOW;

bio->data\_avail = 0;

bio->offs\_avail = 0;

return;

bio->data = bio->data0 = (char \*) data + n; ①

bio->offs = bio->offs0 = data; ②

bio->data\_avail = maxdata - n; ③

bio->offs\_avail = maxoffs; ④

bio->flags = 0; ⑤

①: 根据传进来的参数,留下一定长度的offs数据空间, data指针则从data + n开始;

②: offs指针则从data开始,则offs可使用的数据空间只有n个字节;

③: 可使用的data空间计数;

④: 可使用的offs空间计数;

⑤: 清除buf的flag;

init后此时buf空间的分配情况如下图:

![1190000017074746][]

3.2.2 bio\_put\_uint32

void bio\_put\_uint32(struct binder\_io \*bio, uint32\_t n)

uint32\_t \*ptr = bio\_alloc(bio, sizeof(n));

if (ptr)

\*ptr = n;

这个函数往buf里面填充一个uint32的数据,这个数据的最小单位为4个字节;

前面svcmgr\_publish调用bio\_put\_uint32(&msg, 0);,实质buf中的数据是00 00 00 00 ;

3.2.3 bio\_alloc

static void \*bio\_alloc(struct binder\_io \*bio, size\_t size)

size = (size + 3) & (~3);

if (size > bio->data\_avail) \{

bio->flags |= BIO\_F\_OVERFLOW;

return NULL;

\} else \{

void \*ptr = bio->data;

bio->data += size;

bio->data\_avail -= size;

return ptr;

这个函数分配的数据宽度为4的倍数,先判断当前可使用的数据宽度是否小于待分配的宽度;

如果小于则置标志BIO\_F\_OVERFLOW否则分配数据,并对data往后偏移size个字节,可使用数据宽度data\_avail减去size个字节;

3.2.4 bio\_put\_string16\_x

void bio\_put\_string16\_x(struct binder\_io \*bio, const char \*\_str)

unsigned char \*str = (unsigned char\*) \_str;

size\_t len;

uint16\_t \*ptr;

if (!str) \{ ①

bio\_put\_uint32(bio, 0xffffffff);

return;

len = strlen(\_str);

if (len >= (MAX\_BIO\_SIZE / sizeof(uint16\_t))) \{

bio\_put\_uint32(bio, 0xffffffff);

return;

/\* Note: The payload will carry 32bit size instead of size\_t \*/

bio\_put\_uint32(bio, len); ②

ptr = bio\_alloc(bio, (len + 1) \* sizeof(uint16\_t));

if (!ptr)

return;

while (\*str) ③

\*ptr++ = \*str++;

\*ptr++ = 0;

①: 这里到bio\_alloc前都是为了计算和判断自己串的长度再填充到buf中;

②: 填充字符串前会填充字符串的长度;

③: 填充字符串到buf中,一个字符占两个字节,注意uint16\_t \*ptr;;

3.2.5 bio\_put\_obj

void bio\_put\_obj(struct binder\_io \*bio, void \*ptr)

struct flat\_binder\_object \*obj;

obj = bio\_alloc\_obj(bio); ①

if (!obj)

return;

obj->flags = 0x7f | FLAT\_BINDER\_FLAG\_ACCEPTS\_FDS;

obj->type = BINDER\_TYPE\_BINDER; ②

obj->binder = (uintptr\_t)ptr; ③

obj->cookie = 0;

struct flat\_binder\_object \{

/\* WARNING: DO NOT EDIT, AUTO-GENERATED CODE - SEE TOP FOR INSTRUCTIONS \*/

\_\_u32 type;

\_\_u32 flags;

union \{

binder\_uintptr\_t binder;

/\* WARNING: DO NOT EDIT, AUTO-GENERATED CODE - SEE TOP FOR INSTRUCTIONS \*/

\_\_u32 handle;

\};

binder\_uintptr\_t cookie;

\};

①: 分配一个flat\_binder\_object大小的空间(详见3.2.6);

②: type的类型为BINDER\_TYPE\_BINDER时则type传入的是binder实体,一般是服务端注册服务时传入;

type的类型为BINDER\_TYPE\_HANDLE时则type传入的为handle,一般由客户端请求服务时;

③: obj->binder值,跟随type改变;

3.2.6 bio\_alloc\_obj

static struct flat\_binder\_object \*bio\_alloc\_obj(struct binder\_io \*bio)

struct flat\_binder\_object \*obj;

obj = bio\_alloc(bio, sizeof(\*obj)); ①

if (obj && bio->offs\_avail) \{

bio->offs\_avail--;

\*bio->offs++ = ((char\*) obj) - ((char\*) bio->data0); ②

return obj;

bio->flags |= BIO\_F\_OVERFLOW;

return NULL;

①: 在data后分配struct flat\_binder\_object长度的空间;

②: bio->offs空间记下此时插入obj,相对于data0的偏移值;

看到这终于知道offs是干嘛的了,原来是用来记录数据中是否有obj类型的数据;

3.2.7 完整数据格式图

综上分析,传输一次完整的数据的格式如下:

![00832e601d87a1716a1aaa04936fd219.png][]

3.3 binder\_call

int binder\_call(struct binder\_state \*bs,

struct binder\_io \*msg, struct binder\_io \*reply,

uint32\_t target, uint32\_t code)

int res;

struct binder\_write\_read bwr;

struct \{

uint32\_t cmd;

struct binder\_transaction\_data txn;

\} \_\_attribute\_\_((packed)) writebuf;

unsigned readbuf\[32\];

if (msg->flags & BIO\_F\_OVERFLOW) \{

fprintf(stderr,"binder: txn buffer overflow\\n");

goto fail;

writebuf.cmd = BC\_TRANSACTION; // binder call transaction

writebuf.txn.target.handle = target; ①

writebuf.txn.code = code; ②

writebuf.txn.flags = 0;

writebuf.txn.data\_size = msg->data - msg->data0; ③

writebuf.txn.offsets\_size = ((char\*) msg->offs) - ((char\*) msg->offs0);

writebuf.txn.data.ptr.buffer = (uintptr\_t)msg->data0;

writebuf.txn.data.ptr.offsets = (uintptr\_t)msg->offs0;

bwr.write\_size = sizeof(writebuf); ④

bwr.write\_consumed = 0;

bwr.write\_buffer = (uintptr\_t) &writebuf;

for (;;) \{

bwr.read\_size = sizeof(readbuf);

bwr.read\_consumed = 0;

bwr.read\_buffer = (uintptr\_t) readbuf;

res = ioctl(bs->fd, BINDER\_WRITE\_READ, &bwr); ⑤

if (res < 0) \{

fprintf(stderr,"binder: ioctl failed (%s)\\n", strerror(errno));

goto fail;

res = binder\_parse(bs, reply, (uintptr\_t) readbuf, bwr.read\_consumed, 0); ⑥

if (res == 0) return 0;

if (res < 0) goto fail;

fail:

memset(reply, 0, sizeof(\*reply));

reply->flags |= BIO\_F\_IOERROR;

return -1;

①: 这个target就是我们这次请求服务的目标,即ServiceManager;

②: code是我们请求服务的功能码,由服务端提供;

③: 把binder\_io数据转化成binder\_transaction\_data数据;

④: 驱动进行读写是根据这个size来的,分析驱动的时候再详细分析;

⑤: 进行一次读写;

⑥: 解析发送的后返回的数据,判断是否注册成功;

3.4 binder\_done

void binder\_done(struct binder\_state \*bs,

struct binder\_io \*msg,

struct binder\_io \*reply)

struct \{

uint32\_t cmd;

uintptr\_t buffer;

\} \_\_attribute\_\_((packed)) data;

if (reply->flags & BIO\_F\_SHARED) \{

data.cmd = BC\_FREE\_BUFFER;

data.buffer = (uintptr\_t) reply->data0;

binder\_write(bs, &data, sizeof(data));

reply->flags = 0;

这个函数比较简单发送BC\_FREE\_BUFFER命令给驱动,让驱动释放内核态由刚才交互分配的buf;

3.5 binder\_set\_maxthreads

void binder\_set\_maxthreads(struct binder\_state \*bs, int threads)

ioctl(bs->fd, BINDER\_SET\_MAX\_THREADS, &threads);

这里主要调用ioctl函数写入命令BINDER\_SET\_MAX\_THREADS进行设置最大线程数;

3.6 调用时序图

led\_control\_server主要提供led的控制服务,具体的流程如下:

![d16b7c35d71a153266719f9027785437.png][]

四. test\_client

4.1 main

int main(int argc, char \*\*argv)

struct binder\_state \*bs;

uint32\_t svcmgr = BINDER\_SERVICE\_MANAGER;

unsigned int g\_led\_control\_handle;

if (argc < 3) \{

ALOGE("Usage:\\n");

ALOGE("%s led \\n", argv\[0\]);

return -1;

bs = binder\_open(128\*1024); ①

if (!bs) \{

ALOGE("failed to open binder driver\\n");

return -1;

g\_led\_control\_handle = svcmgr\_lookup(bs, svcmgr, LED\_CONTROL\_SERVER\_NAME); ②

if (!g\_led\_control\_handle) \{

ALOGE( "failed to get led control service\\n");

return -1;

ALOGI("Handle for led control service = %d\\n", g\_led\_control\_handle);

if (!strcmp(argv\[1\], "led")) \{

if (!strcmp(argv\[2\], "on")) \{

if (interface\_led\_on(bs, g\_led\_control\_handle, 2) == 0) \{ ③

ALOGI("led was on\\n");

\} else if (!strcmp(argv\[2\], "off")) \{

if (interface\_led\_off(bs, g\_led\_control\_handle, 2) == 0) \{

ALOGI("led was off\\n");

binder\_release(bs, g\_led\_control\_handle); ④

return 0;

①: 打开binder设备(详见2.2);

②: 根据名字获取led控制服务;

③: 根据获取到的handle,调用led控制服务(详见4.3);

④: 释放服务;

client的流程也很简单,按步骤1.2.3.4读下来就是了;

4.2 svcmgr\_lookup

uint32\_t svcmgr\_lookup(struct binder\_state \*bs, uint32\_t target, const char \*name)

uint32\_t handle;

unsigned iodata\[512/4\];

struct binder\_io msg, reply;

bio\_init(&msg, iodata, sizeof(iodata), 4); ①

bio\_put\_uint32(&msg, 0); // strict mode header

bio\_put\_string16\_x(&msg, SVC\_MGR\_NAME);

bio\_put\_string16\_x(&msg, name);

if (binder\_call(bs, &msg, &reply, target, SVC\_MGR\_GET\_SERVICE)) ②

return 0;

handle = bio\_get\_ref(&reply); ③

if (handle)

binder\_acquire(bs, handle); ④

binder\_done(bs, &msg, &reply); ⑤

return handle;

①: 因为是请求服务,所以这里不用添加binder实体数据,具体的参考3.2,这里就不重复解释了;

②: 向target进程(ServiceManager)请求获取led\_control服务(详细参考3.3);

③: 从ServiceManager返回的数据buf中获取led\_control服务的handle;

④: 增加该handle的引用计数;

⑤: 释放内核空间buf(详3.4);

4.2.1 bio\_get\_ref

uint32\_t bio\_get\_ref(struct binder\_io \*bio)

struct flat\_binder\_object \*obj;

obj = \_bio\_get\_obj(bio); ①

if (!obj)

return 0;

if (obj->type == BINDER\_TYPE\_HANDLE) ②

return obj->handle;

return 0;

①: 把bio的数据转化成flat\_binder\_object格式;

②: 判断binder数据类型是否为引用,是则返回获取到的handle;

4.2.2 \_bio\_get\_obj

static struct flat\_binder\_object \*\_bio\_get\_obj(struct binder\_io \*bio)

size\_t n;

size\_t off = bio->data - bio->data0; ①

/\* TODO: be smarter about this? \*/

for (n = 0; n < bio->offs\_avail; n++) \{

if (bio->offs\[n\] == off)

return bio\_get(bio, sizeof(struct flat\_binder\_object)); ②

bio->data\_avail = 0;

bio->flags |= BIO\_F\_OVERFLOW;

return NULL;

①: 一般情况下该值都为0,因为在reply时获取ServiceManager传来的数据,bio->data和bio->data都指向同一个地址;

②: 获取到struct flat\_binder\_object数据的头指针;

从ServiceManager传来的数据是struct flat\_binder\_object的数据,格式如下:

![1190000017074746][]

4.3 interface\_led\_on

int interface\_led\_on(struct binder\_state \*bs, unsigned int handle, unsigned char led\_enum)

unsigned iodata\[512/4\];

struct binder\_io msg, reply;

int ret = -1;

int exception;

bio\_init(&msg, iodata, sizeof(iodata), 4);

bio\_put\_uint32(&msg, 0); // strict mode header

bio\_put\_uint32(&msg, led\_enum);

if (binder\_call(bs, &msg, &reply, handle, LED\_CONTROL\_ON))

return ret;

exception = bio\_get\_uint32(&reply);

if (exception == 0)

ret = bio\_get\_uint32(&reply);

binder\_done(bs, &msg, &reply);

return ret;

这个流程和前面svcmgr\_lookup的请求服务差不多,只是最后是获取led\_control\_server的返回值.

注意这里为什么获取了两次uint32类型的数据,这是因为服务方在回复数据的时候添加了头帧,这个是可以调节的,非规则;

4.4 binder\_release

void binder\_release(struct binder\_state \*bs, uint32\_t target)

uint32\_t cmd\[2\];

cmd\[0\] = BC\_RELEASE;

cmd\[1\] = target;

binder\_write(bs, cmd, sizeof(cmd));

通知驱动层减小对target进程的引用,结合驱动讲解就更能明白了;

4.5 调用时序图

test\_client的调用时序如下,过程和led\_control\_server的调用过程相识:

![2ddfd3269448e8a0bacb240edf7b1487.png][]

A: 表BR\_含义

BR个人理解是缩写为binder reply

消息

含义

参数

BR\_ERROR

发生内部错误(如内存分配失败)

\---

BR\_OK

BR\_NOOP

操作完成

\---

BR\_SPAWN\_LOOPER

该消息用于接收方线程池管理。当驱动发现接收方所有

线程都处于忙碌状态且线程池里的线程总数没有超过

BINDER\_SET\_MAX\_THREADS设置的最大线程数时，

向接收方发送该命令要求创建更多线程以备接收数据。

\---

BR\_TRANSACTION

对应发送方的BC\_TRANSACTION

binder\_transaction\_data

BR\_REPLY

对应发送方BC\_REPLY的回复

binder\_transaction\_data

BR\_ACQUIRE\_RESULT

BR\_FINISHED

未使用

\---

BR\_DEAD\_REPLY

交互时向驱动发送binder调用，如果对方已经死亡，则

驱动回应此命令

\---

BR\_TRANSACTION\_COMPLETE

发送方通过BC\_TRANSACTION或BC\_REPLY发送

完一个数据包后，都能收到该消息做为成功发送的反馈。

这和BR\_REPLY不一样，是驱动告知发送方已经发送成

功，而不是Server端返回请求数据。所以不管

同步还是异步交互接收方都能获得本消息。

\---

BR\_INCREFS

BR\_ACQUIRE

BR\_RELEASE

BR\_DECREFS

这一组消息用于管理强/弱指针的引用计数。只有

提供Binder实体的进程才能收到这组消息。

binder\_uintptr\_t binder：Binder实体在用户空间中的指针

binder\_uintptr\_t cookie：与该实体相关的附加数据

BR\_DEAD\_BINDER

向获得Binder引用的进程发送Binder实体

死亡通知书；收到死亡通知书的进程接下

来会返回BC\_DEAD\_BINDER\_DONE做确认。

\---

BR\_CLEAR\_DEATH\_NOTIFICATION\_DONE

回应命令BC\_REQUEST\_DEATH\_NOTIFICATION

\---

BR\_FAILED\_REPLY

如果发送非法引用号则返回该消息

\---

B: 表BC\_含义

BC个人理解是缩写为binder call or cmd

消息

含义

参数

BC\_TRANSACTION

BC\_REPLY

BC\_TRANSACTION用于Client向Server发送请求数据；

BC\_REPLY用于Server向Client发送回复(应答)数据。

其后面紧接着一个binder\_transaction\_data结构体表明要写

入的数据。

struct binder\_transaction\_data

BC\_ACQUIRE\_RESULT

BC\_ATTEMPT\_ACQUIRE

未使用

\---

BC\_FREE\_BUFFER

请求驱动释放调刚在内核空间创建用来保存用户空间数据的内存块

\---

BC\_INCREFS

BC\_ACQUIRE

BC\_RELEASE

BC\_DECREFS

这组命令增加或减少Binder的引用计数，用以实现强指针或

弱指针的功能。

\---

BC\_INCREFS\_DONE

BC\_ACQUIRE\_DONE

第一次增加Binder实体引用计数时，驱动向Binder

实体所在的进程发送BR\_INCREFS， BR\_ACQUIRE消息；

Binder实体所在的进程处理完毕回馈BC\_INCREFS\_DONE，

BC\_ACQUIRE\_DONE

\---

BC\_REGISTER\_LOOPER

BC\_ENTER\_LOOPER

BC\_EXIT\_LOOPER

这组命令同BINDER\_SET\_MAX\_THREADS一道实现Binder驱

动对接收方线程池管理。BC\_REGISTER\_LOOPER通知驱动线程

池中一个线程已经创建了；BC\_ENTER\_LOOPER通知驱动该线程

已经进入主循环，可以接收数据；BC\_EXIT\_LOOPER通知驱动

该线程退出主循环，不再接收数据。

\---

BC\_REQUEST\_DEATH\_NOTIFICATION

获得Binder引用的进程通过该命令要求驱动在Binder实体销毁得到

通知。虽说强指针可以确保只要有引用就不会销毁实体，但这毕竟

是个跨进程的引用，谁也无法保证实体由于所在的Server关闭Binder

驱动或异常退出而消失，引用者能做的是要求Server在此刻给出通知。

\---

BC\_DEAD\_BINDER\_DONE

收到实体死亡通知书的进程在删除引用后用本命令告知驱动。

\---

参考

表格参考博客:

[5095c7134179129874aa55a36b824701.png]: /images/20221023/9012b1f2db2340b19634f82f079688a6.png
[a41e21fb1add36d03085baf50599ff16.png]: /images/20221023/382f82195b554635ac68e4b4eccb3594.png
[1190000017074746]: https://segmentfault.com/a/1190000017074746
[00832e601d87a1716a1aaa04936fd219.png]: /images/20221023/809f938b564e420eaa4707fc3712ec54.png
[d16b7c35d71a153266719f9027785437.png]: /images/20221023/95ae752a3134468a83f968277e186ae3.png
[2ddfd3269448e8a0bacb240edf7b1487.png]: /images/20221023/b9213dfe8513485abc9a5f484b5a5d2b.png