【Android源码 栏目提醒】:网学会员,鉴于大家对Android源码 十分关注,论文会员在此为大家搜集整理了“Android系统的Binder机制之一——Service Manager - 综合课件”一文,供大家参考学习!
Android系统的Binder机制之一——Service Manager 1 / 10
Android系统的Binder机制之一——Service Manager
Android虽然构建在Linux上面但是在IPC进程间机制方面没有利用Linux提供IPC机制而是自己实现了一套轻量级的IPC机制——binder机制。
并且
Android Binder机制之上
Android框架提供了一套封装可以实现对象代理在本地进程中代理远程进程的对象。
本文简单分析一下
Android Binder机制。
Binder情景分析 一个IPC通讯我们可以理解成客户端-服务器模式因此我们先在这里分析一下典型的Binder应用模式 1、客户端通过某种方式后文会详细介绍得到服务器端的代理对象。
从客户端角度看来代理对象和他的本地对象没有什么差别。
它可以像其他本地对象一样调用其方法访问其变量。
2、客户端通过调用服务器代理对象的方法向服务器端发送请求。
3、代理对象把用户请求通过
Android内核Linux内核的Binder驱动发送到服务器进程。
4、服务器进程处理用户请求并通过
Android内核Linux内核的Binder驱动返回处理结果给客户端的服务器代理对
Android系统的Binder机制之一——Service Manager 2 / 10 象。
5、客户端收到服务器端的返回结果。
如果你对COM或者Corba熟悉的话以上的情景是否会让你联想到什么呢没错都是对象代理。
以上的情景在
Android中经常会被用到。
如果你还没有注意到这点儿那么本文非常适合你。
Binder机制的组成 1、Binder驱动 binder是内核中的一个字符驱动设备位于/dev/binder。
这个设备是
Android系统IPC的核心部分客户端的服务代理用来通过它向服务器server发送请求服务器也是通过它把处理结果返回给客户端的服务代理对象。
我们只需要知道它的功能就可以了本文我们的重点不在这里所以后面不会专门介绍这部分因为很少会有人会显示打开这个设备去开发
Android程序。
如果想深入了解的话请研究内核
源码中的binder.c。
2、Service Manager 负责管理服务。
对应于第一步中客户端需要向Service Manager来查询和获得所需要服务。
服务器也需要向Service
Android系统的Binder机制之一——Service Manager 3 / 10 Manager注册自己提供的服务。
可以看出Service Manager是服务的大管家。
3、服务Server 需要强调的是这里服务是指的是System Server而不是SDK server请参考《转高焕堂——
Android框架底层结构知多少》关于两种Server的介绍其实应该是三种丢掉了init调用的server在init.rc中配置。
4、客户端 一般是指
Android系统上面的应用程序。
它可以请求Server中的服务。
5、对象代理 是指在客户端应用程序中生成的Server代理proxy。
从应用程序角度看代理对象和本地对象没有差别都可以调用其方法方法都是同步的并且返回相应的结果。
大内总管——Service Manager
Android系统Binder机制的总管是Service Manager所有的ServerSystem Server都需要向他注册应用程序需要向其查询相应的服务。
可见其作用是多么的重要所以本文首先介绍Service Manager。
Android系统的Binder机制之一——Service Manager 4 / 10 通过上面介绍我们知道Service Manager非常重要责任重大。
那么怎样才能成为Service Manager呢是不是谁都可以成为Service Manager呢怎样处理server的注册和应用程序的查询和获取服务呢为了回答这些问题先查看
Android中Service Manager的
源码其
源码位于 frameworksbasecmdsservicemanagerservice_manager.c 我们发现了main函数说明他自己就是一个进程在init.rc中我们发现 service servicemanager /system/bin/servicemanager user system critical onrestart restart zygote onrestart restart media 说明其是
Android核心程序开机就会自动运行。
下面我们在研究一下它的代码main函数很简单 int mainint argc char argv struct binder_state bs void svcmgr BINDER_SERVICE_MANAGER
Android系统的Binder机制之一——Service Manager 5 / 10 bs binder_open1281024 if binder_become_context_managerbs LOGEcannot become context manager sn strerrorerrno return -1 svcmgr_handle svcmgr binder_loopbs svcmgr_handler return 0 我们看到它先调用binder_open打开binder设备/dev/binder其次它调用了binder_become_context_manager函数这个函数使他自己变为了“Server大总管”其代码如下 int binder_become_context_managerstruct binder_state bs return ioctlbs-fd BINDER_SET_CONTEXT_MGR 0 也就是通过ioctl向binder设备声明“我就是server大总管”。
Android系统的Binder机制之一——Service Manager 6 / 10 Service Manager作为一个Server大总管本身也是一个server。
既然是一个server就要时刻准备为客户端提供服务。
最好Service Manager调用binder_loop进入到循环状态并提供了一个回调函数等待用户的请求。
注意他的Service Manager的客户端既包括应用程序查询和获取服务也包括Server注册服务。
Service Manager的客户怎样才能请求其服务呢答案是上文我们提到的情景一样。
客户需要在自己进程中创建一个服务器代理。
现在没有地方去查询服务那么怎样它的客户怎样生成他的服务代理对象呢答案是binder设备/devbinder为每一个服务维护一个句柄调用binder_become_context_manager函数变为“Server大总管”的服务他的句柄永远是0是一个“众所周知”的句柄这样每个程序都可以通过binder机制在自己的进程空间中创建一个 Service Manager代理对象了。
其他的服务在binder设备在设备中的句柄是不定的需要向“Server大总管”查询才能知道。
现在我们需要研究Server怎样注册服务了还是在其
源码中我们可以看到在其服务处理函数中上文提到
Android系统的Binder机制之一——Service Manager 7 / 10 binder_loop函数注册给binder设备的回调函数有如下代码 case SVC_MGR_ADD_SERVICE: s bio_get_string16msg len ptr bio_get_refmsg if do_add_servicebs s len ptr txn-sender_euid return -1 break 有server向binder设备写入请求注册Service时Service Manager的服务处理回调函数将会被调用。
我们在仔细看看do_add_service函数的实现 int do_add_servicestruct binder_state bs uint16_t s unsigned len void ptr unsigned uid struct svcinfo si // LOGIadd_servicesp uiddn str8s ptr uid if ptr len 0 len 127 return -1 if svc_can_registeruid s
Android系统的Binder机制之一——Service Manager 8 / 10 LOGEadd_servicesp uidd - PERMISSION DENIEDn str8s ptr uid return -1 si find_svcs len if si if si-ptr LOGEadd_servicesp uidd - ALREADY REGISTEREDn str8s ptr uid return -1 si-ptr ptr else si mallocsizeofsi len 1 sizeofuint16_t if si LOGEadd_servicesp uidd - OUT OF MEMORYn str8s ptr uid return -1 si-ptr ptr si-len len memcpysi-name s len 1 sizeofuint16_t
Android系统的Binder机制之一——Service Manager 9 / 10 si-namelen 0 si-death.func svcinfo_death si-death.ptr si si-next svclist svclist si binder_acquirebs ptr binder_link_to_deathbs ptr si-death return 0 我们看到首先检查是否有权限注册service没权限就对不起了出错返回然后检查是否已经注册过注册过的service将不能再次注册。
然后构造一个svcinfo对象并加入一个全局链表中svclist中。
最后通知binder设备有一个service注册进来。
我们再来看看客户端怎样通过Service Manager获得Service还是在服务处理函数中上文提到binder_loop函数注册给binder设备的回调函数有如下代码 case SVC_MGR_GET_SERVICE: case SVC_MGR_CHECK_SERVICE: s bio_get_string16msg len
Android系统的Binder机制之一——Service Manager 10 / 10 ptr do_find_servicebs s len if ptr break bio_put_refreply ptr return 0 我们可以看到通过do_find_service查找Service如果查找到的话写入reply中返回给客户端。
本文我们简单分析了一下Service Manager后续我们会继续分析
Android binder机制的其他部分。