AndroidO Treble架构下的变化--

AndroidO引入Treble架构后，有那些变化呢？

1. 增加了多个服务管家，AndroidO之前版本有且只有一个servicemanager，现在增加到3个，他们分管不同的服务。
2. 增加了binder通信库，这是为了适配binder域的扩展。
3. 增加了binder域，系统定义了3个binder设备节点，binder驱动分别处理这3个binder设备节点上的binder通信事件。

Binder通信域变化

Treble架构的引入足以说明Binder通信的重要性，之前APP和Framework之间通过binder实现跨进程调用，当然这个调用对开发者来说是透明的，相当于函数本地调用。Treble引入后，Framework和HAL又实现了进程分离，Framework和HAL之间依然使用binder通信，通过HIDL来定义通信接口。那binder通信有什么变化呢？在Treble中，引入了多个binder域，主要是增加了多个binder设备，binder驱动实现原理基本没变，变化了一些细节。增加binder设备应该是为了实现更换的权限控制，使用不同binder设备的主体和客体之间的selinux权限有所不同，同时，Android 框架和 HAL 现在使用 Binder 互相通信。由于这种通信方式极大地增加了 Binder 流量。
为了明确地拆分框架（与设备无关）和供应商（与具体设备相关）代码之间的 Binder 流量，Android O 引入了“Binder 上下文”这一概念。每个 Binder 上下文都有自己的设备节点和上下文（服务）管理器。您只能通过上下文管理器所属的设备节点对其进行访问，并且在通过特定上下文传递 Binder 节点时，只能由另一个进程从相同的上下文访问上下文管理器，从而确保这些域完全互相隔离。为了显示 /dev/vndbinder，请确保内核配置项 CONFIG_ANDROID_BINDER_DEVICES 设为”binder,hwbinder,vndbinder”

static char *binder_devices_param = CONFIG_ANDROID_BINDER_DEVICES; 

module_param_named(devices, binder_devices_param, charp, S_IRUGO);
  
  
   
   1
   
   2
   
   3

以kernel参数形式得到配置的binder设备节点名称，然后在binder驱动中创建不同的binder设备：

static int __init binder_init(void)  
{  
    int ret;  
    char *device_name, *device_names;  
    struct binder_device *device;  
    struct hlist_node *tmp;  
    ...  
    /* 
     * Copy the module_parameter string, because we don't want to 
     * tokenize it in-place. 
     */  
    device_names = kzalloc(strlen(binder_devices_param) + 1, GFP_KERNEL);  
    if (!device_names) {  
        ret = -ENOMEM;  
        goto err_alloc_device_names_failed;  
    }  
    strcpy(device_names, binder_devices_param);  

    while ((device_name = strsep(&device_names, ","))) {  
        ret = init_binder_device(device_name);  
        if (ret)  
            goto err_init_binder_device_failed;  
    }  

    return ret;  

err_init_binder_device_failed:  
    hlist_for_each_entry_safe(device, tmp, &binder_devices, hlist) {  
        misc_deregister(&device->miscdev);  
        hlist_del(&device->hlist);  
        kfree(device);  
    }  
err_alloc_device_names_failed:  
    debugfs_remove_recursive(binder_debugfs_dir_entry_root);  

    return ret;  
}  
  
  
   
   1
   
   2
   
   3
   
   4
   
   5
   
   6
   
   7
   
   8
   
   9
   
   10
   
   11
   
   12
   
   13
   
   14
   
   15
   
   16
   
   17
   
   18
   
   19
   
   20
   
   21
   
   22
   
   23
   
   24
   
   25
   
   26
   
   27
   
   28
   
   29
   
   30
   
   31
   
   32
   
   33
   
   34
   
   35
   
   36
   
   37

static int __init init_binder_device(const char *name)  
{  
    int ret;  
    struct binder_device *binder_device;  

    binder_device = kzalloc(sizeof(*binder_device), GFP_KERNEL);  
    if (!binder_device)  
        return -ENOMEM;  

    binder_device->miscdev.fops = &binder_fops;  
    binder_device->miscdev.minor = MISC_DYNAMIC_MINOR;  
    binder_device->miscdev.name = name;  

    binder_device->context.binder_context_mgr_uid = INVALID_UID;  
    binder_device->context.name = name;  
    mutex_init(&binder_device->context.context_mgr_node_lock);  

    ret = misc_register(&binder_device->miscdev);  
    if (ret < 0) {  
        kfree(binder_device);  
        return ret;  
    }  

    hlist_add_head(&binder_device->hlist, &binder_devices);  

    return ret;  
}  
  
  
   
   1
   
   2
   
   3
   
   4
   
   5
   
   6
   
   7
   
   8
   
   9
   
   10
   
   11
   
   12
   
   13
   
   14
   
   15
   
   16
   
   17
   
   18
   
   19
   
   20
   
   21
   
   22
   
   23
   
   24
   
   25
   
   26
   
   27

