La figura seguente mostra lo stack di sensori Android. Ogni componente comunica solo con i componenti direttamente sopra e sotto, anche se alcuni sensori possono bypassare l'hub dei sensori quando è presente. Controlla i flussi dalle applicazioni ai sensori e i flussi di dati dai sensori alle applicazioni.
Figura 1. Livelli dello stack di sensori Android e relativi 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 a un sensore.
Quando si registra a un sensore, l'applicazione specifica la frequenza di campionamento preferita e i requisiti di latenza.
- Ad esempio, un'applicazione potrebbe registrarsi all'accelerometro predefinito, richiedendo eventi a 100 Hz e consentendo la segnalazione di eventi con una latenza di 1 secondo.
- L'applicazione riceverà eventi dall'accelerometro a una frequenza di almeno 100 Hz e con un possibile ritardo fino a 1 secondo.
Per saperne di più sull'SDK, consulta la documentazione per gli sviluppatori.
Framework
Il framework è responsabile del collegamento delle varie applicazioni all'HAL. L'HAL è a singolo cliente. Senza questo multiplexing a livello di framework, solo una singola applicazione potrebbe accedere a ogni sensore in un determinato momento.
- Quando una prima app si registra a un sensore, il framework invia una richiesta all'HAL per attivare il sensore.
- Quando altre app si registrano allo stesso sensore, il framework tiene
conto dei requisiti di ogni app e invia i parametri richiesti aggiornati
all'HAL.
- La frequenza di campionamento sarà il massimo delle frequenze di campionamento richieste, il che significa che alcune applicazioni riceveranno eventi a una frequenza superiore a quella richiesta.
- La latenza massima dei report sarà il valore minimo di quelli richiesti. 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. Per ulteriori dettagli, consulta la sezione Batching.
- Quando l'ultima applicazione registrata a un sensore viene annullata, i framework inviano una richiesta all'HAL per disattivare il sensore in modo che l'energia non venga consumata inutilmente.
Impatto del multiplexing
Questa necessità di un livello di 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 li 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 dei report, le applicazioni non possono
configurare i parametri del sensore.
- Ad esempio, immagina un sensore fisico che può funzionare sia in modalità "alta precisione" che in modalità "basso consumo energetico".
- Su un dispositivo Android può essere utilizzata solo una di queste due modalità, perché altrimenti un'applicazione potrebbe richiedere la modalità ad alta precisione e un'altra una modalità a basso consumo energetico; il framework non potrebbe soddisfare entrambe le applicazioni. Il framework deve sempre essere in grado di soddisfare tutti i suoi clienti, quindi questa non è un'opzione.
- Non esiste alcun meccanismo per inviare dati dalle applicazioni ai sensori o ai relativi driver. In questo modo, un'applicazione non può modificare il comportamento dei sensori, interrompendo il funzionamento di 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 questi sensori in modo che le applicazioni possano comunque utilizzarli.
L'implementazione predefinita non ha accesso a tutti i dati a cui hanno accesso altre implementazioni e deve essere eseguita sul SoC, pertanto non è precisa né efficiente dal punto di vista energetico come altre implementazioni. Per quanto possibile, i produttori di dispositivi devono definire i propri sensori combinati (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 un'implementazione.
L'implementazione predefinita della fusione dei sensori non viene mantenuta e potrebbe causare il mancato superamento del test CTS da parte dei dispositivi che si basano su di essa.
Roba da smanettoni
Questa sezione fornisce informazioni di base per chi gestisce il codice del framework Android Open Source Project (AOSP). Non è pertinente per i produttori di hardware.
JNI
Il framework utilizza un'interfaccia Java Native Interface (JNI) associata ad android.hardware e si trova nella directory frameworks/base/core/jni/. Questo codice chiama il
codice nativo di livello inferiore per ottenere l'accesso all'hardware del sensore.
Framework nativo
Il framework nativo è definito in frameworks/native/ e fornisce un equivalente nativo
al pacchetto android.hardware. Il framework nativo chiama i proxy IPC Binder per ottenere l'accesso a servizi specifici per i sensori.
Binder IPC
I proxy IPC Binder facilitano la comunicazione oltre i limiti del processo.
HAL
L'API Sensors Hardware Abstraction Layer (HAL) è l'interfaccia tra i driver hardware e il framework Android. È composto da un'interfaccia HAL sensors.h e da un'implementazione HAL che chiamiamo sensors.cpp.
L'interfaccia è definita da Android e dai collaboratori AOSP, mentre l'implementazione è fornita dal produttore del dispositivo.
L'interfaccia HAL del sensore si trova in hardware/libhardware/include/hardware.
Per ulteriori dettagli, consulta sensors.h.
Ciclo di rilascio
L'implementazione HAL specifica la versione dell'interfaccia HAL che implementa impostando your_poll_device.common.version. Le versioni dell'interfaccia HAL esistenti sono definite in sensors.h e la funzionalità è associata a queste versioni.
Il framework Android attualmente supporta le versioni 1.0 e 1.3, ma la versione 1.0 non sarà più supportata a breve. Questa documentazione descrive il comportamento della versione 1.3, a cui tutti i dispositivi devono eseguire l'upgrade. Per informazioni dettagliate su come eseguire l'upgrade alla versione 1.3, vedi Ritiro della versione HAL.
Driver del kernel
I driver dei sensori interagiscono con i dispositivi fisici. In alcuni casi, l'implementazione 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 è lui a scrivere l'implementazione HAL.
In tutti i casi, l'implementazione dell'HAL e i driver del kernel sono responsabilità dei produttori di hardware e Android non fornisce approcci preferiti per scriverli.
Hub sensori
Lo stack di sensori di un dispositivo può includere facoltativamente un hub sensori, utile per eseguire alcuni calcoli di basso livello a basso consumo energetico mentre il SoC può essere in modalità sospensione. Ad esempio, il conteggio dei passi o la fusione dei sensori possono essere eseguiti su questi chip. È anche un buon posto per implementare il batching dei sensori, aggiungendo FIFO hardware per gli eventi dei sensori. Per saperne di più, consulta la sezione Raggruppamento.
Nota:per sviluppare nuove funzionalità di ContextHub che utilizzano nuovi sensori o LED, puoi anche utilizzare un Neonkey SensorHub collegato a una scheda di sviluppo Hikey o Hikey960.
La modalità di materializzazione dell'hub sensore dipende dall'architettura. A volte è un chip separato, altre volte è incluso nello stesso chip del SoC. Le caratteristiche importanti dell'hub dei sensori sono che deve contenere memoria sufficiente per il batching e consumare pochissima energia per consentire l'implementazione dei sensori Android a basso consumo energetico. Alcuni hub sensori contengono un microcontrollore per il calcolo generico e acceleratori hardware per consentire il calcolo a bassissimo consumo per sensori a basso consumo.
L'architettura dell'hub sensori e il modo in cui comunica con i sensori e il SoC (bus I2C, bus SPI, …) non sono specificati da Android, ma dovrebbero 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 le interruzioni di riattivazione (per i sensori di riattivazione) e l'altra per le interruzioni non di riattivazione (per i sensori non di riattivazione).
Sensori
Questi sono i chip MEMS fisici che eseguono le misurazioni. In molti casi, più sensori fisici sono presenti sullo stesso chip. Ad esempio, alcuni chip includono un accelerometro, un giroscopio e un magnetometro. (Questi chip vengono spesso chiamati chip a 9 assi, poiché ogni sensore fornisce dati su 3 assi.)
Alcuni di questi chip contengono anche una logica per eseguire i calcoli usuali, come il rilevamento del movimento, il rilevamento dei passi e la fusione dei sensori a 9 assi.
Sebbene i requisiti e i consigli relativi a potenza e precisione della CDD siano rivolti al sensore Android e non ai sensori fisici, questi requisiti influiscono sulla scelta dei sensori fisici. Ad esempio, il requisito di precisione del vettore di rotazione del gioco ha implicazioni sulla precisione richiesta per il giroscopio fisico. Spetta al produttore del dispositivo derivare i requisiti per i sensori fisici.