Ambiente di runtime dell'hub di contesto (CHRE)

Gli smartphone contengono un certo numero di processori, ciascuno ottimizzato per offrire diverse attività. Tuttavia, Android funziona su un solo processore: le applicazioni di elaborazione (AP). L'AP è ottimizzato per offrire prestazioni ottimali per lo screen-on come i giochi, ma richiede troppo energia supportare funzionalità che richiedono tempi di elaborazione frequenti e brevi, in ogni momento, anche quando lo schermo è disattivata. I processori più piccoli sono in grado di gestire questi carichi di lavoro in modo più efficiente, svolgere le proprie attività senza incidere in modo significativo sulla durata della batteria. Tuttavia, ambienti software in questi processori a basso consumo sono più limitati e possono variano notevolmente, rendendo difficile lo sviluppo multipiattaforma.

L'ambiente di runtime dell'hub di contesto (CHRE) fornisce una piattaforma comune per l'esecuzione per le app su un processore a basso consumo, con un l'API incorporata. CHRE semplifica il lavoro degli OEM dei dispositivi e dei loro ai partner di ridurre il carico di elaborazione dell'AP, di risparmiare batteria e migliorare aree dell'esperienza utente e offrono una classe di opzioni sempre attive, le caratteristiche contestualmente consapevoli, in particolare quelle che implicano l'applicazione dal machine learning al rilevamento ambientale.

Concetti principali

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

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

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

C'è anche un'importante distinzione da fare tra il concetto di CHRE e un hub dei sensori. Sebbene sia pratica comune utilizzare lo stesso hardware per implementare hub sensori e CHRE, CHRE in sé non fornisce le funzionalità come richiesto dai Sensori Android HAL CHRE è legato Context Hub HAL e funge da client di un sensore specifico per dispositivo per ricevere dati dei sensori senza coinvolgere l'AP.

Architettura del framework CHRE

Figura 1. Architettura del framework CHRE

HAL hub di contesto

L'HAL (Hardware Astrazione Layer) dell'hub di contesto è l'interfaccia tra il framework Android e l'implementazione CHRE del dispositivo, definiti all'indirizzo hardware/interfaces/contexthub L'HAL di Context Hub definisce le API attraverso le quali il framework Android gli hub di contesto disponibili e le relative nanoapp, interagisce con di nanoapp tramite la trasmissione dei messaggi e consente il caricamento e il caricamento di nanoapp non è stato scaricato. Un'implementazione di riferimento dell'HAL dell'hub di contesto che funziona con di riferimento dell'implementazione CHRE è disponibile all'indirizzo system/chre/host

In caso di conflitto tra questa documentazione e la definizione dell'HAL, La definizione dell'HAL ha la precedenza.

Inizializzazione

All'avvio di Android, ContextHubService richiama la funzione getHubs() HAL per determinare se gli hub di contesto sono disponibili sul dispositivo. Questa è una chiamata una tantum di blocco, quindi deve essere completata rapido per evitare ritardi nell'avvio e deve restituire risultati precisi, come nuovi gli hub di contesto non possono essere introdotti in un secondo momento.

Carica e scarica nanoapp

Un hub di contesto può includere un insieme di nanoapp incluse nel dispositivo e vengono caricati all'avvio di CHRE. Queste sono note come nanoapp precaricate, e deve essere incluso nella prima possibile risposta a queryApps().

L'HAL di Context Hub supporta anche il caricamento e l'unload dinamico di nanoapp il runtime, attraverso le funzioni loadNanoApp() e unloadNanoApp(). Nanoapp vengono forniti all'HAL in un formato binario specifico per l'hardware CHRE e implementazione software del dispositivo.

Se l'implementazione per il caricamento di una nanoapp comporta la scrittura in un ambiente non volatile memoria flash, ad esempio l'archiviazione flash collegata al processore che esegue CHRE, L'implementazione CHRE deve sempre avviarsi con queste nanoapp dinamiche disattivato. Ciò significa che nessuno del codice di nanoapp viene eseguito fino a quando Richiesta enableNanoapp() ricevuta tramite l'HAL. Le nanoapp precaricate possono vengono inizializzate nello stato Attivato.

