上海网站推广有哪些,深圳人才网官方网站,海原县建设局网站,阿里巴巴官网下载手机版1、概述 在Android中#xff0c;系统提供的服务被包装成一个个系统级service#xff0c;这些service往往会在设备启动之时添加进Android系统#xff0c;当某个应用想要调用系统某个服务的功能时#xff0c;往往是向系统发出请求#xff0c;调用该服务的外部接口。在上一节…1、概述 在Android中系统提供的服务被包装成一个个系统级service这些service往往会在设备启动之时添加进Android系统当某个应用想要调用系统某个服务的功能时往往是向系统发出请求调用该服务的外部接口。在上一节我们了解到这种外部接口我们通常称之为代理接口也就是我们要拿到目标服务对应的代理对象。 //TODO 在Android8.0后谷歌引入Treble机制binder机制增加了hwbinder和vndbinder其中vndbinder的守护进程为vndservicemanager。 vndservicemanager和service共用同一份代码只是传入的参数和宏控制的流程有部分差异。 vndservicemanager会传入参数“/dev/vndbinder”servicemanager使用默认的“/dev/binder”。 servicemanager主要做了以下几件事 1、打开binder驱动申请了128k的内存空间 2、然后调用binder_become_context_manager()让自己成为整个系统中唯一的上下文管理器其实也就是service管理器 3、调用binder_loop()进入无限循环不断监听并解析binder驱动发来的命令 2、Binder架构
//TODO
3、servicemanager的启动
//TODO
4、service_manager调用栈
//TODO
5、源码分析 5.1 主程序启动main //TODO 5.2 binder_open() servicemanager启动后先通过binder_open()来打开“/dev/binder”代码如下
binder_open()的工作也比较简单分为以下几步
1、通过系统调用open()来打开“/dev/binder”获得一个句柄信息在Binder驱动重对应的是函数binder_open()
2、通过ioctl获取binder的版本信息比较binder协议版本是否相同不同则跳出在Binder驱动重对应的是函数binder_ioctl()
3、通过mmap内存映射128k的内存空间即把binder驱动文件的128K字节映射到了内存空间这128K内存空间的servicemanager使用在Binder驱动重对应的是函数binder_mmap()。
其他的binder服务进程会映射BINDER_VM_SIZE((1*1024*1024)-sysconf(SC_PAGE_SIZE)*2)的内存空间SC_PAGE_SIZE表示一个page页的大小通常情况下为4K即(1M-4K*2)(1M-7K)
这个page的大小不同厂家有时候也会调整大小一般有1M64K4K1KB通常为4K。
ServiceManager进程mmap的内存大小可以通过adb shell命令得出
其中0x7457b61000 -0x745d410000x20000,转成10进制即为128K ARM32内存映射
虚拟空间的低3GB部分从0-0XBFFFFFFF的虚拟线性地址用户态和内核态都可以寻址这部分也是每个进程的独立空间。
虚拟空间的高1G部分从0XC00000000到0XFFFFFFFF的虚拟地址只有内核态的进程才能访问这种限制由页目录和页眉描述符的权限标示位决定通过MML启动控制 ARM64内存映射
默认情况下32位系统默认只能支持4G的内存在打开PAE后最大可以扩展到64G的内存随着物理硬件的不断升级现在的内存越来越大因此基本上都切换到了64位系统。
理论上讲64位的地址总线可以支持高达16EB(2^64)的内存。
2^64次方太大了Linux内核只采用了64bits的一部分(开启CONFIG_ARM64_64K_PAGES时使用42bits页大小是4K时使用39bits)该文假设使用的页大小是4K(VA_BITS39)
ARM64有足够的虚拟地址用户空间和内核空间可以有各自的2^39512GB的虚拟地址。
需要注意到32位应用仍然拥有512GB的内核虚拟地址空间并且不与内核共享自己的4GB空间但在ARM32上32位应用只有3GB的地址空间。 ARM32和ARM64内存地址比较 5.3 binder_become_context_manager() binder_become_context_manager()的作用是让servicemanager成为整个系统中唯一的上下文管理器其实也就是service管理器这样我们就可以把ServiceManager称之为守护进程。 对应的binder驱动中操作如下
从用户空间拷贝ioctl的参数调用binder_ioctl_set_ctx_mgr()进行设置
BINDER_SET_CONTEXT_MGR_EXT带参数BINDER_SET_CONTEXT_MGR不带参数 binder_ioctl_set_ctx_mgr()的流程也比较简单
1、先检查当前进程是否具有注册Context Manager的SEAndroid安全权限
2、如果具有SELinux权限会为整个系统的上下管理器专门生成一个binder_node节点便该节点的强弱应用加1
3、新创建的binder_node节点记入context-binder_context_mgr_node,即ServiceManager进程的context binder节点使之成为serviceManager的binder管理实体 5.4 binder_loop() 下一步进行守护进程的循环处理binder_loop()会先向binder驱动发出了BC_ENTER_LOOPER命令告诉binder驱动“本线程要进入循环状态了”接着进入一个for循环不断调用ioctl()读取发来的数据接着解析这些数据 其中最重要的一个结构体是binder_write_read它用来记录Binder buffer中读和写的数据信息结构体如下 5.5 binder_parse() 在binder_loop()进入for循环之后核心处理流程就是ioctl和binder_parse()即不停的从Binder驱动接收读写数据进行binder解析后进行处理。 在binder_loop()中声明了一个128字节的栈内存-readbuf用BINDER_WRITE_READ命令从驱动读取一些内容并传入binder_parse(),binder_parse()根据binder驱动传来的“BR_XXX”协议码进行相关的逻辑处理最重要的有三个“BR_XXX”协议
BR_TRANSACTION事务处理解析binder_transaction_data的数据调用回调函数svcmgr_handler()进行服务的注册获取等操作
BR_REPLY消息回复
BR_DEAD_BINDER死亡通知
只要binder_parse()解析正常binder_loop()就会一直执行下去ServiceManager进程不退出。
binder_parse()解析binder驱动传来的readbuf的内存readbuf拥有128字节的栈内存每次可以只处理一个cmd也可以有多个cmd所以存在一个while循环可以同时解析多个cmd多个cmd的结构体如下图所示 5.5.1 BR_XXX 协议码分析 BR_XXX码也称为Binder响应码这里介绍了ServiceManager处理的一些响应码的作用 5.5.2 BR_TRANSACTION解析 我们这里单独分析下BR_TRANSACTION的流程这也是我们常用的一个流程这是Binder驱动向Server端发送请求数据。
从readbuf中解析出binder_transaction_data的数据最后对接收和发送数据进行了封装传递给svcmgr_handler()做详细处理 从上main的逻辑看我们重点关注的是binder_transaction_data这个结构binder_transaction_data说明了transaction到底在传输什么语义而语义码就记录在其code成员中不同语义码需要携带的数据也是不同的这些数据由data指定。 结构体说明如下 从上面binder_transaction_data的结构可以看出data可存入的数据很少主要采用了数据其实地址和数据偏移量根据代码上下文可知调用了bio_init_from_txn(),从txn.transaction_data解析出binder_io的信息存入msg 5.5.2.1 bio_init_from_txn()
bio_init_from_txn()的作用就是把binder_transaction_data的“数据起始地址”“偏移量”“data数据的总大小”和“偏移数组中可用的条目” binder_transaction_data和binder_io的关联 初始化完binder_io的replay并把transaction_data转换成了binder_io的msg后调用回调函数svcmgr_handler()进行最终逻辑处理 5.6 svcmgr_handler 在BR_TRANSACTION的命令解析后就把binder_transaction_data_secctx的数据传给回调函数svcmgr_handler()进行处理。
根据不同的传输语义码(txn-code)来进行相应的操作查询服务注册服务以及列举所服务
源码如下 5.7 ServiceManager是如何管理service信息的 //TODO 5.8 注册服务 根据传入的codeSVC_MGR_ADD_SERVICE得知本次binder流程想要进行服务注册。
步骤
从binder_io msg中获取服务名称和长度
从binder_io msg中获取handle
检查该服务是否有注册的selinx权限
查询服务列表svclist是否存在该handle如果有handle就更新该服务的handle信息通过这个handle我们最终就能找到远端的service实体
如果svclist不存在该服务申请一个svcinfo的空间把服务名长度handle等信息存入其中
把svcinfo进入svclist的链表中
再以BC_ACQUIRE命令handle为目标的信息通过ioctl发送给binder驱动
最后以BC_REQEST_DEATH_NOTIFICATION命令的信息通过ioctl发送给binder驱动主要用于清理内存等收尾工作 5.9 查找服务 //TODO
6、总结 //TODO
