Sensori AIDL HAL

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.