Riavvii dell'hub di contesto

Sebbene non sia previsto il riavvio di CHRE durante il normale funzionamento, il ripristino da condizioni impreviste, come un tentativo di accedere a un indirizzo di memoria non mappato. In queste situazioni, CHRE si riavvia indipendentemente da Android. L'HAL invia una notifica ad Android tramite RESTARTED evento, che deve essere inviato solo dopo che CHRE è stato reinizializzato in punto in cui può accettare nuove richieste, come queryApps().

Panoramica del sistema CHRE

CHRE è progettato attorno a un'architettura basata su eventi, in cui l'unità principale Il computing è un evento passato al punto di ingresso di una nanoapp per la gestione degli eventi. Mentre il framework CHRE può essere multithread, una determinata nanoapp non viene mai eseguita più thread in parallelo. Il framework CHRE interagisce con una determinata nanoapp attraverso uno dei tre punti di ingresso di nanoapp (nanoappStart(), nanoappHandleEvent() e nanoappEnd()) o tramite una richiamata fornita in un 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 così come le strutture per accedere agli indicatori di contesto, tra cui: sensori GNSS, Wi-Fi, WWAN e audio, e può essere esteso con e funzionalità specifiche del fornitore per l'uso da parte di nanoapp specifiche del fornitore.

Sistema di compilazione

Sebbene l'hub di contesto HAL e gli altri componenti lato AP necessari insieme ad Android, il codice che viene eseguito all'interno di CHRE può avere requisiti che lo rendono incompatibile con il sistema di build Android, come la necessità di un la toolchain. Pertanto, il progetto CHRE in AOSP fornisce una build semplificata basato su GNU Make per compilare nanoapp e, facoltativamente, su CHRE in librerie che possono essere integrate con il sistema. Dispositivo i produttori che aggiungono il supporto per CHRE devono integrare il supporto del sistema di compilazione i loro dispositivi target in AOSP.

L'API CHRE è scritta secondo lo standard linguistico C99 e il riferimento utilizza un sottoinsieme limitato di C++11 adatto a risorse limitate app.

API CHRE

L'API CHRE è una raccolta di file di intestazione C che definiscono il software tra una nanoapp e il sistema. È progettata per creare 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 dispositivo tipo, anche se potrebbe essere necessario ricompilarlo appositamente per il tipo set di istruzioni del processore o ABI (Application Bin Interface). CHRE l'architettura e la progettazione delle API assicurano inoltre che le nanoapp siano compatibili con i file binari, diverse versioni dell'API CHRE, il che significa che una nanoapp devono essere ricompilati per essere eseguiti su un sistema che implementa una versione diversa l'API CHRE rispetto all'API target su cui è compilata la nanoapp. In altre parole, se un file binario nanoapp viene eseguito su un dispositivo che supporta l'API CHRE v1.3, e il dispositivo è stato aggiornato per supportare l'API CHRE v1.4, la stessa nanoapp il codice binario continua a funzionare. Allo stesso modo, nanoapp può essere eseguita sull'API CHRE v1.2, e può determinare in fase di runtime se richiede funzionalità dall'API v1.3 a a raggiungere il suo utilizzo o se sia in grado di funzionare, potenzialmente con la degradazione delle caratteristiche.

Nuove versioni dell'API CHRE vengono rilasciate insieme ad Android, ma come CHRE dell'implementazione fa parte l'implementazione da parte del fornitore, la versione dell'API CHRE supportata su un dispositivo non è necessariamente collegata a un Versione di Android.

Riepilogo versioni

Ad esempio 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 vengono incrementate 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 patch specifica della piattaforma chreGetVersion(), che indica quando vengono apportati correzioni di bug o aggiornamenti di minore entità in l'implementazione.

