客户端 binder远程调用 服务端
surfaceflinger --binder--> hwcomposer
.hal文件编译时生成支持binder进程间远程调用通信的cpp文件
在out/soong/.intermediates/hardware/interfaces/graphics/composer/2.1/
目录下找到对应的.h和.cpp文件
registerAsService()函数就是.hal编译成cpp文件时自动生成的方法,
用于注册成为服务
在out/soong/.intermediates/hardware/interfaces/graphics/composer/2.1
搜索registerAsService()能看到它的实现。
hw_get_mudule()找到模块id为hwcomposer的模块
HAL module 架构逻辑如下:
/hardware/libhardware/hardware.c
加载动态库:hwcomposer.xxx.so
https://xkzzz.com/post/55999.html Linux动态库教程:深入理解符号表
dlopen函数用于打开指定的共享库文件
dlsym函数的功能就是可以从共享库(动态库)中
获取符号(全局变量与函数符号)地址
dlopen打开hwcomposer.xxx.so动态连接库
dlsym 在hwcomposer.xxx.so动态库中到HMI变量的地址,强制转换为指向hw_module_t的指针变量。
通过代码看android约定了:hal层数据结构。所以,大家按照这个约定编写代码。
Android方(甲方):通过dlsym找到类型为hw_module_t的HMI变量,
并通过HMI变量启动该模块工作。
设备生产制造方(乙方):在自己实现的hwcompoer动态库上,
实现类型为hw_module_t的HMI变量。
HAL module 架构
Android硬件抽象层有三个核心数据结构,
分别是hw_module_t , hw_module_methods_t, hw_device_t
hw_module_t 和 hw_device_t的区别是什么?
hw_module_t:是给动态库使用。
我的理解是用于代码之间的约定逻辑。
(代码间约定逻辑) (约定逻辑) (模块间session会话逻辑)
凡是用于代码之间的约定逻辑都可以成为module,
例如linux驱动开发中module_init和module_exit
hw_device_t: 该module的要实现具体功能对象。(业务逻辑)
hw_module_methods_t:代码之间的接口 (模块间session会话通信接口)
高通平台:sm8150 hwcomposer动态库的代码,声明HMI变量,且HMI变量的类型必须为hw_module_t类型或hw_module_t类型的子类。
如果自定义一个module结构体,第一个成员变量类型必须为hw_module_t。
因为,结构体可以强制转为第一个成员变量的类型。
放在第一个位置,相当于继承了hw_module_t。
通过loadModule()找到hwcompoer动态库的HMI变量,传给createHalWithAdapter()
最后,调用动态库里的HMI->methods->open()打开设备,
获取到hw_device_t类型设备变量
2.1)initWithDevice()
initDispatch(): 初始化分发器。代码之间业务功能对接函数映射表。
由于在不同模块之间,不同公司实现的代码。所以就引入函数映射表。 (甲方提供接口声明,乙方实现接口功能)
mDispatch是一个struct类型的函数映射表。
Android方(甲方):需要create layer功能,也是声明了createLayer()接口 (代码间约定逻辑)(session会话接口)
设备生产制造方(乙方):按照session会话接口实现create layer功能,把实现create layer功能填充到mDispatch函数映射表中。
硬件抽象层模块中的自定义一个硬件设备结构体,并且第一个成员变量的类型必须为hw_device_t。
放在第一个位置,相当于继承了hw_device_t。
HWCSession继承hwc2_device_t,hwc2_device_t继承hw_device_t
也即:HWCSession的父类是hw_device_t
C++:封装,继承,多态
HWCSession子类转化为父类hw_device_t后,调用到的getFunction()函数就是子类 HWCSession::GetFunction()