Pakete

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 reine IFoo Schnittstelle in einer C++-Klasse; Es enthält die Methoden und Typen, die in der IFoo Schnittstelle in der Datei IFoo.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 von IFoo erbt und die HwBinder Proxy-Implementierung (clientseitig) der Schnittstelle beschreibt. Entwickler sollten niemals direkt auf diese Klasse verweisen.
• BnHwFoo.h . Eine Klasse, die einen Verweis auf eine IFoo Implementierung enthält und die HwBinder Stub-Implementierung (serverseitig) der Schnittstelle beschreibt. Entwickler sollten niemals direkt auf diese Klasse verweisen.
• FooAll.cpp . Eine Klasse, die die Implementierungen sowohl für den HwBinder Proxy als auch für den HwBinder 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:

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