Bis auf wenige Ausnahmen befinden sich HIDL-Schnittstellenpakete im Verzeichnis hardware/interfaces
oder vendor/
. Die oberste Ebene von hardware/interfaces
ist direkt dem Paket-Namespace android.hardware
zugeordnet. Die Version ist ein Unterverzeichnis im Paket-Namespace (nicht im Interface-Namespace).
Der hidl-gen
-Compiler kompiliert die .hal
-Dateien in eine Reihe von .h
- und .cpp
-Dateien. Aus diesen automatisch generierten Dateien wird eine freigegebene Bibliothek erstellt, mit der Client-/Serverimplementierungen verknüpft werden.
Die Android.bp
-Datei, aus der diese gemeinsam genutzte Bibliothek erstellt wird, wird vom hardware/interfaces/update-makefiles.sh
-Script automatisch generiert. Jedes Mal, wenn Sie hardware/interfaces
ein neues Paket hinzufügen oder .hal
-Dateien zu einem vorhandenen Paket hinzufügen oder daraus entfernen, müssen Sie das Script noch einmal ausführen, damit die generierte freigegebene Bibliothek auf dem neuesten Stand ist.
Die Beispieldatei IFoo.hal
sollte sich beispielsweise in hardware/interfaces/samples/1.0
befinden. In der Beispieldatei IFoo.hal
wird die IFoo-Schnittstelle im Paket samples erstellt:
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 mit einer einzigen freigegebenen Bibliothek verknüpft, die denselben Namen wie das Paket hat (z. B. android.hardware.samples@1.0
). Die freigegebene Bibliothek exportiert auch einen einzelnen Header, IFoo.h
, der von Clients und Servern eingeschlossen werden kann. Wenn Sie den hidl-gen
-Compiler mit der IFoo.hal
-Benutzeroberflächendatei als Eingabe verwenden, werden im Binder-Modus die folgenden automatisch generierten Dateien erstellt:
Abbildung 1: Vom Compiler generierte Dateien.
IFoo.h
: Beschreibt die reineIFoo
-Schnittstelle in einer C++-Klasse. Sie enthält die in derIFoo.hal
-Datei in derIFoo
-Schnittstelle definierten Methoden und Typen, die bei Bedarf in C++-Typen übersetzt werden. Enthält keine Details zum RPC-Mechanismus (z. B.HwBinder
), der für die Implementierung dieser Schnittstelle verwendet wird. Die Klasse hat denselben Namensraum wie das Paket und die 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
. Headerdatei mit Deklarationen für Funktionen, die Datentypen serialisieren, die in der Benutzeroberfläche verwendet werden. Entwickler sollten diesen Header niemals direkt einfügen, da er keine Klassen enthält.BpHwFoo.h
: Eine Klasse, die vonIFoo
abgeleitet ist und dieHwBinder
-Proxy-Implementierung (clientseitig) der Schnittstelle beschreibt. Entwickler sollten sich niemals direkt auf diese Klasse beziehen.BnHwFoo.h
: Eine Klasse, die einen Verweis auf eineIFoo
-Implementierung enthält und dieHwBinder
-Stub-Implementierung (serverseitig) der Schnittstelle beschreibt. Entwickler sollten sich niemals direkt auf diese Klasse beziehen.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 die Argumente automatisch vom Client und sendet die Transaktion an den Binder-Kernel-Treiber, der die Transaktion an den Stub auf der anderen Seite weiterleitet, der dann die eigentliche Serverimplementierung aufruft.
Die Dateien sind ähnlich strukturiert wie die von aidl-cpp
generierten Dateien. Weitere Informationen 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 dürfen Client- und Serverimplementierungen sich niemals direkt auf etwas anderes als IFoo
beziehen. Fügen Sie dazu nur IFoo.h
ein und verknüpfen Sie es mit der generierten freigegebenen Bibliothek.
Verknüpfung mit geteilten Fotogalerien
Ein Client oder Server, der eine Schnittstelle in einem Paket verwendet, muss die freigegebene 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 standardmäßige HIDL-Datentypen. Ab Android 10 enthält diese Taste auch alle Symbole, die zuvor unter libhidltransport und libhwbinder zu finden waren.
|
---|---|
libhidltransport |
Verwaltet den Transport von HIDL-Aufrufen über verschiedene RPC-/IPC-Mechanismen. Diese Bibliothek wird in Android 10 eingestellt. |
libhwbinder |
Ordnerspezifische Symbole. Diese Bibliothek wird in Android 10 eingestellt. |
libfmq |
Fast Message Queue IPC. |
Namespaces
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.
Ein Paket mypackage mit der Version 1.2 unter hardware/interfaces
hat beispielsweise die folgenden Eigenschaften:
- 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 eine Kennung und kein Teil des Namespace.) - Typen, die in der
types.hal
-Datei des Pakets definiert sind, werden so gekennzeichnet:::android::hardware::mypackage::V1_2::MyPackageType