Pacchetti

Con poche eccezioni, i pacchetti di interfacce HIDL si trovano in hardware/interfaces o la directory vendor/. La hardware/interfaces mappe di primo livello direttamente Spazio dei nomi 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 video generati automaticamente File di una libreria condivisa a cui si collegano le implementazioni client/server. Il file Android.bp che crea questa libreria condivisa è generato automaticamente dal hardware/interfaces/update-makefiles.sh lo script. Ogni volta che aggiungi un nuovo pacchetto a hardware/interfaces oppure aggiungi/rimuovi .hal file a/da un pacchetto esistente, devi eseguire nuovamente lo script per garantire che la libreria condivisa generata sia aggiornata.

Ad esempio, il file di esempio IFoo.hal deve trovarsi in hardware/interfaces/samples/1.0. L'esempio IFoo.hal crea un'interfaccia IFoo nella Pacchetto 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);
};

File generati

I file generati automaticamente in un pacchetto HIDL sono collegati in un'unica libreria con lo stesso nome del pacchetto (ad esempio, android.hardware.samples@1.0). La libreria condivisa esporta anche intestazione singola, IFoo.h, che può essere inclusa dai clienti e server web. Utilizzo del compilatore hidl-gen con l'elemento IFoo.hal di interfaccia come input, la modalità binderizzata ha la seguente generazione automatica file:

File generate dal compilatore

Figura 1. File generati dal compilatore.

  • IFoo.h. Descrive il valore IFoo puro interfaccia in una classe C++; contiene i metodi e i tipi definiti Interfaccia IFoo nel file IFoo.hal, tradotta in C++ tipi di connessione, ove 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 client che server includi questa intestazione: Client per chiamare metodi su questo oggetto e server per implementando questi metodi.
  • IHwFoo.h. File di intestazione che contiene le dichiarazioni per le funzioni che serializzano i tipi di dati utilizzati nell'interfaccia. Gli sviluppatori non devono mai includere direttamente la sua intestazione (non deve contenere .
  • BpHwFoo.h. Una classe che eredita da IFoo e descrive il proxy HwBinder (lato client) implementazione dell'interfaccia. Gli sviluppatori non devono mai fare riferimento a questo corso strato Add.
  • BnHwFoo.h. Un corso che contiene un riferimento a un'implementazione IFoo e descrive implementazione stub HwBinder (lato server) dell'interfaccia. Gli sviluppatori non devono mai fare riferimento direttamente a questo corso.
  • FooAll.cpp. Una classe che contiene implementazioni sia per il proxy HwBinder che per Stub HwBinder. Quando un client chiama un metodo di interfaccia, il proxy esegue automaticamente il marshalling degli argomenti dal client e invia la transazione al driver kernel binder, che consegna la transazione allo stub sulla dall'altro lato (che a sua volta chiama l'implementazione effettiva del server).

I file hanno una struttura simile a quella dei file generati aidl-cpp (per maggiori dettagli, vedi "Modalità passthrough" nella Panoramica HIDL). L'unico generato automaticamente che sia indipendente dal meccanismo RPC usato dall'HIDL sia IFoo.h; tutti gli altri file sono legati al meccanismo RPC HwBinder utilizzato di HIDL. Di conseguenza, le implementazioni di client e server non devono mai fare riferimento direttamente a qualsiasi altra attività diversa da IFoo. Per raggiungere questo include solo IFoo.h e il link rispetto alla condivisione generata libreria.

Un client o un server che utilizzi qualsiasi interfaccia di un pacchetto deve includere i campi libreria condivisa del pacchetto in una (1) delle seguenti opzioni località:

  • 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 i tipi di dati HIDL standard. A partire da Android 10, contiene anche tutti i simboli precedentemente presenti libhidltransport e libhwbinder.
libhidltransport Gestisce il trasporto delle chiamate HIDL su diversi meccanismi RPC/IPC. Android 10 ritira questa libreria.
libhwbinder Simboli specifici del legante. Android 10 ritira questa libreria.
libfmq IPC coda di messaggi veloce.

Spazi dei nomi

Funzioni e 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 versione 1.2 in hardware/interfaces ha le seguenti qualità:

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