Forniamo un'implementazione di riferimento per AIDL VHAL. Il thread del servizio principale è implementato
in
VehicleService.cpp
.
L'implementazione dell'interfaccia VHAL si trova in
DefaultVehicleHal.cpp
.
L'implementazione di riferimento si basa su un'architettura a due livelli. Nel livello superiore,
DefaultVehicleHal
, implementa l'interfaccia VHAL AIDL e fornisce la logica VHAL
generica per tutti i dispositivi hardware. Nel livello inferiore, FakeVehicleHardware
,
implementa l'interfaccia IVehicleHardware
. Questa classe simula la logica VHAL
di interazione con l'hardware o il bus del veicolo effettivi ed è specifica per il dispositivo. Facoltativamente, i fornitori
possono adattare questa stessa architettura, riutilizzare la stessa classe DefaultVehicleHal
(estendendola
per sovrascrivere un metodo) e fornire la propria implementazione IVehicleHardware
.
DefaultVehicleHal
contiene la seguente logica, considerata generica e applicabile a qualsiasi implementazione VHAL.
- Implementa l'interfaccia
IVehicle
. - Esegue controlli di base sull'input, incluso un controllo per ID duplicati.
- Alloca oggetti client (ad esempio,
GetValuesClient
) per ogni operazione per ogni client binder e li aggiunge a un pool globale. - Gestisce la logica dei callback asincroni, ad esempio l'aggiunta di una richiesta in attesa a un pool di richieste in attesa. Risolve le richieste in attesa quando riceviamo i risultati o restituisce un errore quando una delle richieste in attesa scade.
- Serializza e deserializza
LargeParcelable
(vediParcelableUtils.h
). - Gestisce l'abbonamento (vedi
SubscriptionManager.h
). - Controlla le autorizzazioni. (vedi le funzioni
checkReadPermission
echeckWritePermission
). - Chiama periodicamente
IVehicleHardware.checkHealth
e invia segnali di battito cardiaco (vedi la funzionecheckHealth
).
IVehicleHardware
è un'interfaccia generica utilizzata per rappresentare un'implementazione
specifica dell'hardware di VHAL. L'implementazione di riferimento per IVehicleHardware
è
FakeVehicleHardware
,
che utilizza una mappa in memoria per memorizzare il valore della proprietà e
non comunica con un bus del veicolo effettivo. È progettato per essere eseguito su un emulatore e non ha
dipendenze specifiche dell'hardware. Le implementazioni del fornitore non devono utilizzarlo così com'è e devono aggiungere
una logica specifica per il bus del veicolo.
A partire da Android 14, FakeVehicleHardware
legge la configurazione delle proprietà supportate in fase di runtime
durante l'inizializzazione dalla cartella /vendor/etc/automotive/vhalconfig/
del dispositivo,
che contiene un file di configurazione in stile JSON. Consulta il
file README di riferimento VHAL
per il formato e il contenuto del file di configurazione.
FakeVehicleHardware
supporta anche l'override del file di configurazione per i test. Se è impostata la proprietà di sistema persist.vendor.vhal_init_value_override
(questa proprietà deve essere impostata al momento della compilazione o molto presto durante l'avvio prima dell'inizializzazione di VHAL), utilizza il file di configurazione della cartella /vendor/etc/automotive/vhaloverride/
sul dispositivo per eseguire l'override della configurazione esistente. L'implementazione di un fornitore può utilizzare un approccio simile in modo che la configurazione delle proprietà supportate da VHAL non sia hardcoded e possa essere decisa dinamicamente all'avvio.
L'elenco delle configurazioni delle proprietà del veicolo deve essere statico dopo l'inizializzazione di VHAL.
A partire da Android 16, GRPCVehicleHardware
fornisce un'altra implementazione di riferimento di IVehicleHardware
. Questa implementazione
presuppone che esista un server separato in esecuzione su una macchina remota o una VM che contiene la logica di gestione delle proprietà. La VHAL in esecuzione sui dispositivi AAOS funge da proxy che inoltra le richieste al server remoto. Per maggiori dettagli, consulta la pagina grpc.