Ambiente di runtime dell'hub di contesto (CHRE)

Gli smartphone contengono diversi processori, ognuno ottimizzato per eseguire attività diverse. Tuttavia, Android viene eseguito su un solo processore: il processore applicazioni (AP). Il processore dell'app è ottimizzato per offrire prestazioni eccellenti per i casi d'uso con schermo acceso, come i giochi, ma consuma troppa energia per supportare funzionalità che richiedono elaborazioni frequenti e brevi in modo continuo, 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 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 energetico, con un'API semplice, standardizzata e adatta ai sistemi embedded. CHRE consente agli OEM di dispositivi e ai loro partner affidabili di ridurre il carico di elaborazione dell'AP, per risparmiare batteria e migliorare varie aree dell'esperienza utente, nonché di attivare una classe di funzionalità sempre attive e sensibili al 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 energetico 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 sottostanti tramite una serie di livelli di astrazione della piattaforma (PAL). Le nanoapp sono quasi sempre associate a una o più app client in esecuzione in Android, che interagiscono con CHRE e le nanoapp tramite API di sistema ContextHubManager con accesso limitato.

A livello generale, si possono fare dei parallelismi 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 vincoli di risorse e limitazioni di sicurezza, CHRE non è aperto all'utilizzo da parte di app per Android di terze parti arbitrarie. Solo le app attendibili dal sistema possono accedervi.

Inoltre, è importante distinguere tra il concetto di CHRE e un hub sensori. Sebbene sia comune utilizzare lo stesso hardware per implementare l'hub sensori e CHRE, CHRE stesso non fornisce le funzionalità dei sensori richieste dall'HAL dei sensori Android. CHRE è collegato all'HAL Context Hub e funge da client di un framework di sensori specifico del dispositivo per ricevere i dati dei sensori senza coinvolgere il processore applicazioni.

Architettura del framework CHRE

Figura 1. Architettura del framework CHRE

HAL dell'hub di contesto

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 tramite le quali il framework Android rileva gli hub di contesto disponibili e le relative nanoapp, interagisce con queste nanoapp tramite il passaggio 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 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 ContextHubService richiama la funzione HAL getHubs() per determinare se sono disponibili hub di contesto sul dispositivo. Si tratta di una chiamata di blocco una tantum, quindi deve essere completata rapidamente per evitare di ritardare l'avvio e deve restituire un risultato accurato, poiché non è possibile introdurre nuovi hub contestuali in un secondo momento.

Caricare e scaricare le nanoapp

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

L'HAL Context Hub supporta anche 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 nella memoria non volatile, ad esempio l'archiviazione flash collegata al processore che esegue CHRE, l'implementazione CHRE deve sempre avviarsi con queste nanoapp dinamiche nello stato disattivato. Ciò significa che nessun codice della nanoapp viene eseguito finché non viene ricevuta una richiesta enableNanoapp() tramite l'HAL. Le nanoapp precaricate possono inizializzarsi nello stato abilitato.

Riavvii dell'hub di contesto

Sebbene non sia previsto il riavvio di CHRE durante il normale funzionamento, potrebbe essere necessario per il ripristino da 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 comunica questa informazione ad Android tramite l'evento RESTARTED, che deve inviare solo dopo che CHRE è stato reinizializzato al punto in cui può accettare nuove richieste, ad esempio queryApps().

Panoramica del sistema CHRE

CHRE è progettato intorno a un'architettura basata su eventi, in cui l'unità di calcolo principale è un evento passato al punto di ingresso di 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 della nanoapp (nanoappStart(), nanoappHandleEvent() e nanoappEnd()) o tramite un callback fornito in una chiamata API CHRE precedente, mentre 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 e strutture per l'accesso a segnali contestuali, tra cui sensori, GNSS, Wi-Fi, WWAN e audio, e può essere estesa con funzionalità specifiche del fornitore per l'utilizzo da parte di nanoapp specifiche del fornitore.

Sistema di compilazione

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

