ZChongr

起点从TestClient.cpp的main函数发起：int main() { sp < IServiceManager > sm = defaultServiceManager(); sp < IBinder > binder = sm->getService(String16("service.testservice")); sp<ITestService> cs = i

驱动层为什么要篡改binder_buffer内的数据？先给出这张图： 上图中标红的部分需要重点考虑，为什么驱动层要篡改这两个字段呢？我们结合前面的文章或许可以找出端倪。在Binder学习笔记（七）—— ServiceManager如何响应addService请求 ？一文中其实留下了挺多疑问。server端调用addService(…)向ServiceManager注册该Service，Serv

binder_open(…)都干了什么？在回答binder_transaction(…)之前，还有一些基础设施要去探究，比如binder_open(…)，binder_mmap(…)，这些调用是在打开设备文件/dev/binder之后必须完成的程式化操作，而在它们内部需要做一些数据结构的准备。首先来看binder_open(…) kernel/drivers/staging/android/bin

轻量级指针Binder的学习历程爬到驱动的半山腰明显感觉越来越陡峭，停下业务层的学习，补补基础层知识吧，这首当其冲的就是智能指针了，智能指针的影子在Android源码中随处可见。打开frameworkds/rs/cpp/util，RefBase.h和StrongPointer.h两个文件，代码多读几遍都能读懂，可是串起来总感觉摸不到骨架，把不住主线。闭上眼零零星星的点串不成一条线。究其原因应该是此处

Binder驱动层的代码在kernel/goldfish/drivers/staging/android下的binder.c和binder.h。Android源码是不带Linux内核的，驱动正是在这个内核里，需要单独下载，出门左转参见《Anrdoid源码、内核编译》。驱动的相关知识先不在这里展开了，那又是一个庞大的体系，以后再啃。直奔我们的主题——客户端为test()组织的请求数据是： 驱动程

从服务端代码出发，TestServer.cppint main() { sp < ProcessState > proc(ProcessState::self()); sp < IServiceManager > sm = defaultServiceManager(); sm->addService(String16("service.testservice"), new

还从客户端代码看起TestClient.cpp:14int main() { sp < IServiceManager > sm = defaultServiceManager(); // new BpServiceManager(new BpBinder(0)); sp < IBinder > binder = sm->getService(String16("service

有了《ServiceManager如何响应checkService请求》的探索，研究addService就轻车熟路了，中间过程不再多说，仅把关键节点列出： frameworks/native/cmds/servicemanager/service_manager.c:347int main(int argc, char **argv){ …… binder_loop(bs, sv

在checkService的调查中我们知道客户端向ServiceManager请求服务名，ServiceManager根据服务名遍历本地链表，找到匹配的handle返回给客户端。这个handle显然是由服务端注册的，这个handle究竟是什么？要先搞清楚这个问题，必须研究服务端和ServiceManager是如何共同完成一次addService操作的。我们从服务端代码出发。TestService.c

前文中曾经遇到过Parcel，从命名上知道他负责数据打包。在checkService的请求/响应体系中，Parcel只打包了基本数据类型，如Int32、String16……后面还要用于打包抽象数据类型flat_binder_object，这会稍微复杂一些，因此有必要拿出来单独研究。我们从Parcel::writeInterfaceToken(…)追起，它的层层调用关系如下，这些函数都在framewo

这要从frameworks/native/cmds/servicemanager/service_manager.c:347的main函数说起，该文件编译后生成servicemanager。int main(int argc, char **argv){ struct binder_state *bs; bs = binder_open(128*1024); // 打开/dev/b

在binder请求的发起端，binder_transaction(…)函数的结尾，第#198行，它将struct binder_transaction的work字段插入target_list的尾部，然后完成发起端的工作。 在接收端binder_loop(…)函数的第#19行，也在通过调用ioctl(bs->fd, BINDER_WRITE_READ, &bwr)等待着来自发起端的请求。在驱动层