Ambiente di runtime dell'hub di contesto (CHRE)

Gli smartphone contengono una serie di processori, ciascuno ottimizzato per l'esecuzione di attività diverse. Tuttavia, Android funziona solo su un processore: il processore di applicazioni (AP). L'AP è ottimizzato per offrire ottime prestazioni per casi d'uso con lo schermo attivo come i giochi, ma è troppo energivoro per supportare funzionalità che richiedono sempre picchi di elaborazione frequenti e brevi, anche quando lo schermo è spento. I processori più piccoli sono in grado di gestire questi carichi di lavoro in modo più efficiente, completando le attività senza influire in modo significativo sulla durata della batteria. Tuttavia, gli ambienti software di 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 semplifica per gli OEM dei dispositivi e i loro partner di fiducia il trasferimento dell'elaborazione dall'AP, consente di risparmiare batteria e migliorare varie aree dell'esperienza utente e abilita una classe di funzionalità sempre attive e consapevoli del contesto, in particolare quelle che prevedono l'applicazione del machine learning al rilevamento ambientale.

Concetti principali

CHRE è l'ambiente software in cui piccole app native, chiamate nanoapp, vengono eseguite su un processore a basso consumo e interagiscono con il sistema sottostante tramite l'API CHRE comune. Per accelerare la corretta implementazione delle API CHRE, AOSP include un'implementazione di riferimento multipiattaforma di riferimento. L'implementazione di riferimento include codice e astrazioni comuni per l'hardware e il software di base tramite una serie di livelli di astrazione della piattaforma (PAL). Le nanoapp sono quasi sempre associate a una o più app client in esecuzione su Android, che interagiscono con CHRE e nanoapp tramite API di sistema con accesso limitato.ContextHubManager

A un livello generale, è possibile tracciare paralleli tra l'architettura di CHRE e Android nel suo complesso. Tuttavia, esistono alcune importanti distinzioni:

  • CHRE supporta l'esecuzione solo di nanoapp sviluppate in codice nativo (C o C++); Java non è supportato.
  • A causa dei vincoli delle risorse e delle limitazioni di sicurezza, CHRE non può essere utilizzato da app Android di terze parti arbitrarie. Solo le app attendibili dal sistema possono accedervi.

Inoltre, è importante distinguere il concetto di CHRE da un hub di sensori. Sebbene sia comune utilizzare lo stesso hardware per implementare l'hub di sensori e il CHRE, quest'ultimo non fornisce le funzionalità dei sensori richieste dall'HAL Android Sensors. CHRE è associato all'HAL di Context Hub e agisce come client di un framework di sensori specifico per il dispositivo per ricevere i dati dei sensori senza coinvolgere l'AP.

Architettura del framework CHRE

Figura 1. Architettura del framework CHRE

HAL di Hub di contesto

L'HAL (Hardware Abstraction Layer) di Context Hub è l'interfaccia tra il framework Android e l'implementazione CHRE del dispositivo, definita in hardware/interfaces/contexthub. L'HAL di Hub di contesto definisce le API tramite le quali il framework Android scopre gli hub di contesto disponibili e le relative nanoapp, interagisce con queste nanoapp tramite il passaggio di messaggi e consente di caricare e scaricare le nanoapp. Un'implementazione di riferimento dell'HAL di Hub per il contesto che funziona con l'implementazione di riferimento di CHRE è disponibile all'indirizzo system/chre/host.

In caso di conflitto tra questa documentazione e la definizione HAL, prevarrà la definizione HAL.

Inizializzazione

All'avvio di Android, il servizio ContextHubService invoca la funzione HAL getHubs() per determinare se sono disponibili hub di contesto sul dispositivo. Si tratta di una chiamata una tantum bloccante, pertanto deve essere completata rapidamente per evitare di ritardare l'avvio e deve restituire un risultato accurato, poiché non è possibile introdurre nuovi hub di contesto in un secondo momento.

Carica e scarica le nanoapp

Un hub di contesto può includere un insieme di nanoapp incluse nell'immagine del dispositivo e caricate all'avvio del CHRE. Queste sono chiamate nanoapp precaricate e devono essere incluse nella prima risposta possibile a queryApps().

L'HAL di Context Hub supporta anche il caricamento e lo scambio dinamico delle nanoapp in fase di esecuzione tramite le funzioni loadNanoApp() e unloadNanoApp(). Le nanoapp vengono fornite all'HAL in un formato binario specifico per l'implementazione hardware e software del CHRE del dispositivo.

