Questa pagina è stata tradotta dall'API Cloud Translation.

Sensori Multi-HAL

Sensors Multi-HAL è un framework che consente ai sensori HAL di funzionare di altri sensori HAL. L'opzione Sensors Multi-HAL carica dinamicamente i sensori sub-HAL archiviati come librerie dinamiche nella partizione del fornitore e assegna loro un callback in grado di gestire eventi di pubblicazione e acquisizione e rilascio del wakelock. Un sensore sub-HAL è un HAL di sensori integrato in un oggetto condiviso sulla del fornitore ed è utilizzata dal framework multi-HAL. Questi sub-HAL non dipendono l'uno dall'altro o dal codice multi-HAL che contiene la funzione principale per il processo.

Sensori Multi-HAL 2.1, disponibile sui dispositivi con Android 11 o superiore, è un l'iterazione di sensori Multi-HAL 2.0 che supporta il caricamento di sub-HAL che possono esporre angolo cerniera tipo di sensore. Per supportare questo tipo di sensore, gli HAL sub-HAL devono utilizzare le API sub-HAL definita nel 2.1 Intestazione SubHal.

Per i dispositivi con Android 13 o versioni successive che utilizzano Sensors AIDL HAL, puoi utilizzare strato shim multi-HAL per consentire funzionalità multi-HAL. Per i dettagli dell'implementazione, vedi Utilizzo di Sensors Multi-HAL con Sensors AIDL HAL.

Differenza tra sensori Multi-HAL 2 e sensori HAL 2

