Pakiety

Z nielicznymi wyjątkami pakiety interfejsu HIDL znajdują się w katalogu hardware/interfaces lub vendor/. Katalog najwyższego poziomu hardware/interfaces jest mapowany bezpośrednio na przestrzeń nazw pakietu android.hardware. Wersja jest podkatalogiem w przestrzeni nazw pakietu (a nie interfejsu).

Kompilator hidl-gen kompiluje pliki .hal w zbiór plików .h i .cpp. Na podstawie tych plików wygenerowanych automatycznie tworzy się bibliotekę współdzieloną, do której odwołują się implementacje klienta i serwera. Plik Android.bp, który tworzy tę bibliotekę współdzieloną, jest generowany automatycznie przez skrypt hardware/interfaces/update-makefiles.sh. Za każdym razem, gdy dodasz nowy pakiet do hardware/interfaces lub dodasz/usuń pliki .hal do/z istniejącego pakietu, musisz ponownie uruchomić skrypt, aby mieć pewność, że wygenerowana biblioteka współdzielona jest aktualna.

Przykładowy plik IFoo.hal powinien znajdować się w folderze hardware/interfaces/samples/1.0. Plik przykładowy IFoo.hal tworzy interfejs IFoo w pakiecie samples:

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);
};

Wygenerowane pliki

Automatycznie wygenerowane pliki w pakiecie HIDL są łączone w jedną wspólną bibliotekę o tej samej nazwie co pakiet (np. [email protected]). Biblioteka wspólna eksportuje też jeden nagłówek (IFoo.h), który może być uwzględniany przez klientów i serwery. W trybie binderized kompilator hidl-gen używa jako danych wejściowych pliku interfejsu IFoo.hal. W ramach tego trybu generowane są te pliki:

pliki wygenerowane przez kompilator;

Rysunek 1. Pliki wygenerowane przez kompilator.

  • IFoo.h. Opisuje czysty interfejs IFoo w klasie C++, zawiera metody i typy zdefiniowane w interfejsie IFoo w pliku IFoo.hal, przetłumaczone w razie potrzeby na typy C++. Nie zawiera szczegółów związanych z mechanizmem RPC (np. HwBinder) używanym do implementacji tego interfejsu. Klasa jest umieszczona w przestrzeni nazw z pakietem i wersją, np. ::android::hardware::samples::IFoo::V1_0. Zarówno klienci, jak i serwery zawierają ten nagłówek: klienci, aby wywoływać metody, a serwery, aby implementować te metody.
  • IHwFoo.h. Plik nagłówka zawierający deklaracje funkcji, które serializują typy danych używane w interfejsie. Programiści nie powinni nigdy bezpośrednio uwzględniać tego nagłówka (nie zawiera on żadnych klas).
  • BpHwFoo.h. Klasa dziedzicząca z IFoo i opisująca implementację interfejsu HwBinder po stronie klienta. Deweloperzy nie powinni bezpośrednio odwoływać się do tej klasy.
  • BnHwFoo.h. Klasa, która przechowuje odwołanie do implementacji IFoo i opisuje implementację HwBinder stuba (po stronie serwera) interfejsu. Deweloperzy nie powinni nigdy odwoływać się bezpośrednio do tej klasy.
  • FooAll.cpp. Klasa zawierająca implementacje zarówno dla obiektu zastępczego HwBinder, jak i elementu stub HwBinder. Gdy klient wywołuje metodę interfejsu, usługa proxy automatycznie tworzy argumenty od klienta i wysyła transakcję do modułu jądra bindera, który przekazuje ją do stuba po drugiej stronie (a ten wywołuje rzeczywistą implementację serwera).

Pliki mają strukturę podobną do plików wygenerowanych przez narzędzie aidl-cpp (szczegółowe informacje znajdziesz w sekcji „Tryb przekazywania” w omówieniu HIDL). Jedynym generowanym automatycznie plikiem, który jest niezależny od mechanizmu RPC używanego przez HIDL, jest plikIFoo.h. Wszystkie inne pliki są powiązane z mechanizmem HwBinder RPC używanym przez HIDL. Dlatego implementacje po stronie klienta i serwera nie powinny bezpośrednio odwoływać się do niczego innego niż IFoo. Aby to zrobić, uwzględnij tylko IFoo.h i utwórz link do wygenerowanej współdzielonej biblioteki.

Klient lub serwer, który korzysta z dowolnego interfejsu w pakiecie, musi zawierać bibliotekę współdzieloną tego pakietu w jednej (1) z tych lokalizacji:

  • W pliku Android.mk: 
    LOCAL_SHARED_LIBRARIES += android.hardware.samples@1.0
  • W pliku Android.bp: 
    shared_libs: [
    /* ... */
    "[email protected]",
],

Dodatkowe biblioteki, które możesz uwzględnić:

libhidlbase Obejmuje standardowe typy danych HIDL. Począwszy od Androida 10, obejmuje ona również wszystkie symbole, które wcześniej znajdowały się w sekcjach libhidltransport i libhwbinder.
libhidltransport Przetwarza wywołania HIDL za pomocą różnych mechanizmów RPC/IPC. W Androidzie 10 ta biblioteka jest wycofana.
libhwbinder Symbole dotyczące wiązania. W Androidzie 10 ta biblioteka jest wycofywana.
libfmq IPC kolejki szybkich wiadomości.

Przestrzenie nazw

Funkcje i typy HIDL, takie jak Return<T> i Void(), są deklarowane w przestrzeni nazw ::android::hardware. Przestrzeń nazw C++ pakietu jest określana przez nazwę i wersję pakietu. Na przykład pakiet mójpakiet w wersji 1.2 w ramach pakietu hardware/interfaces ma te właściwości:

  • Przestrzeń nazw C++ to: ::android::hardware::mypackage::V1_2
  • Pełna i jednoznaczna nazwa IMyInterface w tym pakiecie to: ::android::hardware::mypackage::V1_2::IMyInterface. (IMyInterface to identyfikator, który nie należy do przestrzeni nazw).
  • Typy zdefiniowane w pliku types.hal pakietu są identyfikowane jako:::android::hardware::mypackage::V1_2::MyPackageType