L'HAL (Sensors Hardware Abstraction Layer) è l'interfaccia tra Framework dei sensori Android e i sensori di un dispositivo, ad esempio un accelerometro o un giroscopio. L'HAL dei sensori definisce le funzioni che devono essere implementate per consentire al framework di controllare i sensori.
Sensors AIDL HAL è disponibile su Android 13 e per i dispositivi nuovi e di cui è stato eseguito l'upgrade. L'HAL Sensors AIDL, basato su Sensori HAL 2.1, utilizza la classe interfaccia AIDL HAL e espone il tracker della testa e i tipi di sensori IMU ad asse limitato.
Interfaccia AIDL HAL
La fonte principale di documentazione per l'HAL per Sensors AIDL è all'interno dell'HAL definizione in hardware/interfaces/sensors/aidl/android/hardware/sensors/ISensors.aidl.
Implementazione dei sensori AIDL HAL
Per implementare i sensori AIDL HAL, un oggetto deve estendere ISensors
e implementare tutte le funzioni definite
hardware/interfaces/sensors/aidl/android/hardware/sensors/ISensors.aidl.
Inizializzare l'HAL
L'HAL dei sensori deve essere inizializzato dal framework dei sensori Android prima
è possibile utilizzare. Il framework chiama la funzione initialize() per fornire tre
all'HAL per i sensori: due descrittori FMQ e un puntatore a un
Oggetto ISensorsCallback.
L'HAL utilizza il primo descrittore per creare l'FMQ dell'evento utilizzato per scrivere il sensore
eventi al framework. L'HAL utilizza il secondo descrittore per creare la Wake
Blocca FMQ utilizzato per la sincronizzazione quando l'HAL rilascia il wakelock per WAKE_UP
degli eventi dei sensori. L'HAL deve salvare un puntatore nell'oggetto ISensorsCallback in modo che
che qualsiasi funzione di callback necessaria possa essere richiamata.
La funzione initialize() deve essere la prima funzione chiamata durante l'inizializzazione
Sensors HAL.
Esposizione dei sensori disponibili
Per visualizzare un elenco di tutti i sensori statici disponibili nel dispositivo, utilizza l'app
Funzione getSensorsList(). Questa funzione restituisce un elenco di sensori, ciascuno
identificato in modo univoco dal suo handle. La maniglia di un determinato sensore non deve cambiare
quando viene riavviato il processo che ospita l'HAL per i sensori. Gli handle potrebbero cambiare
tra dispositivi e server di sistema.
Se più sensori condividono lo stesso tipo di sensore e proprietà di riattivazione, la
il primo sensore dell'elenco è chiamato sensore predefinito e viene restituito
app che utilizzano getDefaultSensor(int sensorType, bool wakeUp)
personalizzata.
Stabilità dei sensori
Dopo il riavvio di Sensors HAL, se i dati restituiti da getSensorsList()
indica una variazione significativa rispetto all'elenco dei sensori recuperato prima del
riavvio, il framework attiva un riavvio
Runtime Android. Le modifiche significative all'elenco dei sensori includono i casi in cui
con un determinato handle manca o ha cambiato attributi, oppure i nuovi
vengono introdotti i sensori. Il riavvio del runtime di Android è invasivo
all'utente, è necessaria perché il framework Android non è più in grado di soddisfare
L'API di Android contrae il fatto che i sensori statici (non dinamici) non subiscano variazioni durante
per tutta la durata di un'app. Ciò potrebbe anche impedire il ripristino del framework
richieste di sensori attive effettuate dalle app. Pertanto, ai fornitori di soluzioni HAL si consiglia
evitare modifiche evitabili all'elenco dei sensori.
Per garantire handle stabili dei sensori, l'HAL deve mappare in modo deterministico una sensore fisico nel dispositivo alla maniglia. Anche se non esiste un'implementazione specifica è richiesto dall'interfaccia Sensors HAL, gli sviluppatori hanno disponibili per soddisfare questo requisito.
Ad esempio, l'elenco dei sensori può essere ordinato utilizzando una combinazione
come il fornitore, il modello e il tipo di sensore. Un'altra opzione fa affidamento
sul fatto che l'insieme di sensori statici del dispositivo è fisso nell'hardware, quindi
L'HAL deve sapere quando tutti i sensori previsti hanno completato l'inizializzazione prima
di ritorno da getSensorsList(). Questo elenco di
i sensori previsti possono essere compilati nel file binario dell'HAL o
di configurazione nel file system e l'ordine di apparizione può essere utilizzato
per ricavare handle stabili. Anche se la soluzione migliore dipende dalla configurazione
dettagli di implementazione specifici, il requisito chiave è che il sensore
non cambiano tra i riavvii di HAL.
Configura i sensori
Prima che venga attivato un sensore, questo deve essere configurato con un
periodo e massima latenza dei report utilizzando la funzione batch().
Un sensore deve poter essere riconfigurato in qualsiasi momento utilizzando batch() senza il
dei dati dei sensori.
Periodo di campionamento
Il periodo di campionamento ha un significato diverso in base al tipo di sensore configurazione in corso:
- Continuo: gli eventi del sensore vengono generati a frequenza continua.
- In caso di modifica: gli eventi vengono generati non più rapidamente del periodo di campionamento e possono essere generate a una velocità inferiore rispetto al periodo di campionamento se il valore misurato non cambia.
- One-shot: il periodo di campionamento viene ignorato.
- Speciale: per ulteriori dettagli, vedi Tipi di sensori.
Per scoprire l'interazione tra un periodo di campionamento e la consulta Modalità di reporting.
Latenza massima dei report
La latenza massima dei report imposta il tempo massimo in nanosecondi eventi possono essere ritardati e memorizzati nel file FIFO dell'hardware prima di essere scritti l'FMQ dell'evento tramite l'HAL mentre il SoC è attivo.
Il valore zero indica che gli eventi devono essere segnalati non appena vengono misurato, saltando del tutto il FIFO o svuotando il FIFO non appena un evento del sensore è presente nel FIFO.
Ad esempio, un accelerometro attivato a 50 Hz con un valore di reporting massimo latenza su zero attivazioni si interrompono 50 volte al secondo quando il SoC è attivo.
Quando la latenza massima dei report è maggiore di zero, gli eventi dei sensori non devono essere segnalati non appena vengono rilevati. Gli eventi possono essere archiviati nell'hardware FIFO e riportati in batch, purché non vengano ritardato oltre la latenza massima dei report. Tutti gli eventi a partire dalla batch precedenti vengono registrati e restituiti contemporaneamente. Questo riduce il numero interrompe l'invio al SoC e lo consente di passare alla modalità di risparmio energetico mentre il sensore acquisisce e raggruppa i dati.
A ogni evento è associato un timestamp. Rimandare il momento in cui un che questo evento viene segnalato non deve influire sul timestamp dell'evento. Il timestamp deve essere accurati e corrispondono al momento in cui si è verificato fisicamente l'evento, non l'ora in cui è stato segnalato.
Per ulteriori informazioni e requisiti relativi alla segnalazione degli eventi dei sensori con una latenza di reporting massima diversa da zero, consulta Batching.
Attiva i sensori
Il framework attiva e disattiva i sensori utilizzando la funzione activate().
Prima di attivare un sensore, la struttura deve configurare il sensore
utilizzando batch().
Dopo la disattivazione di un sensore, gli eventi aggiuntivi da quest'ultimo non devono devono essere scritte nell'FMQ dell'evento.
Fai il flush dei sensori
Se un sensore è configurato per raggruppare i dati dei sensori, la struttura può forzare
uno scarico immediato degli eventi batch dei sensori chiamando il numero flush(). Questo causa
gli eventi in batch dei sensori per l'handle del sensore specificato
scritto nell'FMQ dell'evento. L'HAL dei sensori deve aggiungere un evento di svuotamento completo
alla fine degli eventi del sensore scritti a seguito di una chiamata
flush().
Lo svuotamento avviene in modo asincrono (ossia, questa funzione deve restituire immediatamente). Se l'implementazione utilizza un singolo FIFO per diversi sensori, quel FIFO viene e l'evento svuotamento completo viene aggiunto solo per il sensore specificato.
Se il sensore specificato non ha il segnale FIFO (non è possibile il buffering) o se il FIFO è
vuoto al momento della chiamata, flush() deve comunque riuscire e inviare uno svuotamento
completo dell'evento per quel sensore. Vale per tutti i sensori, eccetto one-shot
i sensori.
Se flush() viene richiesto per un sensore one-shot, flush() deve restituire
BAD_VALUE e non generare un evento di svuotamento completo.
Scrivere gli eventi dei sensori in FMQ
L'FMQ dell'evento viene utilizzato dall'HAL dei sensori per inviare gli eventi dei sensori ad Android nella struttura dei sensori.
L'FMQ evento è un FMQ sincronizzato, il che significa che ogni tentativo di scrivere a FMQ rispetto allo spazio disponibile consente di generare e scrivere. In tal caso, l'HAL deve determinare se scrivere il set corrente di eventi come due gruppi più piccoli di eventi o per scrivere tutti gli eventi quando c'è abbastanza spazio disponibile.
Dopo che l'HAL dei sensori ha scritto il numero desiderato di eventi del sensore nella
Event FMQ, l'HAL dei sensori deve notificare al framework che gli eventi sono pronti
scrivere il bit EventQueueFlagBits::READ_AND_PROCESS nell'FMQ dell'evento
Funzione EventFlag::wake. Il flag EventFlag può essere creato dall'FMQ dell'evento
utilizzando EventFlag::createEventFlag e l'elemento getEventFlagWord() dell'FMQ dell'evento
personalizzata.
L'HAL per i sensori AIDL supporta sia write sia writeBlocking nell'FMQ dell'evento.
L'implementazione predefinita fornisce un riferimento per l'utilizzo di write. Se
Viene utilizzata la funzione writeBlocking, il flag readNotification deve essere impostato su
EventQueueFlagBits::EVENTS_READ, che viene impostato dal framework quando legge
eventi dall'FMQ evento. Il flag di notifica di scrittura deve essere impostato su
EventQueueFlagBits::READ_AND_PROCESS, che notifica al framework che gli eventi
siano state scritte all'FMQ dell'evento.
Eventi WAKE_UP
Gli eventi WAKE_UP sono eventi dei sensori che fanno sì che il processore delle applicazioni (AP)
per svegliarti e gestire immediatamente l'evento. Ogni volta che viene scritto un evento WAKE_UP
al FMQ evento, l'HAL dei sensori deve proteggere un wakelock per garantire che
rimane attivo finché il framework non è in grado di gestire l'evento. Dopo aver ricevuto un
WAKE_UP, il framework protegge il proprio wakelock, consentendo
Sensori HAL per sbloccare il wakelock. Per eseguire la sincronizzazione quando l'HAL per i sensori
rilascia il wakelock, utilizza il Wake Lock FMQ.
L'HAL dei sensori deve leggere il valore FMQ Wake Lock per determinare il numero di WAKE_UP.
degli eventi gestiti dal framework. L'HAL deve rilasciare solo il suo wakelock
per gli eventi WAKE_UP se il numero totale di eventi WAKE_UP non gestiti è zero.
Dopo aver gestito gli eventi dei sensori, il framework conteggia il numero di eventi
contrassegnato come WAKE_UP eventi e questo numero viene riscritto nel file FMQ Wake Lock.
Il framework imposta la scrittura WakeLockQueueFlagBits::DATA_WRITTEN
nella notifica Wake Lock FMQ ogni volta che scrive dati nell'FMQ Wake Lock.
Sensori dinamici
I sensori dinamici sono sensori che non fanno fisicamente parte del dispositivo, ma possono come input per il dispositivo, ad esempio un gamepad con un accelerometro.
Quando è collegato un sensore dinamico, la funzione onDynamicSensorConnected in
ISensorsCallback deve essere chiamato dall'HAL per i sensori. In questo modo viene comunicato
quadro del nuovo sensore dinamico e consente di controllarlo
attraverso il framework e fare in modo che gli eventi del sensore vengano fruiti dai clienti.
Analogamente, quando un sensore dinamico è scollegato,
La funzione onDynamicSensorDisconnected in ISensorsCallback deve essere chiamata così
secondo cui il framework può rimuovere qualsiasi sensore non più disponibile.
Canale diretto
Il canale diretto è un metodo operativo in cui gli eventi dei sensori vengono scritti
anziché l'FMQ dell'evento che bypassa i sensori Android
. Un client che registra un canale diretto deve leggere gli eventi del sensore
direttamente dalla memoria utilizzata per creare il canale diretto
ricevono gli eventi dei sensori attraverso il framework. configDirectReport()
è simile a batch() per il normale funzionamento e configura la funzione
Segnala canale.
Le funzioni registerDirectChannel() e unregisterDirectChannel() creano
o distruggere un nuovo canale diretto.
Modalità operative
La funzione setOperationMode() consente al framework di configurare un sensore
in modo che il framework possa inserire i dati del sensore. Questo è utile per
i test, in particolare per gli algoritmi
sotto il framework.
La funzione injectSensorData() viene solitamente utilizzata per eseguire il push delle operazioni
nell'HAL dei sensori. La funzione può essere utilizzata anche per iniettare il sensore
in un sensore specifico.
Convalida
Per convalidare l'implementazione dell'HAL per sensori, esegui i sensori CTS e VTS test.
Test CTS
I test CTS dei sensori sono disponibili sia nei test CTS automatici sia nello strumento di verifica CTS manuale dell'app.
I test automatici si trovano cts/tests/sensor/src/android/hardware/cts. Questi test verificano la funzionalità standard dei sensori, ad esempio l'attivazione sensori, batch e velocità di eventi dei sensori.
I test di CTS Verifier si trovano in cts/apps/CtsVerifier/src/com/android/cts/verifier/sensors. Questi test richiedono l'intervento manuale dell'operatore di test e garantiscono che i sensori riportino valori accurati.
Superare i test CTS è fondamentale per garantire che il dispositivo sottoposto a test soddisfi tutti i requisiti CDD.
Test VTS
I test VTS per i sensori AIDL HAL si trovano in
hardware/interfaces/sensors/aidl/vts/.
Questi test assicurano che l'HAL dei sensori sia implementato correttamente e che tutti
i requisiti di ISensors.aidl e ISensorsCallback.aidl siano soddisfatti.
Inizializzare l'HAL
La funzione initialize() deve essere supportata per stabilire gli FMQ tra
e HAL.
Esposizione dei sensori disponibili
Nell'HAL Sensors AIDL, la funzione getSensorsList() deve restituire lo stesso valore
durante l'avvio di un singolo dispositivo, anche tra i diversi riavvii dell'HAL. Un nuovo requisito
della funzione getSensorsList() è che deve restituire lo stesso valore durante
l'avvio di un singolo dispositivo, anche tra i diversi sensori di riavvio dell'HAL. Ciò consente
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.
Scrivere gli eventi dei sensori in FMQ
Invece di attendere la chiamata di poll(), nei sensori AIDL HAL,
L'HAL deve scrivere in modo proattivo gli eventi dei sensori nell'FMQ evento ogni volta che eventi dei sensori
sono disponibili. L'HAL è anche responsabile di scrivere i bit corretti nel
EventFlag per consentire la lettura di un file FMQ all'interno del framework.
Eventi WAKE_UP
Nella versione Sensori dell'HAL 1.0, l'HAL è riuscito a rilasciare il wakelock per qualsiasi WAKE_UP
evento in qualsiasi chiamata successiva a poll() dopo la pubblicazione di un WAKE_UP in
poll() perché indica che il framework ha elaborato tutti i sensori
eventi e aveva ottenuto un wakelock, se necessario. Poiché, secondo i sensori AIDL
HAL, l'HAL non riceve più notifiche quando il framework ha elaborato gli eventi.
scritto FMQ, il file FMQ Wake Lock consente al framework di comunicare
HAL quando ha gestito WAKE_UP eventi.
Nell'HAL dei sensori AIDL, il wakelock protetto dai sensori HAL per WAKE_UP
gli eventi devono iniziare con SensorsHAL_WAKEUP.
Sensori dinamici
I sensori dinamici sono stati restituiti utilizzando la funzione poll() nella HAL 1.0 dei sensori.
L'HAL di Sensors AIDL richiede che onDynamicSensorsConnected e
onDynamicSensorsDisconnected in ISensorsCallback verrà chiamato ogni volta che una campagna dinamica
le connessioni dei sensori cambiano. Questi callback sono disponibili nell'ambito
Puntatore ISensorsCallback fornito tramite la funzione initialize().
Modalità operative
La modalità DATA_INJECTION per i sensori WAKE_UP deve essere supportata.
Supporto di più HAL
Sensori AIDL HAL supporta l'HAL multiplo utilizzando il Framework Multi-HAL dei sensori. Per dettagli di implementazione, consulta Trasferimento dai sensori HAL 2.1.