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