La figura seguente rappresenta l'insieme di sensori Android. Ogni componente comunica solo con i componenti direttamente sopra e sotto, sebbene i sensori possono bypassare l'hub dei sensori quando è presente. Flussi di controllo le applicazioni fino ai sensori e i dati passano dai sensori diverse applicazioni.
Figura 1. Livelli dell'elenco 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 la registrazione in un sensore.
Quando si registra a un sensore, l'applicazione specifica il campionamento preferito frequenza e i suoi requisiti di latenza.
- Ad esempio, un'applicazione potrebbe registrarsi sull'accelerometro predefinito, richiedendo eventi a 100 Hz e consentendo la segnalazione di eventi con un prompt una latenza di pochi millisecondi.
- L'applicazione riceverà gli eventi dall'accelerometro a una velocità pari a almeno 100 Hz ed eventualmente con ritardo fino a 1 secondo.
Per ulteriori informazioni sull'SDK, consulta la documentazione per gli sviluppatori.
Framework
Il framework è responsabile del collegamento delle diverse applicazioni all'HAL. L'HAL stesso è a client singolo. Senza che questo multiplexing avvenga a livello di framework, solo una singola applicazione poteva accedere a ciascun sensore in un determinato momento.
- Quando una prima applicazione si registra su un sensore, il framework invia una richiesta all'HAL per attivare il sensore.
- Quando applicazioni aggiuntive si registrano sullo stesso sensore, il framework prende
i requisiti di ogni applicazione e invia la richiesta
parametri all'HAL.
- La frequenza di campionamento è la massima tra le frequenze di campionamento richieste, il che significa le applicazioni riceveranno eventi con una frequenza maggiore di quella richiesto.
- La latenza massima dei report sarà quella minima di quelle richieste. Se un'applicazione richiede uno con una latenza di reporting massima pari a 0, tutte le applicazioni riceveranno eventi da questo sensore in modalità continua anche se alcuni hanno richiesto con una latenza massima dei report diversa da zero. Per ulteriori dettagli, consulta Raggruppamento in batch.
- Quando l'ultima applicazione registrata per un sensore annulla la registrazione, invia una richiesta all'HAL per disattivare il sensore in modo che l'alimentazione consumati inutilmente.
Impatto del multiplexing
La necessità di un livello di multiplexing nel framework spiega alcuni concetti prendono le loro decisioni.
- Quando un'applicazione richiede una frequenza di campionamento specifica, non c'è garantire che gli eventi non arrivino a una velocità maggiore. Se un'altra applicazione richiesto lo stesso sensore a una velocità più elevata, anche la prima applicazione riceverle rapidamente.
- La stessa mancanza di garanzia si applica alla latenza massima richiesta nei report: le applicazioni potrebbero ricevere eventi con una latenza minore di quella richiesta.
- Oltre alla frequenza di campionamento e alla massima latenza dei report, le applicazioni non possono
e configurare i parametri del sensore.
- Ad esempio, immagina un sensore fisico in grado di funzionare sia a precisione" e "a bassa potenza".
- Solo una di queste due modalità può essere usata su un dispositivo Android perché altrimenti un'applicazione potrebbe richiedere la modalità Alta precisione e un'altra una modalità a basso consumo; non c'è modo per il framework di soddisfare diverse applicazioni. Il framework deve essere sempre in grado di soddisfare tutti i clienti, non è possibile.
- Non esiste alcun meccanismo per inviare i dati dalle applicazioni ai sensori ai conducenti. Ciò garantisce che un'applicazione non possa modificare il comportamento del e i sensori di interruzione, interrompono altre applicazioni.
Fusione del sensore
Il framework Android fornisce un'implementazione predefinita per alcuni i sensori. 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, la struttura implementa questi sensori in modo che le applicazioni possono comunque utilizzarli.
L'implementazione predefinita non ha accesso a tutti i dati che altre perché le implementazioni hanno accesso e deve essere eseguita sul SoC, quindi ed efficienti dal punto di vista energetico come altre implementazioni. Massimo possibili, i produttori di dispositivi devono definire i propri sensori fusi (rotazione vettoriale, gravità e accelerazione lineare, nonché nuovi sensori compositi come il vettore di rotazione del gioco) anziché fare affidamento su questa implementazione predefinita. I produttori di dispositivi possono richiedere inoltre ai fornitori di chip per sensori di fornire loro un'implementazione.
L'implementazione predefinita di Sensor Fusion non viene mantenuta potrebbe causare un errore CTS da parte dei dispositivi che lo utilizzano.
Roba da smanettoni
Questa sezione viene fornita come informazione di base per chi gestisce il Codice del framework Android Open Source Project (AOSP). Non è pertinente per produttori di hardware.
JNI
Il framework utilizza una Java Native Interface (JNI) associata ad android.hardware e che si trova nella directory frameworks/base/core/jni/. Questo codice chiama
per ottenere l'accesso all'hardware del sensore.
Framework nativo
Il framework nativo è definito in frameworks/native/ e fornisce un'architettura nativa
equivalente al pacchetto android.hardware. Il framework nativo chiama i proxy Binder IPC per ottenere l'accesso
e servizi specifici per i sensori.
IPC Binder
I proxy IPC Binder facilitano la comunicazione oltre i confini del processo.
HAL
L'API Sensors Hardware Abstraction Layer (HAL) è l'interfaccia tra driver hardware e il framework Android. Consiste in un'interfaccia HAL Sensori.h e un'implementazione HAL che definiamo sensori.cpp.
L'interfaccia è definita dai collaboratori Android e AOSP e sia fornita dal produttore del dispositivo.
L'interfaccia dell'HAL del sensore si trova in hardware/libhardware/include/hardware.
Vedi sensors.h
per ulteriori dettagli.
Ciclo di rilascio
L'implementazione HAL specifica la versione dell'interfaccia HAL
viene implementata impostando your_poll_device.common.version. L'HAL esistente
le versioni dell'interfaccia sono definite in sensor.h e la funzionalità è legata a quelle
e versioni successive.
Il framework Android supporta attualmente le versioni 1.0 e 1.3, ma la versione 1.0 a breve non sarà più supportato. Questa documentazione descrive il comportamento della versione 1.3, a cui eseguire l'upgrade di tutti i dispositivi. Per informazioni dettagliate su come eseguire l'upgrade a 1.3, consulta Ritiro della versione HAL.
Driver del kernel
I driver dei sensori interagiscono con i dispositivi fisici. In alcuni casi, l'HAL e i driver sono la stessa entità software. In altri casi, richiede ai produttori di chip dei sensori di fornire i ma sono quelli a scrivere l'implementazione dell'HAL.
In tutti i casi, l'implementazione dell'HAL e i driver del kernel sono responsabilità i produttori di hardware e Android non offre approcci preferenziali e scriverli.
Hub dei sensori
L'insieme di sensori di un dispositivo può facoltativamente includere un hub dei sensori, utile per eseguire calcoli di basso livello a bassa potenza mentre il SoC può trovarsi modalità di sospensione. Ad esempio, il conteggio dei passi o la fusione del sensore possono essere eseguiti le patatine. È inoltre un buon posto per implementare il batch dei sensori, aggiungendo FIFO hardware per gli eventi dei sensori. Per ulteriori informazioni, consulta Raggruppamento in batch.
Nota:per sviluppare nuove funzionalità di ContextHub che nuovi sensori o LED, puoi anche usare Neonkey SensorHub collegato a un la scheda di sviluppo Hikey o Hikey960.
Il modo in cui l'hub del sensore viene materializzato dipende dall'architettura. A volte un chip separato e talvolta incluso nello stesso chip del SoC. Importante dell'hub dei sensori è che deve contenere memoria sufficiente per il batch e consumano pochissima energia per consentire l'implementazione del i sensori di Android. Alcuni hub dei sensori contengono un microcontroller per informazioni generiche di calcolo e acceleratori hardware per consentire il calcolo a bassissima potenza per sensori a bassa potenza.
Come è strutturato l'hub dei sensori e come comunica con i sensori e il SoC (bus I2C, bus SPI...) non è specificato da Android, ma dovrebbe puntare nel ridurre al minimo l'utilizzo complessivo di energia.
Un'opzione che sembra avere un impatto significativo sull'implementazione la semplicità è avere due linee di interruzione che vanno dall'hub del sensore al SoC: una per le interruzioni di sveglia (per i sensori di sveglia) e l'altra per le interruzioni non di sveglia (per i sensori non sveglia).
Sensori
Questi sono i chip MEM fisici che effettuano le misurazioni. In molti casi, sono presenti più sensori fisici sullo stesso chip. Ad esempio, alcuni chip includono un accelerometro, un giroscopio e un magnetometro. (Queste patatine spesso sono chiamati chip a 9 assi, poiché ciascun sensore fornisce dati su 3 assi.)
Alcuni di questi chip contengono anche una logica per eseguire calcoli abituali, come rilevamento dei movimenti, rilevamento dei passi e alla fusione dei sensori a 9 assi.
Sebbene i requisiti e i consigli relativi all'alimentazione e all'accuratezza del CDD riguardino i sensori Android e non quelli fisici. Questi requisiti incidono la scelta dei sensori fisici. Ad esempio, i requisiti di precisione del gioco di rotazione del vettore ha implicazioni sulla precisione richiesta un giroscopio. Spetta al produttore del dispositivo ricavare i requisiti per sensori fisici.