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'interfacciaIFoo
pura in una classe C++; contiene i metodi e i tipi definiti nell'interfacciaIFoo
nel fileIFoo.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 daIFoo
e descrive l'implementazione del proxyHwBinder
(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'implementazioneIFoo
e descrive l'implementazione stubHwBinder
(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 proxyHwBinder
che per lo stubHwBinder
. 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:
libhidlbase | Include tipi di dati HIDL standard. A partire da Android 10, questo contiene anche tutti i simboli precedentemente presenti in libhidltransport e libhwbinder . |
---|---|
libhidltransport | Gestisce il trasporto delle chiamate HIDL su diversi meccanismi RPC/IPC. Android 10 depreca questa libreria. |
libhwbinder | Simboli specifici del raccoglitore. Android 10 depreca questa libreria. |
libfmq | IPC coda messaggi veloce. |
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