Contesto Hub Runtime Environment (CHRE)

Gli smartphone contengono un numero 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 affamato di energia per supportare funzionalità che richiedono frequenti e brevi raffiche di elaborazione tutto il tempo, anche quando lo schermo è spento. I processori più piccoli sono in grado di gestire questi carichi di lavoro in modo più efficiente, completando le loro attività senza influire 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 di facile utilizzo. CHRE consente agli OEM di dispositivi e ai loro partner di fiducia di scaricare facilmente l'elaborazione dall'AP, risparmiare batteria e migliorare varie aree dell'esperienza utente e abilitare una classe di funzionalità sempre attive e contestualmente consapevoli, in particolare quelle che coinvolgono l'applicazione della macchina apprendimento al rilevamento ambientale.

Concetti chiave

CHRE è l'ambiente software in cui piccole applicazioni native, chiamati nanoapps, eseguono su un processore a basso consumo e interagiscono con il sistema sottostante attraverso l'API CHRE comune. 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). Nanoapps sono quasi sempre legati a una o più applicazioni client in esecuzione in Android, che interagiscono con CHRE e nanoapps attraverso ad accesso limitato ContextHubManager API di sistema.

Ad alto livello, è possibile tracciare parallelismi tra l'architettura di CHRE e Android nel suo insieme. Tuttavia, ci sono 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 è aperto per l'utilizzo da parte di app Android di terze parti arbitrarie. Solo le app affidabili del sistema possono accedervi.

C'è anche un'importante distinzione da fare tra il concetto di CHRE e un hub di sensori. Mentre è comune utilizzare lo stesso hardware per implementare il mozzo sensore e CHRE, CHRE sé non fornisce la funzionalità sensore richiesto dal Android sensori HAL . CHRE è legato al Context Hub HAL e agisce come client di un framework di sensori specifico del dispositivo per ricevere i dati del sensore senza coinvolgere l'AP.

Architettura del framework CHRE

Architettura quadro Figura 1. CHRE

Contesto Hub HAL

L'hub livello di astrazione hardware Context (HAL) è l'interfaccia tra il quadro Android e attuazione CHRE del dispositivo, definito a hardware/interfaces/contexthub . L'HAL dell'hub di contesto definisce le API attraverso le quali il framework Android rileva gli hub di contesto disponibili e le relative nanoapp, interagisce con tali nanoapp tramite il passaggio di messaggi e consente il caricamento e lo scaricamento delle nanoapp. Un'implementazione di riferimento del Contesto Hub HAL che funziona con l'implementazione di riferimento di CHRE è disponibile al system/chre/host .

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

Inizializzazione

All'avvio Android up, il ContextHubService richiama il getHubs() funzione HAL per determinare se qualsiasi hub contesto sono disponibili sul dispositivo. Questa è una chiamata di blocco, una tantum, quindi deve essere completata rapidamente per evitare di ritardare l'avvio e deve restituire un risultato accurato, poiché in seguito non è possibile introdurre nuovi hub di contesto.

Caricare e scaricare nanoapp

Un hub di contesto può includere un set di nanoapp incluse nell'immagine del dispositivo e caricate all'avvio di CHRE. Questi sono noti come nanoapps precaricati, e dovrebbero essere inclusi nella prima risposta possibile queryApps() .

Il contesto Hub HAL supporta anche carico e scarico nanoapps dinamicamente in fase di esecuzione, attraverso il loadNanoApp() e unloadNanoApp() funzioni. 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 implica la scrittura su una memoria non volatile, come la memoria flash collegata al processore che esegue CHRE, l'implementazione di CHRE deve sempre avviarsi con queste nanoapp dinamiche nello stato disabilitato. Ciò significa che nessuno di codice del nanoapp viene eseguito fino a quando un enableNanoapp() richiesta è pervenuta attraverso l'HAL. Le nanoapp precaricate possono essere inizializzate nello stato abilitato.

L'hub di contesto si riavvia

Sebbene non sia previsto che CHRE si riavvii durante il normale funzionamento, può essere necessario eseguire 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 Notifica Android di questa attraverso il RESTARTED evento, che deve inviare solo dopo CHRE è stato reinizializzato al punto che si può accettare nuove richieste, come ad esempio queryApps() .

Panoramica del sistema CHRE

CHRE è progettato attorno a un'architettura guidata dagli eventi, in cui l'unità di calcolo primaria è un evento passato al punto di ingresso per la 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. Interagisce quadro CHRE con una data nanoapp attraverso uno dei tre punti di ingresso nanoapp ( nanoappStart() , nanoappHandleEvent() , e nanoappEnd() ) o attraverso un callback fornita in una chiamata CHRE API prima e nanoapps interagiscono con il quadro 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 .

Sistema di costruzione

Sebbene l'HAL di Context Hub e altri componenti necessari sul lato AP siano costruiti 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 una toolchain specializzata. Pertanto, il progetto CHRE in AOSP fornisce un sistema di compilazione semplificato basato su GNU Make per compilare nanoapp e, opzionalmente, 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 limitato di C++ 11 adatto per 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 essere necessario ricompilare specificamente per il processore del dispositivo di destinazione set di istruzioni o interfaccia binaria dell'applicazione (ABI). L'architettura CHRE e il design dell'API assicurano 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 su cui è compilata la nanoapp. In altre parole, se un binario nanoapp viene eseguito su un dispositivo che supporta l'API CHRE v1.3 e quel 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à dall'API v1.3 per ottenere la sua funzionalità o se può funzionare, potenzialmente con un discreto degrado delle funzionalità.