Versione 1.0 (Android 7)

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

Versione 1.1 (Android 8)

Introduce le funzionalità di localizzazione tramite la posizione GNSS e le misurazioni non elaborate. Ricerca di reti Wi-Fi e informazioni sulle reti mobili, insieme a perfezionamenti generali per consentire la comunicazione da nanoapp a nanoapp e altri miglioramenti.

Versione 1.2 (Android 9)

Aggiunge il supporto dei dati provenienti da un microfono a basso consumo, RTT Wi-Fi, AP notifiche di sonno e risveglio e altri miglioramenti.

Versione 1.3 (Android 10)

Migliora le funzionalità relative ai dati di calibrazione dei sensori, aggiunge il supporto per lo flushing dei dati dei sensori in batch, 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)

Aggiunge il supporto per le informazioni della cella 5G, il dump di debug nanoapp e altro miglioramenti.

Funzionalità di sistema obbligatorie

Le fonti degli indicatori di contesto, ad esempio i sensori, sono classificate in facoltativi caratteristiche, sono necessarie alcune funzioni fondamentali in tutti i progetti CHRE implementazioni. Sono incluse le API di sistema di base, come quelle per impostare timer, l'invio e la ricezione di messaggi ai client sul processore delle applicazioni, logging e altri. Per i dettagli completi, consulta Intestazioni API.

Oltre alle funzionalità principali del sistema codificate nell'API CHRE, esistono anche funzionalità obbligatorie a livello di sistema CHRE specificate a livello dell'HAL di hub di contesto. La la più significativa è la capacità di caricare e unload in modo dinamico nanoapp.

libreria standard C/C++

Per ridurre al minimo l'utilizzo della memoria e la complessità del sistema, le implementazioni CHRE necessario per supportare solo un sottoinsieme delle librerie C e C++ standard e di linguaggio naturale che richiedono il supporto del runtime. In base a questi principi, alcune le funzionalità vengono escluse esplicitamente a causa della memoria e dell'esteso livello di sistema operativo di dipendenze e altre, perché sono soppiantate da dipendenze specifiche di CHRE. Questo non è un elenco esaustivo, ma quanto segue funzionalità non sono pensate per essere rese disponibili alle nanoapp:

  • Eccezioni C++ e informazioni sul tipo di runtime (RTTI)
  • Supporto del multithreading delle librerie standard, incluse le intestazioni C++11 <thread>, <mutex>, <atomic> e <future>
  • Librerie di input/output standard C e C++
  • Standard Template Library (STL) C++
  • Libreria espressioni regolari standard C++
  • Allocazione dinamica della memoria tramite funzioni standard (ad esempio, malloc, calloc, realloc, free, operator new) e altri standard di funzioni libreria che usano 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, tra cui system e getenv
  • POSIX e altre librerie non incluse nel linguaggio C99 o C++11 standard

In molti casi, le funzioni dell'API CHRE hanno a disposizione capacità equivalenti. e librerie di utilità. Ad esempio, è possibile utilizzare chreLog per il logging di debug indirizzata al sistema logcat di Android, dove un programma più tradizionale potrebbe usa printf o std::cout.

Al contrario, alcune funzionalità delle librerie standard sono necessarie. Tocca al della piattaforma per esporli tramite librerie statiche per l'inclusione in un file binario nanoapp o tramite collegamento dinamico tra nanoapp e il sistema. Questo include, a titolo esemplificativo:

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

  • Libreria matematica: funzioni in virgola mobile a precisione singola comunemente utilizzate:

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

Mentre alcune piattaforme sottostanti supportano funzionalità aggiuntive, una nanoapp non è considerata portabile nelle implementazioni CHRE a meno che non limiti la sua dipendenze esterne alle funzioni dell'API CHRE e alla libreria standard approvata funzioni.

Funzionalità facoltative

