hw_module_t结构参考
#include < hardware.h >
资料栏位 | |
uint32_t | 标签 |
uint16_t | module_api_version |
uint16_t | hal_api_version |
const char * | ID |
const char * | 名称 |
const char * | 作者 |
struct 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行定义。
const char * id |
模块标识符
在文件hardware.h的第133行定义。
struct hw_module_methods_t *方法 |
模块方法
在文件hardware.h的第142行定义。
uint16_t module_api_version |
已实现模块的API版本。当模块接口更改时,模块所有者负责更新版本。
派生模块(例如gralloc和audio)拥有并管理此字段。模块用户必须解释版本字段,以决定是否与提供的模块实现进行互操作。例如,SurfaceFlinger负责确保它知道如何管理gralloc-module API的不同版本,而AudioFlinger必须知道如何对音频模块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 /包含/硬件/ hardware.h