Android Hardware Abstraction Layer
|const char *||id|
|const char *||name|
|const char *||author|
|struct hw_module_methods_t *||methods|
Every hardware module must have a data structure named HAL_MODULE_INFO_SYM and the fields of this data structure must begin with hw_module_t followed by module specific information.
|const char* author|
version_major/version_minor defines are supplied here for temporary source code compatibility. They will be removed in the next version. ALL clients must convert to the new version format. The API version of the HAL module interface. This is meant to version the hw_module_t, hw_module_methods_t, and hw_device_t structures and definitions.
The HAL interface owns this field. Module users/implementations must NOT rely on this value for version information.
Presently, 0 is the only valid value.
The API version of the implemented module. The module owner is responsible for updating the version when a module interface has changed.
The derived modules such as gralloc and audio own and manage this field. The module user must interpret the version field to decide whether or not to inter-operate with the supplied module implementation. For example, SurfaceFlinger is responsible for making sure that it knows how to manage different versions of the gralloc-module API, and AudioFlinger must know how to do the same for audio-module API.
The module API version should include a major and a minor component. For example, version 1.0 could be represented as 0x0100. This format implies that versions 0x0100-0x01ff are all API-compatible.
In the future, libhardware will expose a hw_get_module_version() (or equivalent) function that will take minimum/maximum supported versions as arguments and would be able to reject modules with versions outside of the supplied range.