Pacchetti

Con poche eccezioni, i pacchetti di interfaccia HIDL si trovano in hardware/interfaces o nella directory vendor/ . Il livello superiore hardware/interfaces viene mappato direttamente allo spazio dei nomi del pacchetto android.hardware ; la versione è una sottodirectory nello spazio dei nomi del pacchetto (non dell'interfaccia).

Il compilatore hidl-gen compila i file .hal in un insieme di file .h e .cpp . Da questi file generati automaticamente viene creata una libreria condivisa a cui si collegano le implementazioni client/server. Il file Android.bp che crea questa libreria condivisa viene generato automaticamente dallo script hardware/interfaces/update-makefiles.sh . Ogni volta che aggiungi un nuovo pacchetto a hardware/interfaces o aggiungi/rimuovi file .hal a/da un pacchetto esistente, devi eseguire nuovamente lo script per assicurarti che la libreria condivisa generata sia aggiornata.

Ad esempio, il file di esempio IFoo.hal dovrebbe trovarsi in hardware/interfaces/samples/1.0 . Il file IFoo.hal di esempio crea un'interfaccia IFoo nel pacchetto degli esempi :

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

File generati

I file generati automaticamente in un pacchetto HIDL sono collegati a un'unica libreria condivisa con lo stesso nome del pacchetto (ad esempio, android.hardware.samples@1.0 ). La libreria condivisa esporta anche una singola intestazione, IFoo.h , che può essere inclusa da client e server. Utilizzando il compilatore hidl-gen con il file di interfaccia IFoo.hal come input, la modalità binderizzata ha i seguenti file generati automaticamente:

• IFoo.h . Descrive l'interfaccia IFoo pura in una classe C++; contiene i metodi e i tipi definiti nell'interfaccia IFoo nel file IFoo.hal , tradotti in tipi C++ dove necessario. Non contiene dettagli relativi al meccanismo RPC (ad esempio, HwBinder ) utilizzato per implementare questa interfaccia. La classe ha uno spazio dei nomi con il pacchetto e la versione, ad esempio ::android::hardware::samples::IFoo::V1_0 . Sia i client che i server includono questa intestazione: Client per chiamare metodi su di esso e server per implementare tali metodi.
• IHwFoo.h . File di intestazione che contiene dichiarazioni per funzioni che serializzano i tipi di dati utilizzati nell'interfaccia. Gli sviluppatori non dovrebbero mai includere direttamente la sua intestazione (non contiene alcuna classe).
• BpHwFoo.h . Una classe che eredita da IFoo e descrive l'implementazione del proxy HwBinder (lato client) dell'interfaccia. Gli sviluppatori non dovrebbero mai fare riferimento direttamente a questa classe.
• BnHwFoo.h . Una classe che contiene un riferimento a un'implementazione IFoo e descrive l'implementazione stub HwBinder (lato server) dell'interfaccia. Gli sviluppatori non dovrebbero mai fare riferimento direttamente a questa classe.
• FooAll.cpp . Una classe che contiene le implementazioni sia per il proxy HwBinder che per lo stub HwBinder . Quando un client chiama un metodo di interfaccia, il proxy effettua automaticamente il marshalling degli argomenti dal client e invia la transazione al driver del kernel del raccoglitore, che consegna la transazione allo stub sull'altro lato (che poi chiama l'effettiva implementazione del server).

I file sono strutturati in modo simile ai file generati da aidl-cpp (per i dettagli vedere "Modalità passthrough" nella panoramica HIDL ). L'unico file generato automaticamente indipendente dal meccanismo RPC utilizzato da HIDL è IFoo.h ; tutti gli altri file sono legati al meccanismo RPC HwBinder utilizzato da HIDL. Pertanto, le implementazioni client e server non dovrebbero mai fare riferimento direttamente a qualcosa di diverso da IFoo . Per raggiungere questo obiettivo, includere solo IFoo.h e collegarlo alla libreria condivisa generata.

Collegamento a librerie condivise

Un client o server che utilizza qualsiasi interfaccia in un pacchetto deve includere la libreria condivisa di quel pacchetto in una (1) delle seguenti posizioni:

• In Android.mk :

  LOCAL_SHARED_LIBRARIES += android.hardware.samples@1.0
  

• In Android.bp :

  shared_libs: [
      /* ... */
      "android.hardware.samples@1.0",
  ],
  

Librerie aggiuntive che potresti dover includere:

Spazi dei nomi

Le funzioni e i tipi HIDL come Return<T> e Void() sono dichiarati nello spazio dei nomi ::android::hardware . Lo spazio dei nomi C++ di un pacchetto è determinato dal nome e dalla versione del pacchetto. Ad esempio, un pacchetto mypackage con la versione 1.2 in hardware/interfaces ha le seguenti qualità:

• Lo spazio dei nomi C++ è ::android::hardware::mypackage::V1_2
• Il nome completo di IMyInterface nel pacchetto è: ::android::hardware::mypackage::V1_2::IMyInterface . ( IMyInterface è un identificatore, non fa parte dello spazio dei nomi).
• I tipi definiti nel file types.hal del pacchetto sono identificati come: ::android::hardware::mypackage::V1_2::MyPackageType