Referência de estrutura hw_module_t

Referência de estrutura hw_module_t

#include < hardware.h >

Campos de dados

uint32_t marcação
uint16_t module_api_version
uint16_t hal_api_version
const char * Eu iria
const char * nome
const char * autor
struct hw_module_methods_t * métodos
vazio * dso
uint32_t reservado [32-7]

Descrição detalhada

Cada módulo de hardware deve ter uma estrutura de dados chamada HAL_MODULE_INFO_SYM e os campos dessa estrutura de dados devem começar com hw_module_t seguido de informações específicas do módulo.

Definição na linha 86 do arquivo hardware.h .

Documentação de campo

const char* autor

Autor/proprietário/implementador do módulo

Definição na linha 139 do arquivo hardware.h .

void* dso

dso do módulo

Definição na linha 145 do arquivo hardware.h .

uint16_t hal_api_version

As definições de version_major/version_minor são fornecidas aqui para compatibilidade temporária do código-fonte. Eles serão removidos na próxima versão. TODOS os clientes devem converter para o formato da nova versão. A versão da API da interface do módulo HAL. Isso destina-se à versão das estruturas e definições hw_module_t , hw_module_methods_t e hw_device_t .

A interface HAL possui este campo. Os usuários/implementações do módulo NÃO devem confiar neste valor para informações de versão.

Atualmente, 0 é o único valor válido.

Definição na linha 129 do arquivo hardware.h .

const char* id

Identificador do módulo

Definição na linha 133 do arquivo hardware.h .

struct hw_module_methods_t * métodos

Métodos de módulos

Definição na linha 142 do arquivo hardware.h .

uint16_t module_api_version

A versão da API do módulo implementado. O proprietário do módulo é responsável por atualizar a versão quando a interface de um módulo é alterada.

Os módulos derivados como gralloc e audio possuem e gerenciam este campo. O usuário do módulo deve interpretar o campo de versão para decidir se deve ou não interoperar com a implementação do módulo fornecido. Por exemplo, o SurfaceFlinger é responsável por garantir que ele saiba como gerenciar diferentes versões da API do módulo gralloc, e o AudioFlinger deve saber como fazer o mesmo para a API do módulo de áudio.

A versão da API do módulo deve incluir um componente principal e um componente secundário. Por exemplo, a versão 1.0 pode ser representada como 0x0100. Este formato implica que as versões 0x0100-0x01ff são todas compatíveis com API.

No futuro, o libhardware irá expor uma função hw_get_module_version() (ou equivalente) que terá versões mínimas/máximas suportadas como argumentos e poderá rejeitar módulos com versões fora do intervalo fornecido.

Definição na linha 111 do arquivo hardware.h .

const char* nome

Nome deste módulo

Definição na linha 136 do arquivo hardware.h .

uint32_t reservado[32-7]

preenchimento de 128 bytes, reservado para uso futuro

Definição na linha 151 do arquivo hardware.h .

etiqueta uint32_t

a tag deve ser inicializada para HARDWARE_MODULE_TAG

Definição na linha 88 do arquivo hardware.h .


A documentação para esta estrutura foi gerada a partir do seguinte arquivo:
  • hardware/libhardware/include/hardware/ hardware.h