Smartphones enthalten mehrere Prozessoren, die jeweils für die Ausführung verschiedener Aufgaben optimiert sind. Android läuft jedoch nur auf einem Prozessor: dem Anwendungsprozessor (AP). Der AP ist für eine hervorragende Leistung bei eingeschaltetem Display optimiert, z. B. beim Gaming. Er ist jedoch zu energiehungrig, um Funktionen zu unterstützen, die ständig häufige, kurze Verarbeitungsspitzen erfordern, auch wenn das Display ausgeschaltet ist. Kleinere Prozessoren können diese Arbeitslasten effizienter bewältigen und ihre Aufgaben erledigen, ohne die Akkulaufzeit merklich zu beeinträchtigen. Die Softwareumgebungen in diesen Energiesparprozessoren sind jedoch eingeschränkter und können stark variieren, was die plattformübergreifende Entwicklung erschwert.
Die Context Hub Runtime Environment (CHRE) bietet eine gemeinsame Plattform zum Ausführen von Apps auf einem leistungseffizienten Prozessor mit einer einfachen, standardisierten, eingebetteten API. Mit CHRE können Gerätehersteller und ihre vertrauenswürdigen Partner die Verarbeitung ganz einfach vom ZP auslagern, um den Akku zu schonen, verschiedene Bereiche der Nutzererfahrung zu verbessern und eine Reihe von immer aktiven, kontextsensitiven Funktionen zu ermöglichen, insbesondere solche, bei denen maschinelles Lernen auf die Umgebungserkennung angewendet wird.
Schlüsselkonzepte
CHRE ist die Softwareumgebung, in der kleine native Apps, sogenannte Nano-Apps, auf einem leistungseffizienten Prozessor ausgeführt werden und über die gemeinsame CHRE API mit dem zugrunde liegenden System interagieren. Um die korrekte Implementierung der CHRE APIs zu beschleunigen, ist in AOSP eine plattformübergreifende Referenzimplementierung der CHRE enthalten. Die Referenzimplementierung umfasst gemeinsamen Code und Abstraktionsschichten für die zugrunde liegende Hardware und Software über eine Reihe von Plattformabstraktionsschichten (PALs). Nano-Apps sind fast immer mit einer oder mehreren Client-Apps verknüpft, die unter Android ausgeführt werden und über System-APIs mit eingeschränktem Zugriff ContextHubManager mit CHRE und Nano-Apps interagieren.
Im Großen und Ganzen lassen sich Parallelen zwischen der Architektur von CHRE und Android insgesamt ziehen. Es gibt jedoch einige wichtige Unterschiede:
- CHRE unterstützt nur das Ausführen von Nano-Apps, die in nativem Code (C oder C++) entwickelt wurden. Java wird nicht unterstützt.
- Aufgrund von Ressourcenbeschränkungen und Sicherheitseinschränkungen kann CHRE nicht von beliebigen Android-Apps von Drittanbietern verwendet werden. Nur vom System als vertrauenswürdig eingestufte Apps können darauf zugreifen.
Außerdem ist es wichtig, zwischen dem Konzept des CHRE und einem Sensorhub zu unterscheiden. Es ist zwar üblich, dieselbe Hardware für die Implementierung des Sensorhubs und des CHRE zu verwenden, aber das CHRE selbst bietet nicht die Sensorfunktionen, die von der Android Sensors HAL benötigt werden. CHRE ist mit der Context Hub HAL verknüpft und fungiert als Client eines gerätespezifischen Sensor-Frameworks, um Sensordaten zu empfangen, ohne den AP einzubinden.
Abbildung 1: CHRE-Framework-Architektur
Context Hub HAL
Die Context Hub Hardware Abstraction Layer (HAL) ist die Schnittstelle zwischen dem Android-Framework und der CHRE-Implementierung des Geräts, die unter hardware/interfaces/contexthub definiert ist.
Die Context Hub HAL definiert die APIs, über die das Android-Framework verfügbare Context Hubs und ihre Nano-Apps erkennt, über die Nachrichtenweitergabe mit diesen Nano-Apps interagiert und das Laden und Entladen von Nano-Apps ermöglicht. Eine Referenzimplementierung der Context Hub HAL, die mit der Referenzimplementierung der CHRE funktioniert, ist unter system/chre/host verfügbar.
Im Falle eines Konflikts zwischen dieser Dokumentation und der HAL-Definition hat die HAL-Definition Vorrang.
Initialisierung
Beim Starten von Android ruft der ContextHubService die HAL-Funktion getHubs() auf, um zu prüfen, ob auf dem Gerät Kontexthubs verfügbar sind. Dies ist ein blockierender einmaliger Aufruf, der schnell abgeschlossen werden muss, um Verzögerungen beim Starten zu vermeiden. Außerdem muss ein korrektes Ergebnis zurückgegeben werden, da danach keine neuen Kontexthubs eingeführt werden können.
Nano-Apps laden und entladen
Ein Kontext-Hub kann eine Reihe von Nano-Apps enthalten, die im Geräte-Image enthalten sind und beim Start des CHRE geladen werden. Diese werden als vorinstallierte Nano-Apps bezeichnet und sollten in der ersten Antwort auf queryApps() enthalten sein.
Die Context Hub HAL unterstützt auch das dynamische Laden und Entladen von Nano-Apps zur Laufzeit über die Funktionen loadNanoApp() und unloadNanoApp(). Nano-Apps werden der HAL in einem Binärformat zur Verfügung gestellt, das spezifisch für die CHRE-Hardware und ‑Softwareimplementierung des Geräts ist.
Wenn die Implementierung zum Laden einer Nano-App das Schreiben in nichtflüchtigen Arbeitsspeicher erfordert, z. B. in Flash-Speicher, der an den Prozessor angeschlossen ist, auf dem CHRE ausgeführt wird, muss die CHRE-Implementierung immer mit diesen dynamischen Nano-Apps im deaktivierten Zustand gestartet werden. Das bedeutet, dass kein Code der Nano-App ausgeführt wird, bis eine enableNanoapp()-Anfrage über die HAL empfangen wird. Vorab geladene Nano-Apps können im aktivierten Status initialisiert werden.
Context Hub wird neu gestartet
Normalerweise wird die CHRE während des normalen Betriebs nicht neu gestartet. Es kann jedoch erforderlich sein, sie nach unerwarteten Vorfällen wie dem Zugriff auf eine nicht zugeordnete Speicheradresse wiederherzustellen. In diesen Fällen wird die CHRE unabhängig von Android neu gestartet. Die HAL benachrichtigt Android darüber über das Ereignis RESTARTED, das erst gesendet werden darf, nachdem die CHRE so neu initialisiert wurde, dass sie neue Anfragen wie queryApps() akzeptieren kann.
CHRE-Systemübersicht
CHRE basiert auf einer ereignisgesteuerten Architektur, bei der die primäre Recheneinheit ein Ereignis ist, das an den Einstiegspunkt der Ereignisbehandlung einer Nano-App übergeben wird. Das CHRE-Framework kann zwar mehrstufig sein, aber eine bestimmte Nano-App wird nie parallel in mehreren Threads ausgeführt. Das CHRE-Framework interagiert über einen der drei Nano-App-Einstiegspunkte (nanoappStart(), nanoappHandleEvent() und nanoappEnd()) oder über einen Callback, der in einem vorherigen CHRE API-Aufruf bereitgestellt wurde, mit einer bestimmten Nano-App. Nano-Apps interagieren über die CHRE API mit dem CHRE-Framework und dem zugrunde liegenden System. Die CHRE API bietet eine Reihe grundlegender Funktionen sowie Funktionen für den Zugriff auf kontextbezogene Signale, einschließlich Sensoren, GNSS, WLAN, WWAN und Audio. Sie kann mit zusätzlichen anbieterspezifischen Funktionen für die Verwendung durch anbieterspezifische Nano-Apps erweitert werden.
Build-System
Während die Context Hub HAL und andere erforderliche AP-Seiten-Komponenten zusammen mit Android erstellt werden, kann Code, der im CHRE ausgeführt wird, Anforderungen haben, die ihn mit dem Android-Build-System inkompatibel machen, z. B. die Notwendigkeit einer speziellen Toolchain. Daher bietet das CHRE-Projekt in AOSP ein vereinfachtes Buildsystem auf der Grundlage von GNU Make zum Kompilieren von Nano-Apps und optional des CHRE-Frameworks in Bibliotheken, die in das System eingebunden werden können. Gerätehersteller, die CHRE unterstützen, sollten die Build-Systemunterstützung für ihre Zielgeräte in AOSP einbinden.
Die CHRE API wird gemäß dem C99-Sprachstandard geschrieben. Die Referenzimplementierung verwendet eine eingeschränkte Untermenge von C++11, die für ressourcenbeschränkte Apps geeignet ist.
CHRE API
Die CHRE API ist eine Sammlung von C-Headerdateien, die die Softwareschnittstelle zwischen einer Nano-App und dem System definieren. Es soll den Code von Nano-Apps für alle Geräte kompatibel machen, die CHRE unterstützen. Das bedeutet, dass der Quellcode einer Nano-App nicht für die Unterstützung eines neuen Gerätetyps geändert werden muss. Er muss jedoch möglicherweise speziell für den Prozessorbefehlssatz oder die Anwendungs-Binärschnittstelle (Application Binary Interface, ABI) des Zielgeräts neu kompiliert werden. Die CHRE-Architektur und das API-Design sorgen außerdem dafür, dass Nano-Apps binärkompatibel mit verschiedenen Versionen der CHRE API sind. Das bedeutet, dass eine Nano-App nicht neu kompiliert werden muss, um auf einem System ausgeführt zu werden, das eine andere Version der CHRE API implementiert als die Ziel-API, gegen die die Nano-App kompiliert wird. Wenn also eine Nano-App-Binärdatei auf einem Gerät ausgeführt wird, das die CHRE API v1.3 unterstützt, und dieses Gerät auf die CHRE API v1.4 aktualisiert wird, funktioniert dieselbe Nano-App-Binärdatei weiterhin. Ebenso kann die Nano-App mit der CHRE API v1.2 ausgeführt werden und bei der Laufzeit feststellen, ob für die Nutzung Funktionen aus der API v1.3 erforderlich sind oder ob sie möglicherweise mit einer schrittweisen Funktionsbeeinträchtigung ausgeführt werden kann.
Neue Versionen der CHRE API werden zusammen mit Android veröffentlicht. Da die CHRE-Implementierung jedoch Teil der Implementierung des Anbieters ist, ist die auf einem Gerät unterstützte CHRE API-Version nicht unbedingt mit einer Android-Version verknüpft.
Versionsübersicht
Wie das Android HIDL-Versionierungsschema folgt die CHRE API dem semantischen Versionierungsschema.
Die Hauptversion gibt die Binärkompatibilität an, während die Nebenversion erhöht wird, wenn abwärtskompatible Funktionen eingeführt werden. Die CHRE API enthält Quellcode-Anmerkungen, mit denen angegeben wird, in welcher Version eine Funktion oder ein Parameter eingeführt wurde, z. B. @since v1.1.
Die CHRE-Implementierung stellt über chreGetVersion() auch eine plattformspezifische Patchversion bereit, die angibt, wann Fehlerkorrekturen oder kleinere Updates in der Implementierung vorgenommen wurden.
Version 1.0 (Android 7)
Enthält Unterstützung für Sensoren und grundlegende Nano-App-Funktionen wie Ereignisse und Timer.
Version 1.1 (Android 8)
Standortfunktionen über GNSS-Standort und Rohmessungen, WLAN-Scans und Informationen zu Mobilfunknetzen sowie allgemeine Optimierungen zur Nano-App-zu-Nano-App-Kommunikation und weitere Verbesserungen.
Version 1.2 (Android 9)
Es werden Daten von einem energieeffizienten Mikrofon, WLAN-RTT-Messungen, Benachrichtigungen zum Aktivieren und Deaktivieren von ZPs sowie weitere Verbesserungen unterstützt.
Version 1.3 (Android 10)
Die Funktionen im Zusammenhang mit Sensorkalibrierungsdaten wurden verbessert. Außerdem wird jetzt unterstützt, dass gebatchte Sensordaten auf Anfrage gelöscht werden. Außerdem wird der Sensortyp für die Schritterkennung definiert und GNSS-Standortereignisse werden um zusätzliche Felder für die Genauigkeit erweitert.
Version 1.4 (Android 11)
Es wurde Unterstützung für Informationen zu 5G-Basisstationen, Nano-App-Debug-Dumps und andere Verbesserungen hinzugefügt.
Erforderliche Systemfunktionen
Quellen für kontextbezogene Signale wie Sensoren werden in optionale Funktionsbereiche kategorisiert. Für alle CHRE-Implementierungen sind jedoch einige Kernfunktionen erforderlich. Dazu gehören auch die wichtigsten System-APIs, z. B. zum Festlegen von Timern, zum Senden und Empfangen von Nachrichten an Clients auf dem Anwendungsprozessor und zum Logging. Weitere Informationen finden Sie unter API-Header.
Zusätzlich zu den in der CHRE API codierten Hauptsystemfunktionen gibt es auch obligatorische CHRE-Funktionen auf Systemebene, die auf HAL-Ebene des Context Hubs angegeben sind. Die wichtigste davon ist die Möglichkeit, Nano-Apps dynamisch zu laden und zu entladen.
C/C++-Standardbibliothek
Um die Speichernutzung und die Systemkomplexität zu minimieren, müssen CHRE-Implementierungen nur einen Teil der Standard-C- und C++-Bibliotheken und Sprachfunktionen unterstützen, die Laufzeitunterstützung erfordern. Gemäß diesen Prinzipien sind einige Funktionen aufgrund ihrer Speicher- und umfangreichen Abhängigkeiten auf Betriebssystemebene ausdrücklich ausgeschlossen. Andere werden durch geeignetere CHRE-spezifische APIs ersetzt. Die folgende Liste ist nicht vollständig. Die folgenden Funktionen sind jedoch nicht für Nano-Apps vorgesehen:
- C++-Ausnahmen und Laufzeittypinformationen (RTTI)
- Unterstützung für Multithreading in der Standardbibliothek, einschließlich C++11-Headern
<thread>,<mutex>,<atomic>,<future> - C- und C++-Standard-Eingabe/-Ausgabebibliotheken
- C++ Standard Template Library (STL)
- C++-Standardbibliothek für reguläre Ausdrücke
- Dynamische Arbeitsspeicherzuweisung über Standardfunktionen (z. B.
malloc,calloc,realloc,free,operator new) und andere Standardbibliotheksfunktionen, die standardmäßig eine dynamische Zuweisung verwenden, z. B.std::unique_ptr - Unterstützung für Lokalisierung und Unicode-Zeichen
- Datums- und Uhrzeitbibliotheken
- Funktionen, die den normalen Programmablauf ändern, einschließlich
<setjmp.h>,<signal.h>,abortundstd::terminate - Zugriff auf die Hostumgebung, einschließlich
system,getenv - POSIX und andere Bibliotheken, die nicht in den Sprachstandards C99 oder C++11 enthalten sind
In vielen Fällen sind entsprechende Funktionen über CHRE API-Funktionen und Dienstprogrammbibliotheken verfügbar. chreLog kann beispielsweise für das Debug-Logging verwendet werden, das auf das Android-Logcat-System ausgerichtet ist. Ein traditionelleres Programm verwendet dagegen möglicherweise printf oder std::cout.
Einige Funktionen der Standardbibliothek sind dagegen erforderlich. Die Plattformimplementierung muss diese über statische Bibliotheken für die Aufnahme in eine Nano-App-Binärdatei oder über eine dynamische Verknüpfung zwischen der Nano-App und dem System bereitstellen. Dazu zählt unter anderem Folgendes:
- String- und Array-Dienstprogramme:
memcmp,memcpy,memmove,memset,strlen Math-Bibliothek: Häufig verwendete Gleitkommafunktionen mit einfacher Genauigkeit:
- Grundlegende Vorgänge:
ceilf,fabsf,floorf,fmaxf,fminf,fmodf,roundf,lroundf,remainderf - Exponential- und Potenzfunktionen:
expf,log2f,powf,sqrtf - Trigonometrische und hyperbolische Funktionen:
sinf,cosf,tanf,asinf,acosf,atan2f,tanhf
- Grundlegende Vorgänge:
Einige zugrunde liegende Plattformen unterstützen zusätzliche Funktionen. Eine Nano-App gilt jedoch nur dann als plattformübergreifend portabel, wenn sie ihre externen Abhängigkeiten auf CHRE API-Funktionen und genehmigte Standardbibliotheksfunktionen beschränkt.
Optionale Funktionen
Zur Bewerbung von Hardware und Software ist die CHRE API in Funktionsbereiche unterteilt, die aus API-Sicht als optional gelten. Diese Funktionen sind zwar möglicherweise nicht erforderlich, um eine kompatible CHRE-Implementierung zu unterstützen, aber möglicherweise für die Unterstützung einer bestimmten Nano-App. Auch wenn eine Plattform eine bestimmte Gruppe von APIs nicht unterstützt, müssen Nano-Apps, die auf diese Funktionen verweisen, erstellt und geladen werden können.
Sensoren
Mit der CHRE API können Daten von Sensoren angefordert werden, darunter Beschleunigungsmesser, Gyroskop, Magnetometer, Umgebungslichtsensor und Näherungssensor. Diese APIs sollen ein ähnliches Funktionspaket wie die Android-Sensor-APIs bieten, einschließlich der Unterstützung für Batch-Sensor-Samples zur Reduzierung des Energieverbrauchs. Die Verarbeitung von Sensordaten innerhalb des CHRE ermöglicht eine deutlich geringere Leistungsaufnahme und eine geringere Latenz bei der Verarbeitung von Bewegungssignalen als bei der Ausführung auf dem ZP.
GNSS
CHRE stellt APIs für die Abfrage von Standortdaten aus einem globalen Navigationssatellitensystem (GNSS) bereit, einschließlich GPS und anderer Satellitenkonstellationen. Dazu gehören Anfragen für regelmäßige Standortermittlungen sowie Rohmessdaten. Beides sind unabhängige Funktionen. Da CHRE eine direkte Verbindung zum GNSS-Subsystem hat, wird der Stromverbrauch im Vergleich zu AP-basierten GNSS-Anfragen reduziert, da der AP während des gesamten Lebenszyklus einer Standortsitzung inaktiv bleiben kann.
WLAN
CHRE bietet die Möglichkeit, mit dem WLAN-Chip zu interagieren, hauptsächlich zu Standortzwecken. GNSS funktioniert gut für Standorte im Freien. Die Ergebnisse von WLAN-Scans können jedoch in Innenräumen und in bebauten Gebieten genaue Standortinformationen liefern. Neben den Kosten, die durch das Aufwecken des ZP für einen Scan entstehen, kann die CHRE die Ergebnisse von WLAN-Scans abhören, die von der WLAN-Firmware zu Verbindungszwecken ausgeführt werden und aus Gründen der Energieeffizienz in der Regel nicht an den ZP gesendet werden. Wenn Sie Konnektivitätsscans für kontextbezogene Zwecke nutzen, lässt sich die Gesamtzahl der durchgeführten WLAN-Scans reduzieren und so Strom sparen.
In der CHRE API v1.1 wurde die Unterstützung für WLAN hinzugefügt, einschließlich der Möglichkeit, Scanergebnisse zu überwachen und Scans bei Bedarf auszulösen. In Version 1.2 wurden diese Funktionen um die Möglichkeit erweitert, Umlaufzeiten (Round-Trip Time, RTT) an WLAN-Zugangspunkten zu messen, die die Funktion unterstützen. So kann die relative Position genau bestimmt werden.
WWAN
Mit der CHRE API können Sie Informationen zur Zellenidentifikation für die anfragende Zelle und ihre benachbarten Zellen abrufen. Diese werden in der Regel für grobe Standortzwecke verwendet.
Audio
CHRE kann Audiodaten-Batches von einem energieeffizienten Mikrofon verarbeiten, das in der Regel die Hardware nutzt, die für die Implementierung der SoundTrigger HAL verwendet wird. Wenn Sie Audiodaten in CHRE verarbeiten, können sie mit anderen Daten wie Bewegungssensoren zusammengeführt werden.
Referenzimplementierung
Der Referenzcode für das CHRE-Framework ist im AOSP im Projekt system/chre enthalten und in C++11 implementiert. Es ist zwar nicht unbedingt erforderlich, aber es wird empfohlen, dass alle CHRE-Implementierungen auf dieser Codebasis basieren, um für Einheitlichkeit zu sorgen und die Einführung neuer Funktionen zu beschleunigen. Dieser Code kann als Analogon zum Android-Kern-Framework betrachtet werden, da es sich um eine Open-Source-Implementierung von APIs handelt, die von Apps verwendet werden und als Baseline und Standard für die Kompatibilität dienen. Er kann zwar mit anbieterspezifischen Funktionen angepasst und erweitert werden, es wird jedoch empfohlen, den gemeinsamen Code so nah wie möglich an der Referenz zu halten. Ähnlich wie bei den HALs von Android verwendet die CHRE-Referenzimplementierung verschiedene Plattformabstraktionen, damit sie an jedes Gerät angepasst werden kann, das die Mindestanforderungen erfüllt.
Technische Details und eine Anleitung zur Portierung finden Sie in der README-Datei im system/chre-Projekt.