Pakete

Hinweis: In diesem Abschnitt wird ein Beispiel .hal-Dateien, um zu veranschaulichen, wie HIDL-Sprachkonstrukte der C++ zugeordnet sind.

Mit wenigen Ausnahmen befinden sich HIDL-Schnittstellenpakete hardware/interfaces oder das vendor/-Verzeichnis. Die hardware/interfaces-Karte der obersten Ebene direkt zum android.hardware-Paket-Namespace; die Version ist ein Unterverzeichnis im Namespace „Package (nicht Interface)“.

Der Compiler hidl-gen kompiliert die .hal-Dateien in eine Reihe von .h- und .cpp-Dateien. Von diesen automatisch generierten Dateien eine gemeinsam genutzte Bibliothek erstellt, mit der die Client/Server-Implementierungen verknüpft sind. Die Datei Android.bp, mit der diese gemeinsam genutzte Bibliothek erstellt wird, ist automatisch generiert von hardware/interfaces/update-makefiles.sh . Jedes Mal, wenn du hardware/interfaces ein neues Paket hinzufügst, oder .hal Dateien einem vorhandenen Paket hinzufügen/entfernen, müssen noch einmal ausgeführt werden das Skript, um sicherzustellen, dass die generierte gemeinsam genutzte Bibliothek auf dem neuesten Stand ist.

Die Beispieldatei IFoo.hal sollte sich beispielsweise in folgendem Verzeichnis befinden: hardware/interfaces/samples/1.0. Das Beispiel IFoo.hal-Datei erstellt eine IFoo-Schnittstelle im proben-Paket enthält:

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 einem einzigen freigegebenen Bibliothek mit dem Namen des Pakets (z. B. android.hardware.samples@1.0. Die gemeinsam genutzte Bibliothek exportiert auch einen einzelnen Header, IFoo.h, der von Kunden und Server. Compiler hidl-gen mit dem IFoo.hal verwenden Schnittstellendatei als Eingabe verwendet, hat der binderisierte Modus Folgendes automatisch generiert: Dateien:

Abbildung 1: Vom Compiler generierte Dateien.

• IFoo.h Beschreibt die reine IFoo in einer C++-Klasse; enthält sie die Methoden und Typen, die in den IFoo-Schnittstelle in der Datei IFoo.hal, übersetzt in C++ -Typen an, wenn dies erforderlich ist. Enthält keine Details zum RPC-Mechanismus (z. B. HwBinder), der zur Implementierung dieser Schnittstelle verwendet wird. Die Klasse erhält einen Namespace mit dem Paket und der Version. Beispiel: ::android::hardware::samples::IFoo::V1_0 Sowohl Clients als auch Server Diesen Header einfügen: Clients zum Aufrufen von Methoden auf diesem und Server für um diese Methoden zu implementieren.
• IHwFoo.h Headerdatei mit -Deklarationen für Funktionen, die Datentypen serialisieren, die in der Schnittstelle verwendet werden. Entwickler sollten seinen Header niemals direkt einfügen, da er keine Klassen).
• BpHwFoo.h Eine Klasse, die Werte von IFoo und beschreibt den HwBinder-Proxy (clientseitig) Implementierung der Schnittstelle. Entwickler sollten niemals auf diese Klasse verweisen. .
• BnHwFoo.h Ein Kurs mit einem Verweis auf eine IFoo-Implementierung und Beschreibung der HwBinder-Stub-Implementierung der Schnittstelle (serverseitig). Entwickler sollten sich niemals direkt auf diese Klasse beziehen.
• FooAll.cpp Eine Klasse, die den Implementierungen für den HwBinder-Proxy und den HwBinder-Stub. Wenn ein Client eine Schnittstellenmethode aufruft, marschiert automatisch die Argumente des Clients und sendet die Transaktion, an den binder-Kernel-Treiber, der die Transaktion an den Stub auf der (wodurch dann die eigentliche Serverimplementierung aufgerufen wird).

Die Dateien sind ähnlich aufgebaut wie die Dateien, die von aidl-cpp (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, IFoo.h; Alle anderen Dateien sind an den verwendeten HwBinder-RPC-Mechanismus gebunden von HIDL. Client- und Serverimplementierungen sollten daher niemals sich direkt auf etwas anderes als IFoo beziehen. Ziel Dies, nur IFoo.h einfügen und mit den generierten geteilten Bibliothek.

Hinweis: HwBinder ist nur eine möglich. Transportwesen; werden möglicherweise in Zukunft weitere hinzugefügt.

Link zu geteilten Fotogalerien

Ein Client oder Server, der eine beliebige Schnittstelle in einem Paket verwendet, muss den Parameter gemeinsam genutzte Bibliothek dieses Pakets in einem (1) der folgenden Standorte:

• 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 einbeziehen müssen:

libhidlbase	Umfasst Standard-HIDL-Datentypen. In Android starten 10 enthält, enthält sie auch alle Symbole, die zuvor in libhidltransport und libhwbinder.
libhidltransport	Steuert die Übertragung von HIDL-Aufrufen über verschiedene RPC/IPC-Mechanismen. In Android 10 wird diese Bibliothek eingestellt.
libhwbinder	Bindungsspezifische Symbole. Android 10 wird diese Bibliothek verworfen.
libfmq	IPC für schnelle Nachrichtenwarteschlange.

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. Beispiel: Ein Paket mypackage mit Version 1.2 unter hardware/interfaces hat folgende Eigenschaften:

• C++-Namespace ist ::android::hardware::mypackage::V1_2
• Voll qualifizierter Name von IMyInterface in diesem Feld: Paket ist: ::android::hardware::mypackage::V1_2::IMyInterface. (IMyInterface ist eine Kennung, nicht Teil des Namespace).
• Typen, die in der Datei types.hal des Pakets definiert sind sind identifiziert als: ::android::hardware::mypackage::V1_2::MyPackageType