Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

hw_module_t Strukturreferenz

hw_module_t Strukturreferenz

#include < hardware.h >

Datenfelder

uint32_t Schild
uint16_t module_api_version
uint16_t hal_api_version
konstantes Zeichen * Ich würde
konstantes Zeichen * Name
konstantes Zeichen * Autor
struct hw_module_methods_t * Methoden
Leere * dso
uint32_t reserviert [32-7]

detaillierte Beschreibung

Jedes Hardwaremodul muss eine Datenstruktur namens HAL_MODULE_INFO_SYM haben und die Felder dieser Datenstruktur müssen mit hw_module_t beginnen, gefolgt von modulspezifischen Informationen.

Definition in Zeile 86 der Datei hardware.h .

Felddokumentation

const char* Autor

Autor/Eigentümer/Implementierer des Moduls

Definition in Zeile 139 der Datei hardware.h .

ungültig* dso

dso des Moduls

Definition in Zeile 145 der Datei hardware.h .

uint16_t hal_api_version

version_major/version_minor Definitionen werden hier für temporäre Quellcodekompatibilität bereitgestellt. Sie werden in der nächsten Version entfernt. ALLE Clients müssen in das neue Versionsformat konvertieren. Die API-Version der HAL-Modulschnittstelle. Damit sollen die Strukturen und Definitionen hw_module_t , hw_module_methods_t und hw_device_t versioniert werden.

Die HAL-Schnittstelle besitzt dieses Feld. Modulbenutzer/-implementierungen dürfen sich für Versionsinformationen NICHT auf diesen Wert verlassen.

Derzeit ist 0 der einzig gültige Wert.

Definition in Zeile 129 der Datei hardware.h .

const char* id

Kennung des Moduls

Definition in Zeile 133 der Datei hardware.h .

struct hw_module_methods_t * Methoden

Module Methoden

Definition in Zeile 142 der Datei hardware.h .

uint16_t module_api_version

Die API-Version des implementierten Moduls. Der Modulbesitzer ist für die Aktualisierung der Version verantwortlich, wenn sich eine Modulschnittstelle geändert hat.

Die abgeleiteten Module wie gralloc und audio besitzen und verwalten dieses Feld. Der Modulbenutzer muss das Versionsfeld interpretieren, um zu entscheiden, ob er mit der gelieferten Modulimplementierung zusammenarbeitet oder nicht. Beispielsweise ist SurfaceFlinger dafür verantwortlich sicherzustellen, dass es weiß, wie verschiedene Versionen der Gralloc-Modul-API verwaltet werden, und AudioFlinger muss wissen, wie das gleiche für die Audiomodul-API zu tun ist.

Die Modul-API-Version sollte eine Haupt- und eine Nebenkomponente enthalten. Beispielsweise könnte Version 1.0 als 0x0100 dargestellt werden. Dieses Format impliziert, dass die Versionen 0x0100-0x01ff alle API-kompatibel sind.

In Zukunft wird libhardware eine hw_get_module_version() (oder gleichwertige) Funktion verfügbar machen, die minimal/maximal unterstützte Versionen als Argumente akzeptiert und in der Lage wäre, Module mit Versionen außerhalb des bereitgestellten Bereichs abzulehnen.

Definition in Zeile 111 der Datei hardware.h .

const char* name

Name dieses Moduls

Definition in Zeile 136 der Datei hardware.h .

uint32_t reserviert[32-7]

Padding auf 128 Byte, reserviert für zukünftige Verwendung

Definition in Zeile 151 der Datei hardware.h .

uint32_t-Tag

-Tag muss auf HARDWARE_MODULE_TAG initialisiert werden

Definition in Zeile 88 der Datei hardware.h .


Die Dokumentation für diese Struktur wurde aus der folgenden Datei generiert:
  • hardware/libhardware/include/hardware/ hardware.h