Sensori Multi-HAL 2, disponibili sui dispositivi con Android 10 o successive, introduce diverse astrazioni oltre a Sensors HAL 2 per semplificare per interagire con le API HAL. Sensori Il Multi-HAL 2 introduce la HalProxy per gestire l'implementazione dell'interfaccia Sensors HAL 2 e V2_1/SubHal: (o V2_0/SubHal per consentire a HalProxy di interagire con gli HAL secondari.

L'interfaccia di ISensorsSubHal è diversa dalla 2.1/ISensors.hal (o 2.0/ISensors.hal) dell'interfaccia nel seguente modo:

Il metodo di inizializzazione trasmette un valore IHalProxyCallback anziché due FMQ e ISensorsCallback.
Gli HAL secondari devono implementare una funzione di debug per fornire il debug nelle segnalazioni di bug.
Gli HAL secondari devono implementare una funzione di nome in modo che l'HAL secondario caricato possa essere diversi dagli altri sub-HAL.

La differenza principale tra i sensori Multi-HAL 2 e i sensori HAL 2 sta nella inizializza le funzioni. Invece di fornire FMQ, IHalProxyCallback offre due metodi: uno per inviare gli eventi dei sensori ai sensori e un metodo per creare i wakelock. Uno sguardo ai sensori Multi-HAL gestisce tutte le interazioni con gli FMQ per garantire la consegna tempestiva dei degli eventi dei sensori per tutti gli HAL secondari. Consigliamo vivamente agli HAL secondari di utilizzare Metodo createScopedWakelock per delegare l'onere del timeout dei wakelock a l'uso dei sensori Multi-HAL e di centralizzare l'utilizzo dei wakelock in base a un solo wakelock comune per l'intero HAL Sensors, che riduce al minimo il blocco e lo sblocco delle chiamate.

Sensori L'Multi-HAL 2 dispone anche di alcune funzioni di sicurezza integrate. Gestisce situazioni in cui il valore FMQ del sensore è completo o il framework dei sensori Android e lo stato del sensore deve essere reimpostato. Inoltre, quando gli eventi pubblicato nel corso HalProxy, ma il framework del sensore non può essere accettato gli eventi immediatamente, l'HAL (Sensores Multi-HAL) può spostarli in background per consentire il proseguimento del lavoro in tutti gli HAL secondari in attesa eventi da pubblicare.

Implementazione del codice sorgente e del riferimento

Il codice Multi-HAL per tutti i sensori è disponibile in hardware/interfaces/sensors/common/default/2.X/multihal/ Di seguito sono riportati alcuni rimandi ad alcune risorse.

HalProxy.h: L'oggetto HalProxy viene creata da Sensors multi-HAL e gestisce trasferimento dei dati dagli HAL secondari al framework dei sensori.
HalProxy.cpp: L'implementazione di HalProxy contiene tutta la logica necessaria per comunicazione multiplex tra gli HAL secondari e il framework dei sensori.
SubHal.h: L'interfaccia ISensorsSubHal definisce l'interfaccia che gli HAL devono segui per essere compatibile con HalProxy. L'HAL secondario implementa di inizializzazione in modo che l'oggetto HalProxyCallback possa essere utilizzato postEvents e createScopedWakelock.

Per le implementazioni Multi-HAL 2.0, usare la versione 2.0 di SubHal.h
hardware/interfaces/sensors/common/default/2.X/multihal/tests/: Questi test delle unità verificano l'implementazione di HalProxy.
hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/: Questa implementazione di esempio sub-HAL utilizza sensori falsi per generare e i dati di Google Cloud. Utile per verificare l'interazione di più HAL secondari su un dispositivo.

Implementazione

Questa sezione descrive come implementare i sensori Multi-HAL nelle seguenti sezioni situazioni seguenti:

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, importare Modulo di strato shim Multi-HAL, disponibile in hardware/interfaces/sensors/aidl/default/multihal/. Il modulo gestisce la conversione tra la definizione dell'HAL dei sensori AIDL e HIDL dei tipi e definisce un wrapper intorno all'interfaccia multi-HAL descritta in Implementazione di sensori Multi-HAL 2.1. AIDL multi-HAL lo strato di spessore è compatibile con i dispositivi che implementano Sensori Multi-HAL 2.1.

Lo strato di spessore AIDL multi-HAL consente di esporre il tracker della testa e tipi di sensori IMU ad asse limitato nel Sensors AIDL HAL. Per usare questi sensori tipi definiti dall'interfaccia AIDL HAL, imposta il campo type nella struct SensorInfo nell'implementazione getSensorsList_2_1(). È sicuro perché i campi del tipo di sensore con supporto di numeri interi dei sensori AIDL e HIDL HAL non si sovrappongano.

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 in SubHal.h
Implementa il sensorsHalGetSubHal_2_1 in SubHal.h.
Aggiungi un target cc_library_shared per creare l'HAL secondario appena implementato. Quando aggiungi il target:
1. Assicurati che il target venga inviato a una destinazione sul fornitore del dispositivo.
2. Nel file di configurazione all'indirizzo /vendor/etc/sensors/hals.conf, aggiungere il percorso alla libreria su una nuova riga. Se necessario, crea hals.conf.
Per un esempio di voce Android.bp per la creazione di una libreria sub-HAL, consulta hardware/interfaces/sensors/common/default/2.X/multihal/tests/Android.bp
Rimuovi tutte le voci android.hardware.sensors dalla manifest.xml che contiene l'elenco degli HAL supportati sul dispositivo.
Rimuovi tutti i servizi android.hardware.sensors e service.rc file da il file device.mk e aggiungi android.hardware.sensors@2.1-service.multihal e da android.hardware.sensors@2.1-service.multihal.rc a PRODUCT_PACKAGES,

All'avvio, HalProxy si avvia, cerca l'HAL secondario appena implementato e la inizializza richiamando sensorsHalGetSubHal_2_1

Porta da Sensori Multi-HAL 2.0 a Multi-HAL 2.1

Per trasferire da Multi-HAL 2.0 a Multi-HAL 2.1, implementare SubHal e ricompilare l'HAL secondario.

Ecco le differenze tra le interfacce 2.0 e 2.1 di SubHal:

IHalProxyCallback utilizza i tipi creati in versione 2.1 della specifica ISensors.hal.
La funzione initialize() trasmette un nuovo IHalProxyCallback invece di quella dell'interfaccia 2.0 SubHal
Gli HAL secondari devono implementare getSensorsList_2_1 e injectSensorData_2_1 anziché getSensorsList e injectSensorData poiché questi metodi utilizzano i nuovi tipi aggiunti nella versione 2.1 della specifica ISensors.hal.
Gli HAL secondari devono esporre sensorsHalGetSubHal_2_1 anziché sensorsHalGetSubHal per l'HAL Multi-HAL per considerarli come versione 2.1 sub-HAL.

Porta da sensori HAL 2.0

In caso di upgrade a Sensors Multi-HAL 2.0 da Sensors HAL 2.0, assicurati che l'HAL la tua implementazione soddisfi i seguenti requisiti.

Inizializzare l'HAL

Sensori HAL 2.0 ha una funzione di inizializzazione che consente al servizio superare gli FMQ e il callback del sensore dinamico. Nella sezione Sensori Multi-HAL 2.0, La funzione initialize() passa un singolo callback che deve essere utilizzato per pubblicare eventi dei sensori, ottenere wakelock, nonché notificare la connessione dei sensori dinamici e disconnessioni.

Dopo gli eventi dei sensori nell'implementazione Multi-HAL

Anziché pubblicare gli eventi del sensore tramite FMQ, l'HAL secondario deve scrivere il sensore eventi alla IHalProxyCallback quando sono disponibili eventi dei sensori.

Eventi WAKE_UP

Nei sensori HAL 2.0, l'HAL può gestire il wakelock per la sua implementazione. Nella Sensori Multi-HAL 2.0, i sub-HAL consentono l'implementazione gestire i wakelock e richiedere l'acquisizione di un wakelock richiamando createScopedWakelock Un wakelock con ambito bloccato deve essere acquisito e passato a postEvents quando pubblicare eventi di riattivazione nell'implementazione Multi-HAL.

Sensori dinamici

Sensori Multi-HAL 2.0 richiede che onDynamicSensorsConnected e onDynamicSensorsDisconnected pollici IHalProxyCallback: vengono richiamati ogni volta che le connessioni dei sensori dinamici cambiano. Questi callback vengono disponibile come parte del puntatore IHalProxyCallback fornito tramite la funzione initialize().

Porta da sensori HAL 1.0

In caso di upgrade a Sensors Multi-HAL 2.0 da Sensors HAL 1.0, assicurati che l'HAL la tua implementazione 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 durante l'avvio di un singolo dispositivo, anche tra i sensori che l'HAL si riavvia. Ciò consente il framework per tentare di ristabilire le connessioni dei sensori se il server di sistema si riavvia. Il valore restituito da getSensorsList() può cambiare dopo il dispositivo esegue un riavvio.

Dopo gli eventi dei sensori nell'implementazione Multi-HAL

Nei sensori HAL 2.0, invece di attendere la chiamata poll(), viene usato lo stato sub-HAL devono scrivere in modo proattivo gli eventi dei sensori 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. Nella Sensori Multi-HAL 2.0, il sub-HAL consente l'implementazione gestire i wakelock e richiedere l'acquisizione di un wakelock richiamando createScopedWakelock Un wakelock con ambito bloccato deve essere acquisito e passato a postEvents quando pubblicare eventi di riattivazione 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 pollici IHalProxyCallback: vengono richiamati ogni volta che le connessioni dei sensori dinamici cambiano. Questi callback vengono disponibile come parte del puntatore IHalProxyCallback fornito tramite la funzione initialize().

Porta da Sensors Multi-HAL 1.0

Per trasferire un'implementazione esistente Sensori Multi-HAL 1.0, segui questa procedura.

Assicurati che la configurazione dell'HAL dei sensori si trovi in /vendor/etc/sensors/hals.conf. Questa operazione potrebbe comportare lo spostamento del file alle ore /system/etc/sensors/hals.conf.
Rimuovi eventuali riferimenti a hardware/hardware.h e hardware/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 le fasi 3 e 4 nella sezione Implementazione di sensori Mutli-HAL 2.0.

Convalida

Esegui VTS

Se hai integrato uno o più HAL secondari con i sensori Multi-Hal 2.1, Utilizza la suite di prova del fornitore (VTS) per assicurarti che l'HAL secondario le implementazioni soddisfano tutti i requisiti impostati dall'interfaccia Sensori HAL.

Per eseguire solo i test VTS dei sensori quando VTS è configurato su una macchina host, esegui questi 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 modo dinamico nel test delle unità e non vengono caricate in modo dinamico. Quando crei un nuovo sub-HAL, questi test dovrebbero servire da guida su come aggiungere test delle unità che verifica che il nuovo sub-HAL 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 sono 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 verificare il funzionamento del codice Multi-HAL completo di altri sub-HAL caricati nel sistema e di sottolineare vari aspetti Sensori: codice Multi-HAL.

Sono disponibili due falsi sub-HAL all'indirizzo hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/

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 falsi HAL secondari al dispositivo:

$ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests/
mma
adb push \
  $ANDROID_BUILD_TOP/out/target/product/&#x3C;device&#x3E;/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/&#x3C;device&#x3E;/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/&#x3C;device&#x3E;/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 all'indirizzo /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 il dell'output di debug dell'HAL per i 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 saranno quindi al terminale. Di seguito è riportato un esempio dell'output comando per Oggetto HalProxy e sub-HAL 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ù), Ciò indica che ci sono molti eventi in attesa di essere scritti sui sensori il modello di machine learning. Questo indica che il servizio dei sensori è in un deadlock o si è arrestato in modo anomalo. non elabora gli eventi dei sensori o che un gran numero di eventi ha pubblicato di recente da un sub-HAL.

Se il conteggio dei rif wakelock è maggiore di 0, significa che HalProxy ha ha acquisito un wakelock. Questo valore deve essere superiore a 0 solo se un ScopedWakelock viene tenuto intenzionalmente o se gli eventi di sveglia sono stati inviati a HalProxy e non sono stati elaborati dal framework dei sensori.

Il descrittore del file passato al metodo di debug di HalProxy viene trasmesso a ogni dell'HAL, quindi gli sviluppatori devono implementare il metodo di debug nell'ambito ISensorsSubHal.