这样在驱动中就创建了binder、vndbinder、hwbinder三个驱动设备，并保存在binder设备列表binder_devices中。/dev/binder 设备节点成为了框架进程的专属节点，这意味着oem进程将无法再访问该节点。oem进程可以访问 /dev/hwbinder，但必须将其 AIDL 接口转为使用 HIDL。

binder驱动设备

hwbinder驱动设备

vndbinder驱动设备

由于vndbinder和binder使用的都是libbinder.so库，因此在打开binder设备时，需要调用：
ProcessState::initWithDriver(“/dev/vndbinder”);来指定打开那个binder设备。

服务管家变化

AndroidO将服务管家从servicemanager扩展到以下3个：

servicemanager

源码：

编译脚本：
这里写图片描述

vndservicemanager

以前Binder 服务通过 servicemanager 注册，其他进程可从中检索这些服务。在 Android O 中，servicemanager 现在专用于框架和应用进程，供应商进程无法再对其进行访问。不过，供应商服务现在可以使用 vndservicemanager，这是一个使用 /dev/vndbinder而非 /dev/binder 的 servicemanager 的新实例。供应商进程无需更改即可与vndservicemanager 通信；当供应商进程打开 /dev/vndbinder 时，服务查询会自动转至 vndservicemanager。servicemanager和vndservicemanager使用的是同一份代码，都是由service_manager.c编译而来。
这里写图片描述
在启动servicemanager 时，并没有传参，而启动vndservicemanager时，传递了binder设备节点。

这里写图片描述
vndservicemanager使用/dev/vndbinder驱动设备，而servicemanager使用/dev/binder驱动设备。在编译vndservicemanager时指定了VENDORSERVICEMANAGER宏：

cflags: [  

       "-DVENDORSERVICEMANAGER=1",  

    ],  
  
  
   
   1
   
   2
   
   3
   
   4
   
   5

这里写图片描述

vndservicemanager与servicemanager不仅使用的binder设备不同，使用的selinux策略也不同。

vndservicemanager使用的selinux策略文件为：”/vendor/etc/selinux/vndservice_contexts”

servicemanager使用的selinux策略文件为：”/system/etc/selinux/plat_service_contexts”

1) servicemanager和vndservicemanager使用的binder设备节点不同：

servicemanager使用/dev/binder

vndservicemanager使用/deve/vndbinder

  
  
   
   1
   
   2
   
   3

2) servicemanager和vndservicemanager使用的selinux策略文件不同：

servicemanager使用/system/etc/selinux/plat_service_contexts

 vndservicemanager使用/vendor/etc/selinux/vndservice_contexts

  
  
   
   1
   
   2
   
   3

3) 查看servicemanager和vndservicemanager管理的binder服务的工具不同：

servicemanager使用service list

vndservicemanager使用vndservice list

  
  
   
   1
   
   2
   
   3

hwservicemanager

这里写图片描述

该hwservicemanager用于管理hidl服务，因此其实现和servicemanager完全不同，使用的binder库也完全不同。

Binder库变化

servicemanager和vndservicemanager都使用libbinder库，只是他们使用的binder驱动不同而已，而hwservicemanager使用libhwbinder库，binder驱动也不同。

libbinder库源码：

这里写图片描述

libhwbinder库源码：

这里写图片描述

文件对比：

这里写图片描述

Binder通信框架变化

这里写图片描述

1.在普通Java Binder框架中，Client端Proxy类完成数据打包，然后交给mRemotebinder代理来完成数据传输。Server端Stub类完成数据解析，然后交给其子类实现。

2.在普通Native Binder框架中，Client端BpXXX类完成数据打包，然后交给mRemoteBpBinder来完成数据传输。Server端BnXXX类完成数据解析，然后交个其子类实现。

在HwBinder框架中，Client端的BpHwXXX类完成数据打包，然后交给mRemoteBpHwBinder来完成数据传输。Server端的BnHwXXX类完成数据解析，然后交给_hidl_mImpl来实现。

框架层Binder对象变化

这里写图片描述