ZChongr

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

驱动层为什么要篡改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

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

之前在博客园、简书、CSDN等地儿都开过博，一篇文章写好了，我希望能在几个平台可以同步发布，可是操作起来成本不低。几个平台下的富文本编辑器比较起来还是博客园更顺手，看着更舒服，尤其是代码块的操作灵活、准确。而CSDN对代码块内的文字加粗、修改字色后就会出现html文无法解析的情况，混杂着代码和html文本实在太难看了，后来我知道原来是Markdown的代码块规则限制。而且CSDN刚刚才取消了提交文章

不管是客户端还是服务端，头部都要先调用sp sm = defaultServiceManager();defaultServiceManager()都干了什么，它返回的是什么实例呢？该函数定义在frameworks/native/libs/binder/IserviceManager.cpp:33sp defaultServiceManager(){ if

网上看了很多关于binder的文章，但我还是想把自己的心路历程记录下来，有些是跟着别人的脚步领略险峻风景，有些则是自己只身探入代码深处打捞出的收获。我不确定是否全部融会贯通，更担心一两个月后会完全不记得来时的路。最好的验证和留存的方法是把他们写成博文，几个月后回头再来读，看是否还能读得明白。如果可以，说明我两个担心已不复存在；如果又回到云里雾里，刚好可以带着新问题继续探索。文章很多地方会引用And

Android2.x中Logger日志系统采用了字符设备驱动来支持，到了Android6.0已经找不到kernel/goldfish/drivers/staging/android/logger.c这一层的驱动程序了。不过上层接口还是没变的，所以顺着最顶层接口，可以一路找到6.0下Logger的实现机制。从最上层frameworks/base/core/java/android/util/

先写个helloworld吧，在Android源码树中创建文件夹external/helloworld，加入文件：// helloworld.c#include #include int main(int argc, char** arv){ printf("Hello world~
"); return 0;}# Android.mkLOCAL_PATH

侯 Sir说：“源码之下，了无秘密。” 但有些秘密还是要搞起来了看得更真切，仅从静态代码的体位很难体会到运动时的妙处。因此环境搭好了，下一步就是调试。gdbserver搭配gdb的调试环境走得很顺利，可是mmm出的C代码总是没有debugging symbol。在调研原因的过程中倒是熟悉了一些工具的用法，值得记录。首先，关于mmm的代码，它是写在build/envsetup.sh中的函数，内部

例子是从《Android系统源代码情景分析》第二章抄过来的，在学习的过程中还是遇到了不少的问题。个人体会：在学习第二章之前应该把《Linux设备驱动程序》这本书至少前四章要读一遍，理解一些基础概念和背景知识，不过这本书还是略旧，比如sysfs就没有解释，多google吧。本书第二章要理解透了再往下进行，因为这个简单的例子从下往上贯穿了Android系统各层，是理解后面各章的基础。下面列

一直在找mac下顺手的代码编辑器，要求能方便地查找和编辑，最好能再集成调试，最后选择了sublime。用了一段时间emacs，但是学习曲线过于陡峭。尤其是眼下的要务是啃代码时，玩弄emacs有点舍本逐末了，所以暂时还是先放一放神器，找个能尽快上手的玩吧~随着使用深入，我会不断更新，逐步把一些经验码到本篇博文后面。为了撸码更顺手，除了基本包以外，还需要装几个插件。首先要安装Packa