La figura seguente rappresenta lo stack di sensori Android. Ciascun componente comunica solo con i componenti direttamente sopra e sotto di esso, sebbene alcuni sensori possano bypassare l'hub del sensore quando è presente. Il controllo fluisce dalle applicazioni ai sensori e i dati fluiscono dai sensori alle applicazioni.
Figura 1. Livelli dello stack di sensori Android e rispettivi proprietari
SDK
Le applicazioni accedono ai sensori tramite l' API Sensors SDK (Software Development Kit) . L'SDK contiene funzioni per elencare i sensori disponibili e per registrarsi su un sensore.
Quando si registra su un sensore, l'applicazione specifica la frequenza di campionamento preferita e i requisiti di latenza.
- Ad esempio, un'applicazione potrebbe registrarsi sull'accelerometro predefinito, richiedendo eventi a 100 Hz e consentendo la segnalazione degli eventi con una latenza di 1 secondo.
- L'applicazione riceverà eventi dall'accelerometro ad una frequenza di almeno 100 Hz ed eventualmente ritardati fino a 1 secondo.
Consulta la documentazione per gli sviluppatori per ulteriori informazioni sull'SDK.
Struttura
Il framework ha il compito di collegare le varie applicazioni all'HAL . L'HAL stesso è a client singolo. Senza questo multiplexing a livello di framework, solo una singola applicazione potrebbe accedere a ciascun sensore in un dato momento.
- Quando una prima applicazione si registra su un sensore, il framework invia una richiesta all'HAL per attivare il sensore.
- Quando ulteriori applicazioni vengono registrate sullo stesso sensore, il framework prende in considerazione i requisiti di ciascuna applicazione e invia i parametri richiesti aggiornati all'HAL.
- La frequenza di campionamento sarà la massima tra le frequenze di campionamento richieste, il che significa che alcune applicazioni riceveranno eventi con una frequenza superiore a quella richiesta.
- La latenza massima di reporting sarà quella minima tra quelle richieste. Se un'applicazione richiede un sensore con una latenza di reporting massima pari a 0, tutte le applicazioni riceveranno gli eventi da questo sensore in modalità continua anche se alcune hanno richiesto il sensore con una latenza di reporting massima diversa da zero. Vedi Batch per maggiori dettagli.
- Quando l'ultima applicazione registrata su un sensore annulla la registrazione, il framework invia una richiesta all'HAL per disattivare il sensore in modo che l'energia non venga consumata inutilmente.
Impatto del multiplexing
Questa necessità di uno strato multiplexing nel framework spiega alcune decisioni di progettazione.
- Quando un'applicazione richiede una frequenza di campionamento specifica, non vi è alcuna garanzia che gli eventi non arrivino a una velocità maggiore. Se un'altra applicazione ha richiesto lo stesso sensore a una velocità maggiore, anche la prima applicazione lo riceverà alla velocità maggiore.
- La stessa mancanza di garanzia si applica alla latenza massima di reporting richiesta: le applicazioni potrebbero ricevere eventi con una latenza molto inferiore a quella richiesta.
- Oltre alla frequenza di campionamento e alla latenza massima di reporting, le applicazioni non possono configurare i parametri del sensore.
- Ad esempio, immagina un sensore fisico che possa funzionare sia in modalità “alta precisione” che “bassa potenza”.
- Solo una di queste due modalità può essere utilizzata su un dispositivo Android, perché altrimenti un'applicazione potrebbe richiedere la modalità ad alta precisione e un'altra la modalità a basso consumo; non ci sarebbe modo per il framework di soddisfare entrambe le applicazioni. Il framework deve essere sempre in grado di soddisfare tutti i suoi clienti, quindi questa non è un'opzione.
- Non esiste alcun meccanismo per inviare i dati dalle applicazioni ai sensori o ai loro driver. Ciò garantisce che un'applicazione non possa modificare il comportamento dei sensori, interrompendo altre applicazioni.
Fusione dei sensori
Il framework Android fornisce un'implementazione predefinita per alcuni sensori compositi. Quando su un dispositivo sono presenti un giroscopio , un accelerometro e un magnetometro , ma non sono presenti sensori di vettore di rotazione , gravità e accelerazione lineare , il framework implementa tali sensori in modo che le applicazioni possano ancora utilizzarli.
L'implementazione predefinita non ha accesso a tutti i dati a cui hanno accesso altre implementazioni e deve essere eseguita sul SoC, quindi non è precisa né efficiente dal punto di vista energetico come possono essere altre implementazioni. Per quanto possibile, i produttori di dispositivi dovrebbero definire i propri sensori fusi (vettore di rotazione, gravità e accelerazione lineare, nonché sensori compositi più recenti come il vettore di rotazione del gioco ) anziché fare affidamento su questa implementazione predefinita. I produttori di dispositivi possono anche richiedere ai fornitori di chip sensore di fornire loro un'implementazione.
L'implementazione predefinita della fusione dei sensori non viene mantenuta e potrebbe causare il mancato funzionamento del CTS dei dispositivi che fanno affidamento su di essa.
Sotto il cappuccio
Questa sezione viene fornita come informazioni di base per coloro che gestiscono il codice del framework Android Open Source Project (AOSP). Non è rilevante per i produttori di hardware.
JNI
Il framework utilizza una Java Native Interface (JNI) associata ad android.hardware e situata nella directory frameworks/base/core/jni/ . Questo codice richiama il codice nativo di livello inferiore per ottenere l'accesso all'hardware del sensore.
Quadro nativo
Il framework nativo è definito in frameworks/native/ e fornisce un equivalente nativo al pacchetto android.hardware . Il framework nativo chiama i proxy IPC di Binder per ottenere l'accesso a servizi specifici del sensore.
Legante IPC
I proxy IPC Binder facilitano la comunicazione oltre i confini del processo.
HAL
L'API Sensors Hardware Abstraction Layer (HAL) è l'interfaccia tra i driver hardware e il framework Android. È costituito da un'interfaccia HAL sensors.h e da un'implementazione HAL a cui ci riferiamo come sensors.cpp.
L'interfaccia è definita dai contributori Android e AOSP e l'implementazione è fornita dal produttore del dispositivo.
L'interfaccia HAL del sensore si trova in hardware/libhardware/include/hardware . Vedi sensori.h per ulteriori dettagli.
Ciclo di rilascio
L'implementazione HAL specifica quale versione dell'interfaccia HAL implementa impostando your_poll_device.common.version . Le versioni dell'interfaccia HAL esistenti sono definite in sensori.h e la funzionalità è legata a tali versioni.
Il framework Android attualmente supporta le versioni 1.0 e 1.3, ma presto la 1.0 non sarà più supportata. Questa documentazione descrive il comportamento della versione 1.3, alla quale tutti i dispositivi dovrebbero aggiornarsi. Per dettagli su come eseguire l'aggiornamento alla versione 1.3, vedere deprecazione della versione HAL .
Driver del kernel
I driver dei sensori interagiscono con i dispositivi fisici. In alcuni casi, l'implementazione dell'HAL e i driver sono la stessa entità software. In altri casi, l'integratore hardware richiede ai produttori di chip sensore di fornire i driver, ma sono loro a scrivere l'implementazione HAL.
In tutti i casi, l'implementazione dell'HAL e i driver del kernel sono responsabilità dei produttori dell'hardware e Android non fornisce approcci preferenziali per scriverli.
Mozzo del sensore
Lo stack di sensori di un dispositivo può facoltativamente includere un hub di sensori, utile per eseguire alcuni calcoli di basso livello a basso consumo mentre il SoC può essere in modalità di sospensione. Ad esempio, su questi chip è possibile eseguire il conteggio dei passi o la fusione dei sensori. È anche un buon posto per implementare il batching dei sensori, aggiungendo FIFO hardware per gli eventi del sensore. Vedi Raggruppamento per ulteriori informazioni.
Nota: per sviluppare nuove funzionalità ContextHub che utilizzano nuovi sensori o LED, puoi anche utilizzare un Neonkey SensorHub collegato a una scheda di sviluppo Hikey o Hikey960.
Il modo in cui viene materializzato l'hub del sensore dipende dall'architettura. A volte è un chip separato e talvolta è incluso nello stesso chip del SoC. Caratteristiche importanti dell'hub del sensore sono che dovrebbe contenere memoria sufficiente per il batching e consumare pochissima energia per consentire l'implementazione dei sensori Android a basso consumo. Alcuni hub di sensori contengono un microcontrollore per calcoli generici e acceleratori hardware per consentire calcoli a bassissima potenza per sensori a basso consumo.
Android non specifica l'architettura dell'hub dei sensori e il modo in cui comunica con i sensori e il SoC (bus I2C, bus SPI, ...), ma dovrebbe mirare a ridurre al minimo il consumo energetico complessivo.
Un'opzione che sembra avere un impatto significativo sulla semplicità di implementazione è avere due linee di interruzione che vanno dall'hub dei sensori al SoC: una per gli interrupt di riattivazione (per i sensori di riattivazione) e l'altra per gli interrupt di non riattivazione (per sensori non di riattivazione).
Sensori
Quelli sono i chip MEM fisici che effettuano le misurazioni. In molti casi, sullo stesso chip sono presenti più sensori fisici. Ad esempio, alcuni chip includono un accelerometro, un giroscopio e un magnetometro. (Tali chip sono spesso chiamati chip a 9 assi, poiché ciascun sensore fornisce dati su 3 assi.)
Alcuni di questi chip contengono anche una logica per eseguire calcoli usuali come il rilevamento del movimento, il rilevamento dei passi e la fusione dei sensori a 9 assi.
Sebbene i requisiti e le raccomandazioni di potenza e precisione del CDD siano rivolti al sensore Android e non ai sensori fisici, tali requisiti influiscono sulla scelta dei sensori fisici. Ad esempio, il requisito di precisione sul vettore di rotazione del gioco ha implicazioni sulla precisione richiesta per il giroscopio fisico. Spetta al produttore del dispositivo ricavare i requisiti per i sensori fisici.