hw_module_t 结构参考
#include < hardware.h >
数据字段 | |
uint32_t | 标签 |
uint16_t | module_api_version |
uint16_t | hal_api_version |
常量字符 * | ID |
常量字符 * | 姓名 |
常量字符 * | 作者 |
结构hw_module_methods_t * | 方法 |
空白 * | dso |
uint32_t | 保留[32-7] |
详细说明
每个硬件模块都必须有一个名为 HAL_MODULE_INFO_SYM 的数据结构,并且该数据结构的字段必须以hw_module_t开头,后跟模块特定信息。
在文件hardware.h的第86行定义。
现场文件
const char* 作者 |
模块的作者/所有者/实施者
在文件hardware.h的第139行定义。
无效* dso |
模块的dso
在文件hardware.h的第145行定义。
uint16_t hal_api_version |
此处提供 version_major/version_minor 定义以实现临时源代码兼容性。它们将在下一个版本中删除。所有客户端都必须转换为新版本格式。 HAL 模块接口的 API 版本。这是为了版本化hw_module_t 、 hw_module_methods_t和hw_device_t结构和定义。
HAL 接口拥有该字段。模块用户/实现不得依赖此值获取版本信息。
目前,0 是唯一有效的值。
在文件hardware.h的第129行定义。
常量字符* id |
模块标识符
在文件hardware.h的第133行定义。
结构hw_module_methods_t * 方法 |
模块方法
在文件hardware.h的第142行定义。
uint16_t module_api_version |
已实现模块的 API 版本。当模块接口发生变化时,模块所有者负责更新版本。
派生模块如gralloc 和audio 拥有并管理该字段。模块用户必须解释版本字段来决定是否与提供的模块实现互操作。例如,SurfaceFlinger 负责确保它知道如何管理不同版本的 gralloc-module API,而 AudioFlinger 必须知道如何为 audio-module API 做同样的事情。
模块 API 版本应包括主要和次要组件。例如,版本 1.0 可以表示为 0x0100。这种格式意味着版本 0x0100-0x01ff 都是 API 兼容的。
将来,libhardware 将公开一个 hw_get_module_version()(或等效)函数,该函数将支持的最小/最大版本作为参数,并且能够拒绝版本超出提供范围的模块。
在文件hardware.h的第111行定义。
const char* 名称 |
该模块的名称
在文件hardware.h的第136行定义。
uint32_t 保留[32-7] |
填充到 128 字节,保留以供将来使用
在文件hardware.h的第151行定义。
uint32_t 标签 |
标记必须初始化为 HARDWARE_MODULE_TAG
在文件hardware.h的第88行定义。
此结构的文档是从以下文件生成的:
- 硬件/libhardware/include/hardware/hardware.h