Nuove versioni di API CHRE vengono rilasciati fianco Android, tuttavia, come l'implementazione CHRE è parte della attuazione fornitore , la versione CHRE API supportato su un dispositivo non è necessariamente collegata a una versione Android.

Riepilogo versione

Come il sistema di versioning HIDL Android , l'API CHRE segue delle versioni 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 comprende annotazioni codice sorgente per identificare la versione introdotta una funzione o parametro, ad esempio @since v1.1 .

L'implementazione CHRE espone anche una versione della piattaforma-specifici di patch attraverso chreGetVersion() , che indica quando correzioni di bug o aggiornamenti minori sono realizzati nell'attuazione.

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 le funzionalità di localizzazione attraverso la posizione GNSS e le misurazioni grezze, la scansione Wi-Fi e le 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 bassa potenza, la gamma RTT Wi-Fi, le notifiche di attivazione/disattivazione dell'AP e altri miglioramenti.

Versione 1.3 (Android 10)

Migliora le funzionalità relative ai dati di calibrazione del sensore, aggiunge il supporto per il lavaggio dei dati del sensore in batch su richiesta, definisce il tipo di sensore di rilevamento del passo ed estende gli eventi di posizione GNSS con campi di precisione aggiuntivi.

Versione 1.4 (Android 11)

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

Funzionalità di sistema obbligatorie

Sebbene le fonti di segnali contestuali, come i sensori, siano classificate in aree di funzionalità opzionali, sono necessarie alcune funzioni principali in tutte le implementazioni CHRE. 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 tutti i dettagli, vedere le intestazioni API .

Oltre alle funzionalità di base del sistema codificate nell'API CHRE, esistono anche funzionalità obbligatorie a livello di sistema CHRE specificate a livello HAL di Context Hub. 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 standard C e C++ e delle funzionalità del linguaggio che richiedono il supporto runtime. Seguendo questi principi, alcune funzionalità sono esplicitamente escluse a causa della loro memoria e/o delle dipendenze estese a livello di sistema operativo, e altre perché sono soppiantate da API specifiche di CHRE più adatte. Sebbene non debbano essere 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)
  • Libreria standard supporto multithreading, tra cui C ++ 11 intestazioni <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 attraverso funzioni standard (per esempio, malloc , calloc , realloc , free , operator new ), e altre funzioni di libreria standard che utilizzano intrinsecamente allocazione dinamica, come std::unique_ptr
  • Localizzazione e supporto dei caratteri Unicode
  • Librerie di data e ora
  • Le funzioni che modificano il normale flusso del programma, tra cui <setjmp.h> , <signal.h> , abort , std::terminate
  • Accesso al ambiente host, tra cui system , getenv
  • POSIX e altre librerie non incluse negli standard del linguaggio C99 o C++11

In molti casi, la funzionalità equivalente è disponibile dalle funzioni API CHRE e/o dalle librerie di utilità. Ad esempio, chreLog può essere utilizzato per la registrazione di debug mirata al sistema logcat Android, in cui un programma più tradizionale potrebbe utilizzare printf o std::cout .

Al contrario, sono necessarie alcune funzionalità di libreria standard. Spetta all'implementazione della piattaforma esporli tramite librerie statiche per l'inclusione in un binario nanoapp o tramite collegamento dinamico tra nanoapp e sistema. Questo include, ma non è limitato a:

  • Stringa / utilità di matrice: memcmp , memcpy , memmove , memset , strlen
  • Libreria matematica: funzioni a virgola mobile a precisione singola comunemente usate:

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

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 dell'API CHRE e alle funzioni della libreria standard approvate.

Caratteristiche opzionali

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 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 inclusi 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 il batch di campioni di sensori per ridurre il consumo energetico. L'elaborazione dei dati del sensore all'interno di CHRE consente un'elaborazione dei segnali di movimento con una potenza e una latenza molto inferiori rispetto all'esecuzione sull'AP.

GNSS

CHRE fornisce API per la richiesta di dati sulla posizione da un sistema globale di navigazione satellitare (GNSS), inclusi GPS e altre costellazioni di satelliti. Ciò include le richieste di correzioni periodiche della posizione, nonché i 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 su 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 esterne, 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 le scansioni su richiesta. Queste funzionalità sono state estese in v1.2 con la possibilità di eseguire Time (RTT) andata e ritorno misure contro i punti di accesso che supportano la funzione, che consente la determinazione esatta posizione relativa.

WWAN

L'API CHRE offre la possibilità di recuperare le informazioni di identificazione della cella per la cella servente e le sue vicine, che viene generalmente utilizzata 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

Codice di riferimento per il quadro CHRE è incluso nella AOSP nel system/chre progetto, realizzato in C ++ 11. Sebbene non sia strettamente necessario, è consigliabile che tutte le implementazioni di CHRE si basino su questa base di codice, per garantire la coerenza e accelerare l'adozione di nuove funzionalità. Questo codice può essere visto come un analogo del 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. Simile 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 i dettagli tecnici e una guida porting, consultare il file README incluso nel system/chre progetto.