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 adatta all'integrazione. 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 l'implementazione corretta delle API CHRE, in AOSP è inclusa un'implementazione di riferimento multipiattaforma di CHRE. 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 distinzioni importanti:

  • CHRE supporta l'esecuzione solo di nanoapp sviluppate in codice nativo (C o C++). Java non è supportato.
  • A causa di limitazioni di risorse e di sicurezza, CHRE non è aperto all'utilizzo da parte di app Android di terze parti. 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 Hub per il contesto è 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 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 CHRE del dispositivo.

Se l'implementazione per il caricamento di una nanoapp prevede la scrittura in una memoria non volatile, ad esempio lo 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 essere inizializzate nello stato abilitato.

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 API CHRE precedente e le nanoapp interagiscono con il framework CHRE e il sistema sottostante tramite l'API CHRE. L'API CHRE fornisce un insieme di funzionalità di base, nonché strumenti per accedere agli indicatori contestuali, tra cui 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.

Sistema di compilazione

Sebbene l'HAL di Hub di contesto 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 le 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 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 e il design dell'API CHRE assicurano inoltre che le nanoapp siano compatibili a livello di codice macchina su 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 all'API target per la quale è compilata. In altre parole, se un programma binario nanoapp viene eseguito su un dispositivo che supporta l'API CHRE v1.3 e su questo dispositivo viene eseguito l'upgrade per supportare l'API CHRE v1.4, lo stesso programma binario nanoapp continua a funzionare. Analogamente, la nanoapp può essere eseguita sull'API CHRE 1.2 e può determinare in fase di esecuzione se richiede le funzionalità dell'API 1.3 per essere utilizzata o se può funzionare, potenzialmente con un graduale declino delle funzionalità.

Le nuove versioni dell'API CHRE vengono rilasciate insieme ad Android, 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 apportate correzioni di bug o aggiornamenti minori all'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 posizione GNSS con campi di accuratezza aggiuntivi.

Versione 1.4 (Android 11)

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

Funzionalità di sistema obbligatorie

Sebbene le origini degli indicatori contestuali, come i sensori, siano classificate in aree di funzionalità facoltative, alcune funzioni di base sono richieste in tutte le implementazioni di CHRE. 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 destinate a essere rese disponibili per le nanoapp:

  • Eccezione C++ e informazioni sul tipo di runtime (RTTI)
  • Supporto del multithreading della libreria standard, inclusi gli header 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, chreLog può essere utilizzato per la registrazione di debug rivolta al sistema logcat di Android, mentre 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 di base supportino funzionalità aggiuntive, una nanoapp non è considerata portabile tra le implementazioni CHRE, a meno che non limiti le sue dipendenze esterne alle funzioni dell'API CHRE e alle funzioni della 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 globale (GNSS), inclusi GPS e altre costellazioni di satelliti. Sono incluse le richieste di correzioni periodiche della posizione, nonché i dati non elaborati della misurazione, 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 accurate al chiuso e nelle aree sviluppate. Oltre ad evitare il costo di riattivare l'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 inviati all'AP per motivi di alimentazione. Sfruttare le scansioni di connettività per scopi contestuali aiuta a ridurre il numero totale di scansioni 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 offre la possibilità 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 granularità grossolana.

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 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 necessario, è consigliabile che tutte le implementazioni di CHRE si basino su questo codice di base 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.