Sensors Multi-HAL è un framework che consente ai sensori HAL di funzionare insieme ad altri HAL di sensori. L'opzione Sensors Multi-HAL carica dinamicamente gli HAL secondari dei sensori memorizzati come librerie dinamiche sulla partizione del fornitore e fornisce loro un oggetto di callback in grado di gestire gli eventi di pubblicazione e l'acquisizione e il rilascio del wakelock. Un HAL dei sensori è un HAL di sensori integrato in un oggetto condiviso sulla partizione del fornitore e utilizzato dal framework multi-HAL. Questi sub-HAL non dipendono l'uno dall'altro o dal codice multi-HAL che contiene la funzione principale del processo.
Sensori Multi-HAL 2.1, disponibile sui dispositivi con Android 11 o versioni successive, è un'iterazione dei sensori Multi-HAL 2.0 che supporta il caricamento di HAL secondari in grado di esporre il tipo di sensore di angolo della cerniera. Per supportare questo tipo di sensore, gli HAL secondari devono utilizzare le API sub-HAL definite nell'intestazione 2.1 SubHal.
Per i dispositivi con Android 13 o versioni successive che utilizzano Sensors AIDL HAL, puoi utilizzare il livello di shim multi-HAL per consentire la funzionalità multi-HAL. Per i dettagli sull'implementazione, consulta la pagina Utilizzo di Sensors Multi-HAL con Sensors AIDL HAL.
Differenza tra sensori Multi-HAL 2 e sensori HAL 2
Sensori Multi-HAL 2, disponibile su dispositivi con Android
10 o versioni successive,
introduce diverse astrazioni oltre a Sensors HAL
2 per facilitare
l'interazione con le API HAL. Sensors Multi-HAL 2 introduce la classe HalProxy per gestire l'implementazione dell'interfaccia HAL 2 dei sensori e dell'interfaccia V2_1/SubHal
(o V2_0/SubHal
) per consentire a HalProxy
di interagire con gli HAL secondari.
L'interfaccia ISensorsSubHal
è diversa dall'interfaccia
2.1/ISensors.hal
(o
2.0/ISensors.hal
)
per i seguenti modi:
- Il metodo di inizializzazione passa una classe
IHalProxyCallback
anziché due FMQ eISensorsCallback
. - Gli HAL secondari devono implementare una funzione di debug che consenta di fornire informazioni di debug nelle segnalazioni di bug.
- Gli HAL secondari devono implementare una funzione di nome in modo che l'HAL secondario caricato possa essere distinto da altri HAL secondari.
La differenza principale tra i sensori Multi-HAL 2 e i sensori HAL 2 consiste nelle funzioni di inizializzazione. Invece di fornire gli FMQ, l'interfaccia IHalProxyCallback
offre due metodi: uno per pubblicare gli eventi dei sensori nel framework dei sensori
e un metodo per creare wakelock. dietro le quinte, il Multi-HAL gestisce tutte le interazioni con gli FMQ per garantire la consegna tempestiva degli eventi dei sensori per tutti gli HAL secondari. Consigliamo vivamente agli HAL secondari di utilizzare il metodo createScopedWakelock
per delegare l'onere del timeout dei wakelock all'HAL Multi-HAL dei sensori e di centralizzare l'utilizzo dei wakelock a un wakelock comune per l'intero HAL per i sensori, in modo da ridurre al minimo le chiamate di blocco e sblocco.
Sensori L'Multi-HAL 2 dispone anche di alcune funzioni di sicurezza integrate. Gestisce
le situazioni in cui il valore FMQ del sensore è pieno o in cui il framework dei sensori Android
si riavvia e lo stato del sensore deve essere reimpostato. Inoltre, quando gli eventi vengono
pubblicati nella classe HalProxy
ma il framework dei sensori non è in grado di accettarli
immediatamente, il multi-HAL dei sensori può spostare gli eventi in un thread in background
per consentire il lavoro in tutti gli HAL secondari in attesa
della pubblicazione degli eventi.
Implementazione del codice sorgente e del riferimento
Tutti i codici dell'HAL per i sensori sono disponibili in
hardware/interfaces/sensors/common/default/2.X/multihal/
.
Di seguito sono riportati alcuni rimandi ad alcune risorse.
HalProxy.h
: l'oggettoHalProxy
viene creato da Sensors multi-HAL e gestisce il passaggio dei dati dagli HAL secondari al framework dei sensori.HalProxy.cpp
: l'implementazione diHalProxy
contiene tutta la logica necessaria per la comunicazione multiplex tra gli HAL secondari e il framework dei sensori.SubHal.h
: L'interfacciaISensorsSubHal
definisce l'interfaccia che gli HAL secondari devono seguire per essere compatibile conHalProxy
. L'HAL secondario implementa il metodo di inizializzazione in modo che l'oggettoHalProxyCallback
possa essere utilizzato perpostEvents
ecreateScopedWakelock
.Per le implementazioni Multi-HAL 2.0, utilizza la versione 2.0 di
SubHal.h
.hardware/interfaces/sensors/common/default/2.X/multihal/tests/
: questi test delle unità verificano l'implementazione diHalProxy
.hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/
: Questo esempio di implementazione dell'HAL utilizza sensori falsi per generare dati falsi. Utile per verificare l'interazione di più HAL secondari su un dispositivo.
Implementazione
Questa sezione descrive come implementare i sensori Multi-HAL nelle seguenti situazioni:
- Utilizzo di Sensors Multi-HAL con Sensors AIDL HAL
- Implementazione di sensori Multi-HAL 2.1
- Trasferimento da Sensori Multi-HAL 2.0 a Multi-HAL 2.1
- Portabilità dai sensori HAL 2.0
- Portabilità dai sensori HAL 1.0
- Portabilità da sensori Multi-HAL 1.0
Utilizzo di Sensors Multi-HAL con Sensors AIDL HAL
Per consentire la funzionalità multi-HAL con l'HAL per i sensori AIDL, importa il modulo dello shim Layer AIDL Multi-HAL, che si trova in hardware/interfaces/sensors/aidl/default/multihal/. Il modulo gestisce la conversione tra i tipi di definizione HAL dei sensori AIDL e HIDL e definisce un wrapper attorno all'interfaccia multi-HAL descritta in Implementazione di sensori Multi-HAL 2.1. Lo strato di spessore AIDL multi-HAL è compatibile con i dispositivi che implementano l'opzione Sensori Multi-HAL 2.1.
Lo strato di spessore AIDL multi-HAL consente di esporre il tracker della testa e
i tipi di sensori IMU ad asse limitato nei Sensors AIDL HAL. Per utilizzare questi tipi di sensori definiti dall'interfaccia AIDL HAL, imposta il campo type
nello struct SensorInfo
nell'implementazione getSensorsList_2_1()
. Questo è sicuro
perché i campi dei tipi di sensori con supporto di numeri interi dei sensori AIDL e HIDL HAL
non si sovrappongono.
Implementazione di sensori Multi-HAL 2.1
Per implementare i sensori Multi-HAL 2.1 su un nuovo dispositivo, segui questi passaggi:
- Implementa l'interfaccia
ISensorsSubHal
come descritto inSubHal.h
. - Implementa il metodo
sensorsHalGetSubHal_2_1
inSubHal.h
. Aggiungi un target
cc_library_shared
per creare l'HAL secondario appena implementato. Quando aggiungi il target:- Assicurati che il push del target venga inviato a una qualche parte della partizione del fornitore del dispositivo.
- Nel file di configurazione all'indirizzo
/vendor/etc/sensors/hals.conf
, aggiungi il percorso della libreria su una nuova riga. Se necessario, crea il filehals.conf
.
Per un esempio di voce
Android.bp
per la creazione di una libreria sub-HAL, consultahardware/interfaces/sensors/common/default/2.X/multihal/tests/Android.bp
.Rimuovi tutte le voci
android.hardware.sensors
dal filemanifest.xml
, che contiene l'elenco degli HAL supportati sul dispositivo.Rimuovi tutti i servizi
android.hardware.sensors
e i fileservice.rc
dal filedevice.mk
e aggiungiandroid.hardware.sensors@2.1-service.multihal
eandroid.hardware.sensors@2.1-service.multihal.rc
aPRODUCT_PACKAGES
.
All'avvio, HalProxy
si avvia, cerca l'HAL secondario appena implementato e
lo inizializza richiamando
sensorsHalGetSubHal_2_1
.
Porta da Sensori Multi-HAL 2.0 a Multi-HAL 2.1
Per eseguire la porta da Multi-HAL 2.0 a Multi-HAL 2.1, implementa l'interfaccia SubHal
e ricompila l'HAL secondario.
Ecco le differenze tra le interfacce 2.0 e 2.1 di SubHal
:
IHalProxyCallback
utilizza i tipi creati nella versione 2.1 della specificaISensors.hal
.- La funzione
initialize()
trasmette un nuovoIHalProxyCallback
anziché quello dell'interfaccia 2.0SubHal
- Gli HAL secondari devono implementare
getSensorsList_2_1
einjectSensorData_2_1
anzichégetSensorsList
einjectSensorData
, poiché questi metodi utilizzano i nuovi tipi aggiunti nella versione 2.1 della specificaISensors.hal
. - Gli HAL secondari devono esporre
sensorsHalGetSubHal_2_1
anzichésensorsHalGetSubHal
affinché l'HAL multiplo li consideri come HAL secondari della versione 2.1.
Porta da sensori HAL 2.0
Quando esegui l'upgrade a Sensors Multi-HAL 2.0 da Sensors HAL 2.0, assicurati che l'implementazione dell'HAL soddisfi i seguenti requisiti.
Inizializzare l'HAL
I sensori HAL 2.0 hanno una funzione di inizializzazione che consente al servizio dei sensori di superare gli FMQ e un callback del sensore dinamico. In Sensori Multi-HAL 2.0, la
funzione initialize()
passa un singolo callback che deve essere utilizzato per pubblicare
gli eventi dei sensori, ottenere wakelock e notificare la connessione e le
disconnessioni dei sensori dinamici.
Dopo gli eventi dei sensori nell'implementazione Multi-HAL
Anziché pubblicare gli eventi dei sensori tramite FMQ, l'HAL secondario deve scrivere gli eventi dei sensori in IHalProxyCallback
quando sono disponibili.
Eventi WAKE_UP
Nei sensori HAL 2.0, l'HAL può gestire il wakelock per la sua implementazione. In Sensors Multi-HAL 2.0, gli HAL secondari consentono all'implementazione Multi-HAL di gestire i wakelock e possono richiedere l'acquisizione di un wakelock richiamando createScopedWakelock
.
Un wakelock con ambito bloccato deve essere acquisito e passato a postEvents
quando
vengono pubblicati eventi di wakeup nell'implementazione Multi-HAL.
Sensori dinamici
Sensori Multi-HAL 2.0 richiede che onDynamicSensorsConnected
e
onDynamicSensorsDisconnected
in
IHalProxyCallback
vengano richiamati ogni volta che le connessioni dei sensori dinamici cambiano. Questi callback sono disponibili come parte del puntatore IHalProxyCallback
fornito tramite la funzione initialize()
.
Porta da sensori HAL 1.0
Quando esegui l'upgrade a Sensors Multi-HAL 2.0 da Sensors HAL 1.0, assicurati che l'implementazione dell'HAL soddisfi i seguenti requisiti.
Inizializzare l'HAL
La funzione initialize()
deve essere supportata per stabilire il callback tra l'implementazione sub-HAL e l'implementazione Multi-HAL.
Esposizione dei sensori disponibili
In Sensori Multi-HAL 2.0, la funzione getSensorsList()
deve restituire lo stesso
valore durante l'avvio di un singolo dispositivo, anche tra i sensori che l'HAL si riavvia. In questo modo il framework può tentare di ristabilire le connessioni dei sensori al riavvio del server di sistema. Il valore restituito da getSensorsList()
può cambiare dopo il riavvio del dispositivo.
Dopo gli eventi dei sensori nell'implementazione Multi-HAL
Nei sensori HAL 2.0, invece di attendere la chiamata di poll()
, l'HAL secondario
deve scrivere in modo proattivo gli eventi dei sensori in
IHalProxyCallback
ogni volta che sono disponibili eventi dei sensori.
Eventi WAKE_UP
Nei sensori HAL 1.0, l'HAL può gestire il wakelock per la sua implementazione. In Sensors Multi-HAL 2.0, gli HAL secondari consentono all'implementazione Multi-HAL di gestire i wakelock e possono richiedere l'acquisizione di un wakelock richiamando createScopedWakelock
.
Un wakelock con ambito bloccato deve essere acquisito e passato a postEvents
quando
vengono pubblicati eventi di wakeup nell'implementazione Multi-HAL.
Sensori dinamici
Nei sensori HAL 1.0, i sensori dinamici vengono restituiti tramite la funzione poll()
.
Sensori Multi-HAL 2.0 richiede che onDynamicSensorsConnected
e
onDynamicSensorsDisconnected
in
IHalProxyCallback
vengano richiamati ogni volta che le connessioni dei sensori dinamici cambiano. Questi callback sono disponibili come parte del puntatore IHalProxyCallback
fornito tramite la funzione initialize()
.
Porta da Sensors Multi-HAL 1.0
Per trasferire un'implementazione esistente da Sensors Multi-HAL 1.0, segui questi passaggi.
- Assicurati che la configurazione dell'HAL dei sensori si trovi in
/vendor/etc/sensors/hals.conf
. Potrebbe essere necessario spostare il file all'indirizzo/system/etc/sensors/hals.conf
. - Rimuovi tutti i riferimenti a
hardware/hardware.h
ehardware/sensors.h
poiché non sono supportati per HAL 2.0. - Porta gli HAL sub-HAL come descritto in Portabilità dai sensori Hal 1.0.
- Imposta i sensori Multi-HAL 2.0 come HAL designato seguendo i passaggi 3 e 4 nella sezione Implementazione di sensori Mutli-HAL 2.0.
Convalida
Esegui VTS
Dopo aver integrato uno o più HAL secondari con Sensors Multi-Hal 2.1, utilizza la Vendor Test Suite (VTS) per assicurarti che le implementazioni dell'HAL secondario soddisfino tutti i requisiti impostati dall'interfaccia dell'HAL per i sensori.
Per eseguire solo i test dei sensori VTS quando VTS è configurato su una macchina host, esegui i seguenti comandi:
vts-tradefed run commandAndExit vts \
--skip-all-system-status-check \
--primary-abi-only \
--skip-preconditions \
--module VtsHalSensorsV2_0Target && \
vts-tradefed run commandAndExit vts \
--skip-all-system-status-check \
--primary-abi-only \
--skip-preconditions \
--module VtsHalSensorsV2_1Target
Se utilizzi lo shim AIDL Multi-HAL, esegui VtsAidlHalSensorsTargetTest
.
vts-tradefed run commandAndExit vts \
--skip-all-system-status-check \
--primary-abi-only \
--skip-preconditions \
--module VtsAidlHalSensorsTargetTest
Esecuzione dei test delle unità
Il test delle unità in HalProxy_test.cpp
esegue il test HalProxy
utilizzando HAL sub-HAL fittizi che
vengono create in un'istanza nel test delle unità e non vengono caricati dinamicamente. Quando crei un nuovo HAL secondario, questi test dovrebbero servire come guida su come aggiungere test delle unità che verificano che il nuovo HAL secondario sia implementato correttamente.
Per eseguire i test, esegui questi comandi:
cd $ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests
atest
Eseguire test con gli HAL secondari falsi
Gli HAL secondari falsi sono implementazioni fittizie dell'interfaccia ISensorsSubHal
.
Gli HAL secondari espongono diversi elenchi di sensori. Quando i sensori vengono attivati,
pubblicano periodicamente eventi dei sensori generati automaticamente su HalProxy
in base agli intervalli specificati in una determinata richiesta di sensore.
I falsi sub-HAL possono essere utilizzati per testare il funzionamento del codice Multi-HAL completo con altri sub-HAL caricati nel sistema e per sottolineare vari aspetti del codice Multi-HAL dei sensori.
All'indirizzo hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/
sono disponibili due falsi sub-HAL.
Per creare ed eseguire il push di HAL secondari falsi a un dispositivo, procedi nel seguente modo:
Esegui questi comandi per creare ed eseguire il push dei tre diversi HAL secondari falsi al dispositivo:
$ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests/
mma
adb push \ $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so \ /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so
adb push \ $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so \ /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so
adb push \ $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so \ /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so
Aggiorna la configurazione dell'HAL dei sensori in
/vendor/etc/sensors/hals.conf
con i percorsi degli HAL secondari falsi./vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so
Riavvia
HalProxy
e carica i nuovi HAL secondari elencati nella configurazione.adb shell stop
adb shell start
Debug
Gli sviluppatori possono eseguire il debug del framework utilizzando il comando lshal
. Per richiedere l'output di debug dell'HAL per sensori, esegui questo comando:
adb root
adb shell lshal debug android.hardware.sensors@2.1::ISensors/default
Le informazioni sullo stato attuale di HalProxy
e sui relativi HAL secondari vengono quindi inviate al terminale. Di seguito è riportato un esempio dell'output comando per l'oggetto HalProxy
e gli HAL secondari falsi.
Internal values:
Threads are running: true
Wakelock timeout start time: 200 ms ago
Wakelock timeout reset time: 73208 ms ago
Wakelock ref count: 0
# of events on pending write queue: 0
# of non-dynamic sensors across all subhals: 8
# of dynamic sensors across all subhals: 0
SubHals (2):
Name: FakeSubHal-OnChange
Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2
Name: FakeSubHal-OnChange
Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2
Se il numero specificato per # of events on pending write queue
è
un numero elevato (1000 o più),
significa che ci sono molti eventi in attesa di essere scritti nel framework
dei sensori. Questo indica che il servizio dei sensori è in un deadlock o si è arrestato in modo anomalo e non sta elaborando gli eventi dei sensori oppure che un grande gruppo di eventi dei sensori è stato recentemente pubblicato da un sub-HAL.
Se il conteggio dei riferimenti di wakelock è superiore a 0
, significa che HalProxy
ha
acquisito un wakelock. Questo valore dovrebbe essere superiore a 0
solo se un ScopedWakelock
è stato intenzionalmente trattenuto o se gli eventi di wakeup sono stati inviati a HalProxy
e
non sono stati elaborati dal framework dei sensori.
Il descrittore del file passato al metodo di debug HalProxy
viene trasmesso a ogni
HAL secondario, per cui gli sviluppatori devono implementare il metodo di debug nell'interfaccia
ISensorsSubHal
.