La figura seguente mostra la pila di sensori Android. Ogni componente comunicate solo con i componenti direttamente sopra e sotto di esso, anche se alcuni sensori possono bypassare l'hub se presente. I controlli passano dalle applicazioni ai sensori e i dati dai sensori alle applicazioni.
Figura 1. Livelli della pila di sensori Android e rispettivi proprietari
SDK
Le applicazioni accedono ai sensori tramite l'API SDK (Software Development Kit) per i sensori. 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, richiedere eventi a 100 Hz e consentire la registrazione degli eventi con una latenza di 1 secondo.
- L'applicazione riceverà gli eventi dall'accelerometro a una frequenza di almeno 100 Hz e con un ritardo massimo di 1 secondo.
Per ulteriori informazioni sull'SDK, consulta la documentazione per gli sviluppatori.
Framework
Il framework è responsabile del collegamento delle varie applicazioni all'HAL. L'HAL stesso è monocliente. Senza questo multiplexing a livello di framework, solo una singola applicazione potrebbe accedere a ciascun sensore in un determinato momento.
- Quando una prima applicazione si registra a un sensore, il framework invia una richiesta all'HAL per attivare il sensore.
- Quando altre applicazioni si registrano allo stesso sensore, il framework prende in considerazione i requisiti di ciascuna applicazione e invia all'HAL i parametri richiesti aggiornati.
- La frequenza di campionamento sarà la massima delle frequenze di campionamento richieste, il che significa che alcune applicazioni riceveranno gli eventi a una frequenza superiore a quella richiesta.
- La latenza massima dei report sarà la più bassa tra quelle richieste. Se un'applicazione richiede un sensore con una latenza massima di generazione dei report 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 massima di generazione dei report diversa da 0. Per ulteriori dettagli, consulta la sezione Raggruppamento.
- Quando l'ultima applicazione registrata su un sensore viene registrata, i framework inviano una richiesta all'HAL per disattivare il sensore in modo che l'alimentazione 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 c'è alcuna garanzia che gli eventi non arrivino a una frequenza più elevata. Se un'altra applicazione ha richiesto lo stesso sensore a una frequenza più elevata, anche la prima applicazione lo riceverà alla stessa frequenza.
- La stessa mancanza di garanzia si applica alla latenza massima richiesta per i report: 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à di "alta precisione" sia in modalità di "basso consumo".
- Su un dispositivo Android può essere utilizzata una sola di queste due modalità, perché altrimenti un'applicazione potrebbe richiedere la modalità di alta precisione e un'altra una modalità a basso consumo; il framework non avrebbe modo di 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, causando il malfunzionamento di altre applicazioni.
Fusione di 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 li implementa 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 è così accurata né efficiente in termini di consumo energetico come possono essere 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 chiedere ai fornitori di chip per sensori di fornire un'implementazione.
L'implementazione predefinita della fusione dei sensori non viene mantenuta e potrebbe causare il fallimento della CTS dei dispositivi che si basano su questa funzionalità.
Roba da smanettoni
Questa sezione viene fornita come 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 nativa Java (JNI) associata ad android.hardware e situata 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 di Binder per ottenere l'accesso ai servizi specifici dei sensori.
Binder IPC
I proxy IPC di Binder facilitano la comunicazione oltre i confini dei processi.
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 collaboratori di Android e AOSP e 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à è legata a queste versioni.
Al momento il framework Android 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 deve essere eseguito l'upgrade di tutti i dispositivi. Per informazioni dettagliate su come eseguire l'upgrade alla versione 1.3, consulta Ritiro 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 dei sensori di fornire i driver, ma sono loro a scrivere l'implementazione dell'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 di sensori
Lo stack di sensori di un dispositivo può includere facoltativamente 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 punto di partenza per implementare il raggruppamento dei sensori, aggiungendo FIFO hardware per gli eventi del sensore. Per ulteriori informazioni, 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 di sensori dipende dall'architettura. A volte è un chip separato e a volte è incluso nello stesso chip dell'SoC. È importante che l'hub dei sensori contenga memoria sufficiente per l'aggregazione e consumi 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 bassissimo consumo per i sensori a basso consumo.
L'architettura dell'hub di sensori e il modo in cui comunica con i sensori e il SoC (bus I2C, bus SPI e così via) 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 del sensore al SoC: una per le interruzioni di risveglio (per i sensori di risveglio) e l'altra per le interruzioni non di risveglio (per i sensori non di risveglio).
Sensori
Si tratta dei chip MEMS fisici che effettuano le misurazioni. In molti casi, sullo stesso chip sono presenti diversi sensori fisici. Ad esempio, alcuni chip includono un accelerometro, un giroscopio e un magnetometro. Questi chip sono 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 dei movimenti, il rilevamento dei passi e la fusione dei sensori a 9 assi.
Sebbene i requisiti e i consigli relativi all'accuratezza e alla potenza del CDD abbiano come target il sensore Android e non i 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 ricavare i requisiti per i sensori fisici.