Pakete

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:

Vom Compiler generierte Dateien

Abbildung 1: Vom Compiler generierte Dateien.

  • IFoo.h: Beschreibt die reine IFoo-Schnittstelle in einer C++-Klasse. Sie enthält die in der IFoo.hal-Datei in der IFoo-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 von IFoo abgeleitet ist und die HwBinder-Proxy-Implementierung (clientseitig) der Schnittstelle beschreibt. Entwickler sollten sich niemals direkt auf diese Klasse beziehen.
  • BnHwFoo.h: Eine Klasse, die einen Verweis auf eine IFoo-Implementierung enthält und die HwBinder-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 den HwBinder-Proxy als auch für den HwBinder-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.

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