Gli smartphone contengono una serie di processori, ciascuno ottimizzato per eseguire attività diverse. Tuttavia, Android funziona solo su un processore: il processore delle applicazioni (AP). L'AP è ottimizzato per offrire prestazioni eccezionali per casi d'uso con schermo acceso come i giochi, ma è troppo assetato di energia per supportare funzionalità che richiedono raffiche di elaborazione frequenti e brevi in ogni momento, anche quando lo schermo è spento. I processori più piccoli sono in grado di gestire questi carichi di lavoro in modo più efficiente, completando le proprie attività senza incidere notevolmente sulla durata della batteria. Tuttavia, gli ambienti software in questi processori a basso consumo sono più limitati e possono variare notevolmente, rendendo difficile lo sviluppo multipiattaforma.
Context Hub Runtime Environment (CHRE) fornisce una piattaforma comune per l'esecuzione di app su un processore a basso consumo, con un'API semplice, standardizzata e integrata. CHRE consente agli OEM di dispositivi e ai loro partner di fiducia di scaricare facilmente l'elaborazione dall'AP, di risparmiare batteria e migliorare varie aree dell'esperienza dell'utente e di abilitare una classe di funzionalità sempre attive e contestualmente consapevoli, in particolare quelle che coinvolgono l'applicazione della macchina apprendimento del rilevamento ambientale.
Concetti chiave
CHRE è l'ambiente software in cui piccole applicazioni native, chiamate nanoapp , vengono eseguite su un processore a basso consumo e interagiscono con il sistema sottostante tramite la comune API CHRE. Per accelerare la corretta implementazione delle API CHRE, in AOSP è inclusa un'implementazione di riferimento multipiattaforma di CHRE. L'implementazione di riferimento include codice comune e astrazioni per l'hardware e il software sottostanti attraverso una serie di livelli di astrazione della piattaforma (PAL). Le nanoapp sono quasi sempre legate a una o più app client in esecuzione su Android, che interagiscono con CHRE e le nanoapp tramite API del sistema ContextHubManager ad accesso limitato.
Ad alto livello, si possono tracciare paralleli tra l'architettura di CHRE e Android nel suo insieme. Esistono però alcune importanti distinzioni:
- CHRE supporta l'esecuzione solo di nanoapp sviluppate in codice nativo (C o C++); Java non è supportato.
- A causa di vincoli di risorse e limitazioni di sicurezza, CHRE non può essere utilizzato da app Android arbitrarie di terze parti. Solo le app attendibili dal sistema possono accedervi.
C'è anche un'importante distinzione da fare tra il concetto di CHRE e quello di hub di sensori. Sebbene sia comune utilizzare lo stesso hardware per implementare l'hub del sensore e CHRE, CHRE stesso non fornisce la funzionalità del sensore richiesta dall'HAL dei sensori Android . CHRE è legato all'HAL Context Hub e funge da client di un framework di sensori specifico del dispositivo per ricevere i dati dei sensori senza coinvolgere l'AP.
Figura 1. Architettura quadro CHRE
Hub di contesto HAL
Il livello di astrazione hardware (HAL) di Context Hub è l'interfaccia tra il framework Android e l'implementazione CHRE del dispositivo, definita in hardware/interfaces/contexthub . L'HAL Context Hub definisce le API attraverso le quali il framework Android rileva gli hub di contesto disponibili e le relative nanoapp, interagisce con tali nanoapp tramite lo scambio di messaggi e consente il caricamento e lo scaricamento delle nanoapp. Un'implementazione di riferimento dell'HAL Context Hub che funziona con l'implementazione di riferimento di CHRE è disponibile in system/chre/host .
In caso di conflitto tra questa documentazione e la definizione HAL, la definizione HAL ha la precedenza.
Inizializzazione
All'avvio di Android, ContextHubService richiama la funzione HAL getHubs() per determinare se sul dispositivo sono disponibili hub di contesto. Si tratta di una chiamata bloccante e una tantum, pertanto deve essere completata rapidamente per evitare ritardi nell'avvio e deve restituire un risultato accurato, poiché in seguito non è possibile introdurre nuovi hub di contesto.
Caricamento e scaricamento di nanoapp
Un hub di contesto può includere un set di nanoapp incluse nell'immagine del dispositivo e caricate all'avvio di CHRE. Queste sono note come nanoapp precaricate e dovrebbero essere incluse nella prima risposta possibile a queryApps() .
L'HAL dell'hub contesto supporta inoltre il caricamento e lo scaricamento dinamico delle nanoapp in fase di runtime, tramite le funzioni loadNanoApp() e unloadNanoApp() . Le nanoapp vengono fornite all'HAL in un formato binario specifico per l'implementazione hardware e software CHRE del dispositivo.
Se l'implementazione per il caricamento di una nanoapp prevede la scrittura della stessa nella memoria non volatile, ad esempio una memoria flash collegata al processore che esegue CHRE, l'implementazione CHRE deve sempre avviarsi con queste nanoapp dinamiche nello stato disabilitato. Ciò significa che nessuno dei codici di nanoapp viene eseguito finché non viene ricevuta una richiesta enableNanoapp() tramite l'HAL. Le nanoapp precaricate possono essere inizializzate nello stato abilitato.
L'hub di contesto si riavvia
Anche se non è previsto il riavvio di CHRE durante il normale funzionamento, potrebbe essere necessario il ripristino in seguito a condizioni impreviste, ad esempio un tentativo di accesso a un indirizzo di memoria non mappato. In queste situazioni, CHRE si riavvia indipendentemente da Android. L'HAL avvisa Android di ciò tramite l'evento RESTARTED , che deve inviare solo dopo che CHRE è stato reinizializzato al punto da poter accettare nuove richieste, come queryApps() .
Panoramica del sistema CHRE
CHRE è progettato attorno a un'architettura basata sugli eventi, in cui l'unità primaria di calcolo è un evento passato al punto di ingresso della gestione degli eventi di una nanoapp. Sebbene il framework CHRE possa essere multithread, una determinata nanoapp non viene mai eseguita da più thread in parallelo. Il framework CHRE interagisce con una determinata nanoapp tramite uno dei tre punti di ingresso nanoapp ( nanoappStart() , nanoappHandleEvent() e nanoappEnd() ) o tramite un callback fornito in una precedente chiamata API CHRE e le nanoapp interagiscono con il framework CHRE e il sistema sottostante tramite l'API CHRE. L'API CHRE fornisce una serie di funzionalità di base e strutture per l'accesso a segnali contestuali, inclusi sensori, GNSS, Wi-Fi, WWAN e audio, e può essere estesa con funzionalità aggiuntive specifiche del fornitore per l'utilizzo da parte di nanoapp specifiche del fornitore .
Costruisci il sistema
Sebbene l'HAL Context Hub e altri componenti necessari sul lato AP siano creati insieme ad Android, il codice eseguito all'interno di CHRE può avere requisiti che lo rendono incompatibile con il sistema di compilazione Android, come la necessità di una toolchain specializzata. Pertanto, il progetto CHRE in AOSP fornisce un sistema di compilazione semplificato basato su GNU Make per compilare nanoapp e, facoltativamente, il framework CHRE in librerie che possono essere integrate con il sistema. I produttori di dispositivi che aggiungono il supporto per CHRE dovrebbero integrare il supporto del sistema di build per i loro dispositivi di destinazione in AOSP.
L'API CHRE è scritta nello standard del linguaggio C99 e l'implementazione di riferimento utilizza un sottoinsieme ristretto di C++11 adatto ad applicazioni con risorse limitate.
API CHRE
L'API CHRE è una raccolta di file di intestazione C che definiscono l'interfaccia software tra una nanoapp e il sistema. È progettato per rendere il codice delle nanoapp compatibile su tutti i dispositivi che supportano CHRE, il che significa che il codice sorgente di una nanoapp non deve essere modificato per supportare un nuovo tipo di dispositivo, anche se potrebbe dover essere ricompilato appositamente per il processore del dispositivo di destinazione set di istruzioni o interfaccia binaria dell'applicazione (ABI). L'architettura CHRE e il design dell'API garantiscono inoltre che le nanoapp siano compatibili a livello binario tra diverse versioni dell'API CHRE, il che significa che una nanoapp non deve essere ricompilata per essere eseguita su un sistema che implementa una versione diversa dell'API CHRE rispetto a l'API di destinazione rispetto alla quale viene compilata la nanoapp. In altre parole, se un file binario nanoapp viene eseguito su un dispositivo che supporta l'API CHRE v1.3 e tale dispositivo viene aggiornato per supportare l'API CHRE v1.4, lo stesso file binario nanoapp continua a funzionare. Allo stesso modo, la nanoapp può essere eseguita sull'API CHRE v1.2 e può determinare in fase di esecuzione se richiede funzionalità dell'API v1.3 per ottenere la sua funzionalità o se può funzionare, potenzialmente con un graduale degrado delle funzionalità.
Le nuove versioni dell'API CHRE vengono rilasciate insieme ad Android, tuttavia, poiché l'implementazione CHRE fa parte dell'implementazione del fornitore , la versione dell'API CHRE supportata su un dispositivo non è necessariamente collegata a una versione Android.
Riepilogo della versione
Come lo schema di controllo delle versioni HIDL di Android , l'API CHRE segue il controllo delle versioni semantico . La versione principale indica la compatibilità binaria, mentre la versione secondaria viene incrementata quando vengono introdotte funzionalità compatibili con le versioni precedenti. L'API CHRE include annotazioni sul codice sorgente per identificare quale versione ha introdotto una funzione o un parametro, ad esempio @since v1.1 .
L'implementazione CHRE espone anche una versione patch specifica della piattaforma tramite chreGetVersion() , che indica quando vengono apportate correzioni di bug o aggiornamenti minori nell'implementazione.
Versione 1.0 (Android 7)
Include il supporto per sensori e funzionalità principali della nanoapp, come eventi e timer.
Versione 1.1 (Android 8)
Introduce funzionalità di localizzazione tramite localizzazione GNSS e misurazioni grezze, scansione Wi-Fi e informazioni sulla rete cellulare, insieme a perfezionamenti generali per consentire la comunicazione da nanoapp a nanoapp e altri miglioramenti.
Versione 1.2 (Android 9)
Aggiunge il supporto per i dati da un microfono a basso consumo, portata Wi-Fi RTT, notifiche di riattivazione/sospensione dell'AP e altri miglioramenti.
Versione 1.3 (Android 10)
Migliora le funzionalità relative ai dati di calibrazione del sensore, aggiunge il supporto per lo svuotamento dei dati dei sensori in batch su richiesta, definisce il tipo di sensore di rilevamento dei passi ed estende gli eventi di posizione GNSS con campi di precisione aggiuntivi.
Versione 1.4 (Android 11)
Aggiunge il supporto per le informazioni sulla cella 5G, il dump del debug di nanoapp e altri miglioramenti.
Funzionalità obbligatorie del sistema
Sebbene le fonti di segnali contestuali, come i sensori, siano classificate in aree di funzionalità opzionali, in tutte le implementazioni CHRE sono richieste alcune funzioni principali. Ciò include le API di sistema principali, come quelle per l'impostazione dei timer, l'invio e la ricezione di messaggi ai client sul processore delle applicazioni, la registrazione e altro. Per i dettagli completi, consulta le intestazioni API .
Oltre alle funzionalità principali del sistema codificate nell'API CHRE, esistono anche funzionalità CHRE obbligatorie a livello di sistema specificate a livello HAL dell'hub contestuale. Il più significativo di questi è la capacità di caricare e scaricare dinamicamente le nanoapp.
Libreria standard C/C++
Per ridurre al minimo l'utilizzo della memoria e la complessità del sistema, le implementazioni CHRE devono supportare solo un sottoinsieme delle librerie C e C++ standard e delle funzionalità del linguaggio che richiedono il supporto del runtime. Seguendo questi principi, alcune funzionalità sono esplicitamente escluse a causa della loro memoria e/o delle estese dipendenze a livello di sistema operativo e altre perché sono soppiantate da API specifiche CHRE più adatte. Pur non essendo un elenco esaustivo, le seguenti funzionalità non sono destinate a essere rese disponibili alle nanoapp:
- Eccezioni C++ e informazioni sul tipo di runtime (RTTI)
- Supporto multithreading della libreria standard, incluse le intestazioni C++11
<thread>,<mutex>,<atomic>,<future> - Librerie di input/output standard C e C++
- Libreria di modelli standard C++ (STL)
- Libreria di espressioni regolari standard C++
- Allocazione dinamica della memoria tramite funzioni standard (ad esempio,
malloc,calloc,realloc,free,operator new) e altre funzioni della libreria standard che utilizzano intrinsecamente l'allocazione dinamica, comestd::unique_ptr - Localizzazione e supporto dei caratteri Unicode
- Librerie di data e ora
- Funzioni che modificano il normale flusso del programma, inclusi
<setjmp.h>,<signal.h>,abort,std::terminate - Accesso all'ambiente host, incluso
system,getenv - POSIX e altre librerie non incluse negli standard del linguaggio C99 o C++11
In molti casi, funzionalità equivalenti sono disponibili dalle funzioni API CHRE e/o dalle librerie di utilità. Ad esempio, chreLog può essere utilizzato per la registrazione del debug mirata al sistema logcat Android, dove un programma più tradizionale potrebbe utilizzare printf o std::cout .
Al contrario, sono richieste alcune funzionalità della libreria standard. Spetta all'implementazione della piattaforma esporli tramite librerie statiche da includere in un file binario nanoapp o tramite collegamento dinamico tra nanoapp e sistema. Ciò include, ma non è limitato a:
- Utilità per stringhe/array:
memcmp,memcpy,memmove,memset,strlen Libreria matematica: funzioni a virgola mobile a precisione singola comunemente utilizzate:
- Operazioni di base:
ceilf,fabsf,floorf,fmaxf,fminf,fmodf,roundf,lroundf,remainderf - Funzioni esponenziali/potenza:
expf,log2f,powf,sqrtf - Funzioni trigonometriche/iperboliche:
sinf,cosf,tanf,asinf,acosf,atan2f,tanhf
- Operazioni di base:
Sebbene alcune piattaforme sottostanti supportino funzionalità aggiuntive, una nanoapp non è considerata portabile tra le implementazioni CHRE a meno che non limiti le sue dipendenze esterne alle funzioni API CHRE e alle funzioni della libreria standard approvate.
Caratteristiche opzionali
Per promuovere hardware e software, l'API CHRE è divisa in aree di funzionalità, considerate facoltative dal punto di vista dell'API. Anche se queste funzionalità potrebbero non essere necessarie per supportare un'implementazione CHRE compatibile, potrebbero essere necessarie per supportare una particolare nanoapp. Anche se una piattaforma non supporta un determinato set di API, le nanoapp che fanno riferimento a tali funzioni devono essere in grado di creare e caricare.
Sensori
L'API CHRE offre la possibilità di richiedere dati da sensori tra cui accelerometro, giroscopio, magnetometro, sensore di luce ambientale e prossimità. Queste API hanno lo scopo di fornire un set di funzionalità simile alle API dei sensori Android, incluso il supporto per l'invio in batch di campioni di sensori per ridurre il consumo energetico. L'elaborazione dei dati dei sensori all'interno di CHRE consente un'elaborazione dei segnali di movimento con una potenza molto inferiore e una latenza inferiore rispetto all'esecuzione sull'AP.
GNSS
CHRE fornisce API per richiedere dati sulla posizione da un sistema globale di navigazione satellitare (GNSS), inclusi GPS e altre costellazioni satellitari. Ciò include richieste di correzioni periodiche della posizione, nonché dati di misurazione grezzi, sebbene entrambe siano capacità indipendenti. Poiché CHRE ha un collegamento diretto al sottosistema GNSS, la potenza è ridotta rispetto alle richieste GNSS basate sull'AP, poiché l'AP può rimanere inattivo durante l'intero ciclo di vita di una sessione di localizzazione.
Wifi
CHRE offre la possibilità di interagire con il chip Wi-Fi, principalmente per scopi di localizzazione. Sebbene il GNSS funzioni bene per le posizioni all'aperto, i risultati delle scansioni Wi-Fi possono fornire informazioni precise sulla posizione all'interno e nelle aree sviluppate. Oltre a evitare il costo di riattivazione dell'AP per una scansione, CHRE può ascoltare i risultati delle scansioni Wi-Fi eseguite dal firmware Wi-Fi per scopi di connettività, che in genere non vengono consegnati all'AP per motivi di alimentazione. Sfruttare le scansioni della connettività per scopi contestuali aiuta a ridurre il numero totale di scansioni Wi-Fi eseguite, risparmiando energia.
Il supporto per il Wi-Fi è stato aggiunto nell'API CHRE v1.1, inclusa la possibilità di monitorare i risultati della scansione e attivare scansioni su richiesta. Queste funzionalità sono state estese nella versione 1.2 con la possibilità di eseguire misurazioni del tempo di andata e ritorno (RTT) rispetto ai punti di accesso che supportano la funzionalità, che consente una determinazione accurata della posizione relativa.
WWAN
L'API CHRE offre la possibilità di recuperare informazioni di identificazione della cella per la cella servente e quelle vicine, che vengono generalmente utilizzate per scopi di localizzazione a grana grossa.
Audio
CHRE può elaborare batch di dati audio da un microfono a bassa potenza, che in genere sfrutta l'hardware utilizzato per implementare SoundTrigger HAL. L'elaborazione dei dati audio in CHRE può consentirne la fusione con altri dati, come i sensori di movimento.
Implementazione di riferimento
Il codice di riferimento per il framework CHRE è incluso in AOSP nel progetto system/chre , implementato in C++11. Sebbene non sia strettamente richiesto, è consigliabile che tutte le implementazioni CHRE siano basate su questa codebase, per garantire la coerenza e accelerare l'adozione di nuove funzionalità. Questo codice può essere visto come un analogo al framework Android principale in quanto è un'implementazione open source delle API utilizzate dalle applicazioni, che funge da base e standard per la compatibilità. Sebbene possa essere personalizzato ed esteso con funzionalità specifiche del fornitore, la raccomandazione è di mantenere il codice comune il più vicino possibile al riferimento. Similmente agli HAL di Android, l'implementazione di riferimento CHRE utilizza varie astrazioni della piattaforma per consentirne l'adattamento a qualsiasi dispositivo che soddisfi i requisiti minimi.
Per dettagli tecnici e una guida al porting, vedere il README incluso nel progetto system/chre .