Se l'implementazione per il caricamento di una nanoapp prevede la scrittura nella memoria non volatile, ad esempio nello spazio di archiviazione flash collegato al processore che esegue CHRE, l'implementazione di CHRE deve sempre avviarsi con queste nanoapp dinamiche nello stato disattivato. Ciò significa che nessuno dei codici della nanoapp viene eseguito finché non viene ricevuta una richiesta enableNanoapp() tramite l'HAL. Le nanoapp precaricate possono iniziare nello stato Attivato.

Riavvii dell'hub di contesto

Sebbene non sia previsto che il CHRE si riavvii durante il normale funzionamento, può essere necessario recuperare da condizioni impreviste come un tentativo di accedere a un indirizzo di memoria non mappato. In questi casi, CHRE si riavvia indipendente da Android. L'HAL ne informa Android tramite l'evento RESTARTED, che deve inviare solo dopo il reinizializzazione del CHRE in modo che possa accettare nuove richieste, come queryApps().

Panoramica del sistema CHRE

CHRE è progettato attorno a un'architettura basata su eventi, in cui l'unità di calcolo principale è un evento passato al punto di contatto di gestione degli eventi di una nanoapp. Anche se il framework CHRE può 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 contatto delle nanoapp (nanoappStart(),nanoappHandleEvent() e nanoappEnd()) o tramite un callback fornito in una chiamata precedente all'API CHRE. Le nanoapp interagiscono con il framework CHRE e con il sistema sottostante tramite l'API CHRE. L'API CHRE offre una serie di funzionalità di base, nonché servizi per accedere a indicatori di contesto, tra cui sensori, GNSS, Wi-Fi, WWAN e audio, e può essere estesa con ulteriori funzionalità specifiche del fornitore per l'utilizzo da parte di nanoapp specifiche del fornitore.

Sistema di compilazione

Sebbene l'HAL di Context Hub e altri componenti lato AP necessari vengano compilati insieme ad Android, il codice in esecuzione in CHRE può avere requisiti che lo rendono incompatibile con il sistema di compilazione di Android, ad esempio 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 nel sistema. I produttori di dispositivi che aggiungono il supporto per CHRE devono integrare il supporto del sistema di compilazione per i propri dispositivi di destinazione in AOSP.

L'API CHRE è scritta nello standard di lingua C99 e l'implementazione di riferimento utilizza un sottoinsieme limitato di C++11 adatto per le app 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 compatibile il codice delle nanoapp 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 essere necessario ricompilarlo specificamente per l'insieme di istruzioni del processore o l'interfaccia a bit dell'applicazione (ABI) del dispositivo di destinazione. L'architettura CHRE e la progettazione dell'API assicurano inoltre che le nanoapp siano compatibili binarie tra le diverse versioni dell'API CHRE, il che significa che non è necessario ricompilare una nanoapp per essere eseguita su un sistema che implementa una versione diversa dell'API CHRE rispetto all'API target su cui viene compilata la nanoapp. In altre parole, se un file binario di nanoapp viene eseguito su un dispositivo che supporta l'API CHRE v1.3 e su quel dispositivo viene eseguito l'upgrade per supportare l'API CHRE v1.4, lo stesso file binario di nanoapp continua a funzionare. Analogamente, la nanoapp può essere eseguita sull'API CHRE 1.2 e può determinare in fase di esecuzione se richiede funzionalità dell'API 1.3 per essere utilizzata o se può operare, potenzialmente con un graduale declino delle funzionalità.

Oltre ad Android vengono rilasciate nuove versioni dell'API CHRE, tuttavia, poiché l'implementazione di CHRE fa parte dell'implementazione del fornitore, la versione dell'API CHRE supportata su un dispositivo non è necessariamente collegata a una versione di Android.

Riepilogo della versione

Come il schema di controllo della versione HIDL di Android, l'API CHRE segue il controllo della versione semantica. La versione principale indica la compatibilità binaria, mentre la versione minore viene incrementata quando vengono introdotte funzionalità compatibili con le versioni precedenti. L'API CHRE include annotazioni del codice sorgente per identificare la versione che ha introdotto una funzione o un parametro, ad esempio @since v1.1.

L'implementazione CHRE espone anche una versione della patch specifica della piattaforma tramite chreGetVersion(), che indica quando vengono apportati correzioni di bug o aggiornamenti minori nell'implementazione.