L'API CHRE è scritta secondo lo standard del linguaggio C99 e l'implementazione di riferimento utilizza un sottoinsieme limitato di C++11 adatto ad 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 il codice delle nanoapp compatibile con 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 il set di istruzioni del processore o l'interfaccia binaria dell'applicazione (ABI) del dispositivo di destinazione. L'architettura e la progettazione dell'API CHRE garantiscono inoltre che le nanoapp siano compatibili a livello binario tra le 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 di destinazione con cui viene compilata la nanoapp. In altre parole, se un binario nanoapp viene eseguito su un dispositivo che supporta l'API CHRE v1.3 e questo dispositivo viene aggiornato per supportare l'API CHRE v1.4, lo stesso binario nanoapp continua a funzionare. Allo stesso modo, la nanoapp può essere eseguita sull'API CHRE v1.2 e può determinare in fase di runtime se richiede funzionalità dell'API v1.3 per raggiungere il suo utilizzo o se può funzionare, potenzialmente con una riduzione graduale delle funzionalità.

Le nuove versioni dell'API CHRE vengono rilasciate insieme ad Android, ma 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 lo 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 secondaria 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 di CHRE espone anche una versione patch specifica della piattaforma tramite chreGetVersion(), che indica quando vengono apportate correzioni di bug o aggiornamenti secondari 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 localizzazione tramite posizione GNSS e misurazioni non elaborate, 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 energetico, la misurazione della distanza Wi-Fi RTT, le notifiche di riattivazione 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 lo svuotamento dei dati dei sensori batch su richiesta, definisce il tipo di sensore di rilevamento dei passi ed estende gli eventi di localizzazione GNSS con campi di precisione aggiuntivi.

Versione 1.4 (Android 11)

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

Funzionalità di sistema obbligatorie

Sebbene le origini dei segnali 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 principali, ad esempio quelle per l'impostazione dei timer, l'invio e la ricezione di messaggi ai client sul processore delle applicazioni, la registrazione e altre. Per tutti i dettagli, consulta le intestazioni API.

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

  • Eccezioni C++ e informazioni sul tipo di runtime (RTTI)
  • Supporto 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 di libreria standard che utilizzano intrinsecamente l'allocazione dinamica, ad esempio std::unique_ptr
  • Supporto per la localizzazione e i caratteri Unicode
  • Librerie di data e ora
  • 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 dei linguaggi C99 o C++11

In molti casi, 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 destinata al sistema logcat di Android, mentre un programma più tradizionale potrebbe utilizzare printf o std::cout.

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

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

  • Libreria matematica: funzioni in 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 portatile tra le implementazioni CHRE a meno che non limiti le sue dipendenze esterne alle funzioni dell'API CHRE e alle funzioni della libreria standard approvata.

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 necessarie per supportare una particolare 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 dai sensori, tra cui accelerometro, giroscopio, magnetometro, sensore della luce ambientale e sensore di prossimità. Queste API hanno lo scopo di fornire un insieme di funzionalità simile alle API Android Sensors, incluso il supporto per il raggruppamento dei campioni dei sensori per ridurre il consumo energetico. L'elaborazione dei dati dei sensori all'interno di CHRE consente un'elaborazione dei segnali di movimento a basso consumo energetico e bassa latenza rispetto all'esecuzione sull'AP.

GNSS

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

Wi-Fi

CHRE consente 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 al chiuso e nelle aree sviluppate. Oltre a evitare il costo di riattivazione del PA 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 al PA per motivi di alimentazione. L'utilizzo delle scansioni di connettività per scopi contestuali contribuisce a ridurre il numero totale di scansioni Wi-Fi eseguite, risparmiando energia.

Il supporto del Wi-Fi è stato aggiunto nell'API CHRE v1.1, inclusa la possibilità di monitorare i risultati delle scansioni e attivarle su richiesta. Queste funzionalità sono state estese nella versione 1.2 con la possibilità di eseguire misurazioni del Round-Trip Time (RTT) rispetto ai punti di accesso che supportano la funzionalità, il che consente una determinazione accurata della 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 vengono in genere utilizzate per scopi di localizzazione approssimativa.

Audio

CHRE può elaborare batch di dati audio da un microfono a basso consumo energetico, che in genere sfrutta l'hardware utilizzato per implementare l'HAL SoundTrigger. L'elaborazione dei dati audio in CHRE può consentire la loro fusione con altri dati, ad esempio quelli dei 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 codebase, per garantire coerenza e accelerare l'adozione di nuove funzionalità. Questo codice può essere visto come analogo al framework Android principale, in quanto è un'implementazione open source di API utilizzate dalle app, che funge da base 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 al riferimento. Analogamente alle 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, consulta il file README incluso nel progetto system/chre.