Mit wenigen Ausnahmen befinden sich HIDL-Schnittstellenpakete im Verzeichnis hardware/interfaces
oder im vendor/
-Verzeichnis. Die oberste Ebene hardware/interfaces
ist direkt dem Paket-Namespace android.hardware
zugeordnet. Die Version ist ein Unterverzeichnis unter dem Paket-Namespace (nicht der Schnittstelle).
Der hidl-gen
-Compiler kompiliert die .hal
Dateien in einen Satz aus .h
und .cpp
Dateien. Aus diesen automatisch generierten Dateien wird eine gemeinsam genutzte Bibliothek erstellt, mit der Client/Server-Implementierungen verknüpft werden. Die Android.bp
Datei, die diese gemeinsam genutzte Bibliothek erstellt, wird vom Skript hardware/interfaces/update-makefiles.sh
automatisch generiert. Jedes Mal, wenn Sie ein neues Paket zu hardware/interfaces
hinzufügen oder .hal
Dateien zu einem vorhandenen Paket hinzufügen/entfernen, müssen Sie das Skript erneut ausführen, um sicherzustellen, dass die generierte gemeinsam genutzte Bibliothek auf dem neuesten Stand ist.
Beispielsweise sollte sich die Beispieldatei IFoo.hal
unter hardware/interfaces/samples/1.0
befinden. Die Beispieldatei IFoo.hal
erstellt eine IFoo-Schnittstelle im Beispielpaket :
package android.hardware.samples@1.0; interface IFoo { struct Foo { int64_t someValue; handle myHandle; }; someMethod() generates (vec<uint32_t>); anotherMethod(Foo foo) generates (int32_t ret); };
Generierte Dateien
Automatisch generierte Dateien in einem HIDL-Paket werden in einer einzigen gemeinsam genutzten Bibliothek mit demselben Namen wie das Paket verknüpft (z. B. android.hardware.samples@1.0
). Die gemeinsam genutzte Bibliothek exportiert außerdem einen einzelnen Header, IFoo.h
, der von Clients und Servern eingebunden werden kann. Unter Verwendung des hidl-gen
Compilers mit der Schnittstellendatei IFoo.hal
als Eingabe verfügt der binderisierte Modus über die folgenden automatisch generierten Dateien:
-
IFoo.h
. Beschreibt die reineIFoo
Schnittstelle in einer C++-Klasse; Es enthält die Methoden und Typen, die in derIFoo
Schnittstelle in der DateiIFoo.hal
definiert sind und bei Bedarf in C++-Typen übersetzt wurden. Enthält keine Details zum RPC-Mechanismus (z. B.HwBinder
), der zur Implementierung dieser Schnittstelle verwendet wird. Die Klasse hat einen Namensraum mit dem Paket und der Version, z. B.::android::hardware::samples::IFoo::V1_0
. Sowohl Clients als auch Server enthalten diesen Header: Clients zum Aufrufen von Methoden und Server zum Implementieren dieser Methoden. -
IHwFoo.h
. Header-Datei, die Deklarationen für Funktionen enthält, die in der Schnittstelle verwendete Datentypen serialisieren. Entwickler sollten seinen Header niemals direkt einfügen (er enthält keine Klassen). -
BpHwFoo.h
. Eine Klasse, die vonIFoo
erbt und dieHwBinder
Proxy-Implementierung (clientseitig) der Schnittstelle beschreibt. Entwickler sollten niemals direkt auf diese Klasse verweisen. -
BnHwFoo.h
. Eine Klasse, die einen Verweis auf eineIFoo
Implementierung enthält und dieHwBinder
Stub-Implementierung (serverseitig) der Schnittstelle beschreibt. Entwickler sollten niemals direkt auf diese Klasse verweisen. -
FooAll.cpp
. Eine Klasse, die die Implementierungen sowohl für denHwBinder
Proxy als auch für denHwBinder
Stub enthält. Wenn ein Client eine Schnittstellenmethode aufruft, marshallt der Proxy automatisch die Argumente des Clients und sendet die Transaktion an den Binder-Kernel-Treiber, der die Transaktion an den Stub auf der anderen Seite übermittelt (der dann die eigentliche Serverimplementierung aufruft).
Die Dateien sind ähnlich aufgebaut wie die von aidl-cpp
generierten Dateien (Einzelheiten finden Sie unter „Passthrough-Modus“ in der HIDL-Übersicht ). Die einzige automatisch generierte Datei, die unabhängig vom von HIDL verwendeten RPC-Mechanismus ist, ist IFoo.h
; Alle anderen Dateien sind an den von HIDL verwendeten HwBinder-RPC-Mechanismus gebunden. Daher sollten Client- und Serverimplementierungen niemals direkt auf etwas anderes als IFoo
verweisen . Um dies zu erreichen, schließen Sie nur IFoo.h
ein und verknüpfen Sie es mit der generierten gemeinsam genutzten Bibliothek.
Verlinkung zu gemeinsam genutzten Bibliotheken
Ein Client oder Server, der eine beliebige Schnittstelle in einem Paket verwendet, muss die gemeinsam genutzte Bibliothek dieses Pakets an einem (1) der folgenden Speicherorte enthalten:
- In Android.mk :
LOCAL_SHARED_LIBRARIES += android.hardware.samples@1.0
- In Android.bp :
shared_libs: [ /* ... */ "android.hardware.samples@1.0", ],
Zusätzliche Bibliotheken, die Sie möglicherweise einbinden müssen:
libhidlbase | Enthält Standard-HIDL-Datentypen. Ab Android 10 enthält es auch alle Symbole, die zuvor in libhidltransport und libhwbinder enthalten waren. |
---|---|
libhidltransport | Verarbeitet den Transport von HIDL-Aufrufen über verschiedene RPC/IPC-Mechanismen. Android 10 veraltet diese Bibliothek. |
libhwbinder | Binderspezifische Symbole. Android 10 veraltet diese Bibliothek. |
libfmq | Fast Message Queue IPC. |
Namensräume
HIDL-Funktionen und -Typen wie Return<T>
und Void()
werden im Namespace ::android::hardware
deklariert. Der C++-Namespace eines Pakets wird durch den Paketnamen und die Version bestimmt. Beispielsweise hat ein Paket mypackage mit Version 1.2 unter hardware/interfaces
folgende Eigenschaften:
- Der C++-Namespace ist
::android::hardware::mypackage::V1_2
- Der vollständig qualifizierte Name von
IMyInterface
in diesem Paket lautet:::android::hardware::mypackage::V1_2::IMyInterface
. (IMyInterface
ist ein Bezeichner, nicht Teil des Namespace). - In der Datei
types.hal
des Pakets definierte Typen werden wie folgt identifiziert:::android::hardware::mypackage::V1_2::MyPackageType