Versione 1.0 (Android 7)

Include il supporto per i sensori e le funzionalità di base delle nanoapp, come eventi e timer.

Versione 1.1 (Android 8)

Introduce funzionalità di geolocalizzazione tramite misurazioni non elaborate e posizione GNSS, scansione Wi-Fi e informazioni sulla rete mobile, oltre a perfezionamenti generali per abilitare la comunicazione tra nanoapp e altri miglioramenti.

Versione 1.2 (Android 9)

Aggiunge il supporto per i dati di un microfono a basso consumo, la misurazione del RTT Wi-Fi, le notifiche di attivazione e sospensione dell'AP e altri miglioramenti.

Versione 1.3 (Android 10)

Migliora le funzionalità relative ai dati di calibrazione dei sensori, aggiunge il supporto per il svuotamento dei dati dei sensori raggruppati su richiesta, definisce il tipo di sensore di rilevamento dei passi e estende gli eventi di geolocalizzazione GNSS con campi di precisione aggiuntivi.

Versione 1.4 (Android 11)

Sono stati aggiunti il supporto per le informazioni sulle celle 5G, il dump di debug delle nanoapp e altri miglioramenti.

Funzionalità di sistema obbligatorie

Le origini degli indicatori di contesto, come i sensori, sono classificate in aree di funzionalità facoltative, ma in tutte le implementazioni CHRE sono necessarie alcune funzioni fondamentali. Sono incluse le API di sistema di base, ad esempio quelle per l'impostazione di timer, l'invio e la ricezione di messaggi ai client sull'elaborazione delle applicazioni, il logging e altre. Per informazioni dettagliate, consulta le intestazioni API.

Oltre alle funzionalità di sistema di base codificate nell'API CHRE, esistono anche funzionalità obbligatorie a livello di sistema CHRE specificate a livello di HAL di Hub di contesto. La più significativa è la possibilità 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 di runtime. In base a questi principi, alcune funzionalità sono escluse esplicitamente a causa della loro memoria e delle ampie dipendenze a livello di sistema operativo, mentre altre perché sono sostituite da API specifiche per CHRE più adatte. Sebbene non sia un elenco esaustivo, le seguenti funzionalità non sono pensate per essere messe a disposizione delle nanoapp:

  • Eccezione C++ e informazioni sul tipo di runtime (RTTI)
  • Supporto del multithreading delle librerie standard, incluse le intestazioni C++11 <thread>, <mutex>, <atomic>, <future>
  • Librerie di input/output standard C e C++
  • Libreria di modelli standard (STL) C++
  • 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 biblioteca standard che utilizzano intrinsecamente l'allocazione dinamica, come std::unique_ptr
  • Localizzazione e supporto dei caratteri Unicode
  • Librerie di date e ore
  • Funzioni che modificano il normale flusso del programma, tra cui <setjmp.h>, <signal.h>, abort, std::terminate
  • Accesso all'ambiente host, inclusi system, getenv
  • POSIX e altre librerie non incluse negli standard di lingua C99 o C++11

In molti casi, le funzionalità equivalenti sono disponibili nelle funzioni dell'API CHRE e nelle librerie di utilità. Ad esempio, è possibile utilizzare chreLog per il logging del debug miso il sistema logcat di Android, dove un programma più tradizionale potrebbe utilizzare printf o std::cout.

Al contrario, alcune funzionalità della raccolta standard sono obbligatorie. Spetta all'implementazione della piattaforma esporli tramite librerie statiche per l'inclusione in un file binario della nanoapp o tramite il collegamento dinamico tra la nanoapp e il sistema. Sono inclusi, a titolo esemplificativo:

  • Utilità per stringhe e array: memcmp, memcpy, memmove, memset, strlen

  • Libreria matematica: funzioni con virgola mobile a precisione singola di uso comune:

    • Operazioni di base: ceilf, fabsf, floorf, fmaxf, fminf, fmodf, roundf, lroundf, remainderf
    • Funzioni esponenziali e di potenza: expf, log2f, powf, sqrtf
    • Funzioni trigonometriche e iperboliche: sinf, cosf, tanf, asinf, acosf, atan2f, tanhf

Sebbene alcune piattaforme sottostanti supportino funzionalità aggiuntive, una nanoapp non è considerata portabile nelle implementazioni CHRE, a meno che non vincola le sue dipendenze esterne alle funzioni API CHRE e alle funzioni di libreria standard approvate.