Per promuovere hardware e software, l'API CHRE è divisa in aree di funzionalità, considerati facoltativi dal punto di vista delle API. Anche se queste funzionalità potrebbero non essere necessarie per supportare un'implementazione CHRE compatibile, richiesta 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 creare e caricarle.

Sensori

L'API CHRE consente di richiedere dati dai sensori, tra cui accelerometro, giroscopio, magnetometro, sensore di luce ambientale e di prossimità. Queste API hanno lo scopo di fornire un insieme di funzionalità simili ai sensori Android API, compreso il supporto per il recupero in batch di campioni dei sensori al fine di ridurre il consumo energetico. L'elaborazione dei dati dei sensori all'interno di CHRE consente una riduzione dell'alimentazione e una latenza minore l'elaborazione dei segnali di movimento rispetto alla corsa sull'AP.

GNSS

CHRE fornisce API per richiedere dati sulla posizione da una navigazione globale sistema satellitare (GNSS), inclusi GPS e altre costellazioni satellitari. Questo include richieste di correzioni periodiche della posizione, nonché dati di misurazione non elaborati, sebbene entrambe siano capacità indipendenti. Poiché CHRE ha un collegamento diretto al GNSS, sottosistema, la potenza è ridotta rispetto alle richieste GNSS basate sulla AP, perché l'AP possono rimanere addormentati durante l'intero ciclo di vita di una sessione di localizzazione.

Wi-Fi

CHRE offre la possibilità di interagire con il chip Wi-Fi, principalmente per la localizzazione. Sebbene GNSS sia adatto anche in ambienti esterni, i risultati di Le ricerche di reti Wi-Fi possono fornire informazioni precise sulla posizione al chiuso e in ambienti sviluppati in queste aree. Oltre a evitare il costo di riattivare l'AP per una scansione, CHRE può ascoltare i risultati delle ricerche di reti Wi-Fi eseguite dalla rete Wi-Fi il firmware per la connettività, che in genere non viene fornito all'AP per motivi di alimentazione. L'utilizzo delle scansioni di connettività per scopi contestuali aiuta per ridurre il numero totale di ricerche di reti Wi-Fi eseguite, risparmiando energia.

Nell'API CHRE v1.1 è stato aggiunto il supporto per il Wi-Fi, inclusa la possibilità di monitorare analizza i risultati e attiva le scansioni on demand. Queste funzionalità sono state estese v1.2 con la possibilità di eseguire Tempo di round trip (RTT) di misurazione rispetto ai punti di accesso che supportano la funzionalità, il che consente una determinazione più accurata della posizione relativa.

WWAN

L'API CHRE consente di recuperare le informazioni di identificazione delle cellule della cella in cui si trova la cella e delle sue vicinanze, che in genere viene utilizzata a scopi di localizzazione approssimativa.

Audio

CHRE è in grado di elaborare batch di dati audio da un microfono a bassa potenza, di solito sfrutta l'hardware usato per implementare SoundTrigger HAL. In fase di elaborazione I dati audio in CHRE possono essere uniti ad altri dati, come il movimento i sensori.

Implementazione dei riferimenti

Il codice di riferimento per il framework CHRE è incluso in AOSP in system/chre implementato in C++11. Sebbene non sia strettamente obbligatorio, è consigliato per tutte le implementazioni CHRE siano basate su questo codebase, per garantire coerenza e accelerare l'adozione di nuove capacità. Questo codice può essere visto analogico al framework di base Android in quanto si tratta di un sistema delle API utilizzate dalle app, fungendo da base e standard per verificare la compatibilità. Sebbene possa essere personalizzata ed estesa di sicurezza, il consiglio è di mantenere il codice comune il più vicino possibile riferimento possibile. Analogamente agli HAL di Android, il riferimento CHRE utilizza varie astrazioni di piattaforma per consentirne l'adattamento su qualsiasi dispositivo che soddisfi i requisiti minimi.

Per i dettagli tecnici e una guida al trasferimento, consulta la README incluso nel progetto system/chre.