第三节-Android10.0 Binder通信原理（三）-ServiceManager篇

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的大小，不同厂家有时候也会调整大小，一般有1M，64K，4K，1KB，通常为4K。

ServiceManager进程mmap的内存大小可以通过adb shell命令得出：

其中0x7457b61000 -0x745d41000=0x20000,转成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_BITS=39)

ARM64有足够的虚拟地址，用户空间和内核空间可以有各自的2^39=512GB的虚拟地址。

需要注意到，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 注册服务

        根据传入的code：SVC_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