Funzionalità facoltative

Per promuovere hardware e software, l'API CHRE è suddivisa in aree di funzionalità, che sono considerate facoltative dal punto di vista dell'API. Sebbene queste funzionalità potrebbero non essere necessarie per supportare un'implementazione CHRE compatibile, potrebbero essere obbligatorie per supportare una determinata nanoapp. Anche se una piattaforma non supporta un determinato insieme di API, le nanoapp che fanno riferimento a queste funzioni devono essere in grado di essere create e caricate.

Sensori

L'API CHRE consente di richiedere dati da sensori come accelerometro, giroscopio, magnetometro, sensore di luce ambientale e di prossimità. Queste API hanno lo scopo di fornire un insieme di funzionalità simile a quello delle API Android Sensor, incluso il supporto per l'aggregazione dei campioni del sensore per ridurre il consumo energetico. L'elaborazione dei dati dei sensori all'interno del CHRE consente un'elaborazione dei segnali di movimento con un consumo energetico e una latenza molto inferiori rispetto all'esecuzione sull'AP.

GNSS

CHRE fornisce API per richiedere dati sulla posizione da un sistema di navigazione satellite (GNSS) globale, inclusi GPS e altre costellazioni di satelliti. Sono incluse le richieste di correzioni periodiche della posizione, nonché i dati di misurazione non elaborati, anche se entrambe sono funzionalità indipendenti. Poiché il CHRE ha un collegamento diretto al sottosistema GNSS, il consumo energetico è ridotto rispetto alle richieste GNSS basate su AP, perché l'AP può rimanere in modalità di sospensione durante l'intero ciclo di vita di una sessione di geolocalizzazione.

Wi-Fi

CHRE offre la possibilità di interagire con il chip Wi-Fi, principalmente per scopi di geolocalizzazione. Sebbene il GNSS funzioni bene per le posizioni all'aperto, i risultati delle ricerche di reti Wi-Fi possono fornire informazioni sulla posizione precise al chiuso e nelle aree sviluppate. Oltre ad evitare il costo di riattivare l'AP per una scansione, il CHRE può ascoltare i risultati delle scansioni Wi-Fi eseguite dal firmware Wi-Fi per scopi di connettività, che in genere non vengono inviati all'AP per motivi di alimentazione. Sfruttare le analisi di connettività per scopi contestuali contribuisce a ridurre il numero totale di analisi Wi-Fi eseguite, risparmiando energia.

Il supporto del Wi-Fi è stato aggiunto nella versione 1.1 dell'API CHRE, inclusa la possibilità di monitorare i risultati delle scansioni e attivare le scansioni su richiesta. Queste funzionalità sono state estese nella versione 1.2 con la possibilità di eseguire misurazioni del tempo di transito (RTT) rispetto ai punti di accesso che supportano la funzionalità, il che consente di determinare con precisione la posizione relativa.

WWAN

L'API CHRE consente di recuperare le informazioni di identificazione della cella per la cella di servizio e le celle vicine, che in genere vengono utilizzate per scopi di localizzazione a livello granulare.

Audio

CHRE può elaborare batch di dati audio da un microfono a basso consumo, che tipicamente sfrutta l'hardware utilizzato per implementare l'HAL SoundTrigger. L'elaborazione degli audiodati in CHRE può consentire la loro combinazione con altri dati, come i sensori di movimento.

Implementazione dei riferimenti

Il codice di riferimento per il framework CHRE è incluso in AOSP nel progetto system/chre, implementato in C++11. Anche se non è strettamente obbligatorio, è consigliabile che tutte le implementazioni CHRE si basino su questo codebase, per garantire la coerenza e accelerare l'adozione di nuove funzionalità. Questo codice può essere considerato un analogo del framework Android di base in quanto è un'implementazione open source delle API utilizzate dalle app, che funge da base di riferimento e standard per la compatibilità. Sebbene possa essere personalizzato ed esteso con funzionalità specifiche del fornitore, è consigliabile mantenere il codice comune il più vicino possibile a quello di riferimento. Analogamente agli HAL di Android, l'implementazione di riferimento CHRE utilizza varie astrattive della piattaforma per poter essere adattata a qualsiasi dispositivo che soddisfi i requisiti minimi.

Per dettagli tecnici e una guida al porting, consulta il file README incluso nel progetto system/chre.