Context Hub-Laufzeitumgebung (CHRE)

Smartphones enthalten mehrere Prozessoren, die jeweils für unterschiedliche Aufgaben optimiert sind. Android wird jedoch nur auf einem Prozessor ausgeführt: dem Anwendungsprozessor (AP). Der AP ist darauf ausgelegt, eine hohe Leistung für Anwendungsfälle mit eingeschaltetem Bildschirm wie Gaming zu bieten. Er verbraucht jedoch zu viel Strom, um Funktionen zu unterstützen, die häufige, kurze Verarbeitungsspitzen erfordern, auch wenn der Bildschirm ausgeschaltet ist. Kleinere Prozessoren können diese Arbeitslasten effizienter verarbeiten und ihre Aufgaben erledigen, ohne die Akkulaufzeit merklich zu beeinträchtigen. Die Softwareumgebungen in diesen Prozessoren mit geringem Stromverbrauch 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 für die Ausführung von Apps auf einem Prozessor mit geringem Stromverbrauch und eine einfache, standardisierte, eingebettungsfreundliche API. Mit CHRE können Gerätehersteller und ihre vertrauenswürdigen Partner die Verarbeitung vom AP auslagern, um Akku zu sparen und verschiedene Bereiche der Nutzererfahrung zu verbessern. Außerdem können sie eine Klasse von Always-on-Funktionen mit Kontextbezug aktivieren, insbesondere solche, bei denen maschinelles Lernen auf die Umgebungserkennung angewendet wird.

Wichtige Konzepte

CHRE ist die Softwareumgebung, in der kleine native Apps, sogenannte Nanoapps, auf einem Prozessor mit geringem Stromverbrauch 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 von CHRE enthalten. Die Referenzimplementierung umfasst gemeinsamen Code und Abstraktionen für die zugrunde liegende Hardware und Software über eine Reihe von Plattformabstraktionsschichten (Platform Abstraction Layers, PALs). Nanoapps sind fast immer mit einer oder mehreren Client-Apps verknüpft, die unter Android ausgeführt werden und über ContextHubManager System-APIs mit eingeschränktem Zugriff mit CHRE und Nanoapps interagieren.

Auf hoher Ebene lassen sich Parallelen zwischen der Architektur von CHRE und Android insgesamt ziehen. Es gibt jedoch einige wichtige Unterschiede:

• CHRE unterstützt nur die Ausführung von Nanoapps, die in nativem Code (C oder C++) entwickelt wurden. Java wird nicht unterstützt.
• Aufgrund von Ressourcenbeschränkungen und Sicherheitsbeschränkungen kann CHRE nicht von beliebigen Android-Apps von Drittanbietern verwendet werden. Nur Apps, die vom System als vertrauenswürdig eingestuft werden, können darauf zugreifen.

Außerdem muss zwischen dem Konzept von CHRE und einem Sensor-Hub unterschieden werden. Obwohl es üblich ist, dieselbe Hardware zur Implementierung des Sensor-Hubs und von CHRE zu verwenden, bietet CHRE selbst 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 zu verwenden.

Abbildung 1 : CHRE-Framework-Architektur

Context Hub HAL

Die Hardwareabstraktionsschicht (Hardware Abstraction Layer, HAL) des Context Hub 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 Nanoapps erkennt, über die Nachrichtenübertragung mit diesen Nanoapps interagiert und das Laden und Entladen von Nanoapps ermöglicht. Eine Referenzimplementierung der Context Hub HAL, die mit der Referenzimplementierung von 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 getHubs() HAL-Funktion auf, um zu ermitteln, ob auf dem Gerät Context Hubs verfügbar sind. Dies ist ein blockierender, einmaliger Aufruf, der schnell abgeschlossen sein muss, um den Start nicht zu verzögern. Außerdem muss er ein genaues Ergebnis zurückgeben, da später keine neuen Context Hubs eingeführt werden können.

Nanoapps laden und entladen

Ein Context Hub kann eine Reihe von Nanoapps enthalten, die im Geräteimage enthalten sind und beim Starten von CHRE geladen werden. Diese werden als vorab geladene Nanoapps bezeichnet und sollten in der ersten möglichen Antwort auf queryApps() enthalten sein.

Die Context Hub HAL unterstützt auch das dynamische Laden und Entladen von Nanoapps zur Laufzeit über die loadNanoApp() und unloadNanoApp() Funktionen. Nanoapps werden der HAL in einem Binärformat bereitgestellt, das spezifisch für die CHRE-Hardware- und Softwareimplementierung des Geräts ist.

Wenn die Implementierung zum Laden einer Nanoapp das Schreiben in einen nichtflüchtigen Speicher umfasst, z. B. Flash-Speicher, der an den Prozessor angeschlossen ist, auf dem CHRE ausgeführt wird, muss die CHRE-Implementierung immer mit diesen dynamischen Nanoapps im deaktivierten Zustand gestartet werden. Das bedeutet, dass kein Code der Nanoapp ausgeführt wird, bis über die HAL eine enableNanoapp()-Anfrage empfangen wird. Vorab geladene Nanoapps können im aktivierten Zustand initialisiert werden.

Neustarts des Context Hub

Es wird nicht erwartet, dass CHRE während des normalen Betriebs neu gestartet wird. Es kann jedoch erforderlich sein, sich von unerwarteten Bedingungen zu erholen, z. B. von einem Versuch, auf eine nicht zugeordnete Speicheradresse zuzugreifen. In diesen Fällen wird CHRE unabhängig von Android neu gestartet. Die HAL benachrichtigt Android über das Ereignis RESTARTED. Dieses Ereignis darf erst gesendet werden, nachdem CHRE so weit neu initialisiert wurde, dass es neue Anfragen wie queryApps() annehmen kann.

CHRE-Systemübersicht

CHRE basiert auf einer ereignisgesteuerten Architektur, bei der die primäre Recheneinheit ein Ereignis ist, das an den Ereignis-Handler-Einstiegspunkt einer Nanoapp übergeben wird. Das CHRE-Framework kann zwar Multithreading unterstützen, aber eine bestimmte Nanoapp wird nie parallel von mehreren Threads ausgeführt. Das CHRE-Framework interagiert mit einer bestimmten Nanoapp über einen der drei Nanoapp-Einstiegspunkte (nanoappStart(), nanoappHandleEvent() und nanoappEnd()) oder über einen Callback, der in einem vorherigen CHRE API-Aufruf bereitgestellt wurde. Nanoapps interagieren über die CHRE API mit dem CHRE-Framework und dem zugrunde liegenden System. Die CHRE API bietet eine Reihe grundlegender Funktionen sowie Möglichkeiten 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 Nanoapps erweitert werden.

Build-System

Die Context Hub HAL und andere erforderliche AP-seitige Komponenten werden zusammen mit Android erstellt. Code, der in CHRE ausgeführt wird, kann jedoch 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 Build-System, das auf GNU Make basiert, um Nanoapps und optional das CHRE-Framework in Bibliotheken zu kompilieren, die in das System integriert werden können. Gerätehersteller, die CHRE unterstützen, sollten die Unterstützung des Build-Systems für ihre Zielgeräte in AOSP integrieren.

Die CHRE API ist gemäß dem C99-Sprachstandard geschrieben und die Referenzimplementierung verwendet eine eingeschränkte Teilmenge 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 Nanoapp und dem System definieren. Sie wurde entwickelt, um den Code von Nanoapps auf allen Geräten, die CHRE unterstützen, kompatibel zu machen. Das bedeutet, dass der Quellcode einer Nanoapp nicht geändert werden muss, um einen neuen Gerätetyp zu unterstützen. Er muss jedoch möglicherweise speziell für den Prozessor-Befehlssatz oder die binäre Schnittstelle der Anwendung (Application Binary Interface, ABI) des Zielgeräts neu kompiliert werden. Die CHRE-Architektur und das API-Design sorgen auch dafür, dass Nanoapps über verschiedene Versionen der CHRE API hinweg binärkompatibel sind. Das bedeutet, dass eine Nanoapp 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, für die die Nanoapp kompiliert wurde. Wenn eine Nanoapp-Binärdatei beispielsweise auf einem Gerät ausgeführt wird, das CHRE API v1.3 unterstützt, und dieses Gerät auf CHRE API v1.4 aktualisiert wird, funktioniert dieselbe Nanoapp-Binärdatei weiterhin. Ebenso kann die Nanoapp auf CHRE API v1.2 ausgeführt werden und zur Laufzeit ermitteln, ob sie Funktionen aus API v1.3 benötigt, um verwendet zu werden, oder ob sie möglicherweise mit eingeschränkten Funktionen ausgeführt werden kann.

Neue Versionen der CHRE API werden zusammen mit Android veröffentlicht. Da die CHRE Implementierung jedoch Teil der Anbieterimplementierung, ist, ist die auf einem Gerät unterstützte CHRE API-Version nicht unbedingt mit einer Android-Version verknüpft.

Zusammenfassung der Version

Wie das Android HIDL-Versionsschema, folgt die CHRE API der semantischen Versionsverwaltung. Die Hauptversion gibt die binäre Kompatibilität an, während die Nebenversion erhöht wird, wenn abwärtskompatible Funktionen eingeführt werden. Die CHRE API enthält Quellcodeanmerkungen, um anzugeben, in welcher Version eine Funktion oder ein Parameter eingeführt wurde, z. B. @since v1.1.

Die CHRE-Implementierung stellt auch eine plattformspezifische Patchversion über chreGetVersion() bereit, die angibt, wann Fehlerkorrekturen oder kleinere Updates in der Implementierung vorgenommen wurden.

Zusammenfassungen der einzelnen Versionen finden Sie unter version.h.

Obligatorische Systemfunktionen

Quellen kontextbezogener Signale wie Sensoren sind in optionale Funktionsbereiche unterteilt. Einige Kernfunktionen sind jedoch für alle CHRE-Implementierungen erforderlich. Dazu gehören Kernsystem-APIs, z. B. zum Festlegen von Timern, zum Senden und Empfangen von Nachrichten an Clients auf dem Anwendungsprozessor, zum Logging und andere. Vollständige Informationen finden Sie in den API-Headern.

Zusätzlich zu den in der CHRE API festgelegten Kernsystemfunktionen gibt es auch obligatorische CHRE-Systemfunktionen, die auf der Ebene der Context Hub HAL angegeben sind. Die wichtigste davon ist die Möglichkeit, Nanoapps dynamisch zu laden und zu entladen.

C/C++-Standardbibliothek

Um die Arbeitsspeichernutzung und die Systemkomplexität zu minimieren, müssen CHRE-Implementierungen nur eine Teilmenge der Standard-C- und C++-Bibliotheken und Sprachfunktionen unterstützen, die Laufzeitunterstützung erfordern. Gemäß diesen Prinzipien werden einige Funktionen aufgrund ihrer Speicher- und umfangreichen OS-Abhängigkeiten explizit ausgeschlossen, andere, weil sie durch besser geeignete CHRE-spezifische APIs ersetzt werden. Die folgende Liste ist nicht vollständig, aber die folgenden Funktionen sollen Nanoapps nicht zur Verfügung gestellt werden:

• C++-Ausnahmen und Laufzeittypinformationen (Runtime Type Information, RTTI)
• Multithreading-Unterstützung der Standardbibliothek, einschließlich der C++11-Header <thread>, <mutex>, <atomic>, <future>
• Standard-Ein-/Ausgabe-Bibliotheken für C und C++
• C++ Standard Template Library (STL)
• C++-Standardbibliothek für reguläre Ausdrücke
• Dynamische Speicherzuweisung über Standardfunktionen (z. B. malloc, calloc, realloc, free, operator new) und andere Standardbibliotheksfunktionen, die von Natur aus dynamische Zuweisung verwenden, z. B. std::unique_ptr
• Lokalisierung und Unterstützung für Unicode-Zeichen
• Bibliotheken für Datum und Uhrzeit
• Funktionen, die den normalen Programmablauf ändern, einschließlich <setjmp.h>, <signal.h>, abort, std::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 Hilfsbibliotheken verfügbar. So kann beispielsweise chreLog für das Debug-Logging verwendet werden, das auf das Android-Logcat-System ausgerichtet ist, während in einem herkömmlicheren Programm printf oder std::cout verwendet werden könnte.

Im Gegensatz dazu sind einige Standardbibliotheksfunktionen erforderlich. Es liegt an der Plattformimplementierung, diese über statische Bibliotheken zur Einbindung in eine Nanoapp-Binärdatei oder durch dynamische Verknüpfung zwischen der Nanoapp und dem System verfügbar zu machen. Dazu zählt unter anderem Folgendes:

• String- und Array-Hilfsfunktionen: memcmp, memcpy, memmove, memset, strlen

• Mathematische Bibliothek: Häufig verwendete Gleitkommafunktionen mit einfacher Genauigkeit:

  • Grundlegende Operationen: 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

Einige zugrunde liegende Plattformen unterstützen zwar zusätzliche Funktionen, aber eine Nanoapp gilt nur dann als auf verschiedenen CHRE-Implementierungen portierbar, wenn sie ihre externen Abhängigkeiten auf CHRE API-Funktionen und genehmigte Standardbibliotheksfunktionen beschränkt.

Optionale Funktionen

Zur Förderung von Hardware und Software ist die CHRE API in Funktionsbereiche unterteilt, die aus API-Sicht als optional gelten. Diese Funktionen sind möglicherweise nicht erforderlich, um eine kompatible CHRE-Implementierung zu unterstützen, aber möglicherweise, um eine bestimmte Nanoapp zu unterstützen. Auch wenn eine Plattform eine bestimmte Gruppe von APIs nicht unterstützt, müssen Nanoapps, die auf diese Funktionen verweisen, erstellt und geladen werden können.

Sensoren

Die CHRE API bietet die Möglichkeit, Daten von Sensoren anzufordern, darunter Beschleunigungsmesser, Gyroskop, Magnetometer, Umgebungslichtsensor und Näherungssensor. Diese APIs sollen einen ähnlichen Funktionsumfang wie die Android Sensors APIs bieten, einschließlich der Unterstützung für das Batching von Sensorproben, um den Stromverbrauch zu senken. Die Verarbeitung von Sensordaten in CHRE ermöglicht eine viel geringere Leistungsaufnahme und eine geringere Latenz bei der Verarbeitung von Bewegungssignalen im Vergleich zur Ausführung auf dem AP.

GNSS

CHRE bietet APIs zum Anfordern von Standortdaten von einem globalen Navigationssatellitensystem (GNSS), einschließlich GPS und anderer Satellitenkonstellationen. Dazu gehören Anfragen für periodische Positionsbestimmungen sowie Rohmessdaten. Beide sind jedoch 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 im Ruhemodus bleiben kann.

WLAN

CHRE bietet die Möglichkeit, mit dem WLAN-Chip zu interagieren, hauptsächlich für Standortzwecke. GNSS funktioniert gut für Standorte im Freien, aber die Ergebnisse von WLAN-Scans können genaue Standortinformationen in Innenräumen und in bebauten Gebieten liefern. Neben den Kosten für das Aufwecken des AP für einen Scan kann CHRE die Ergebnisse von WLAN-Scans abrufen, die von der WLAN-Firmware für Verbindungszwecke durchgeführt werden und aus Stromspargründen normalerweise nicht an den AP gesendet werden. Durch die Nutzung von Verbindungs-Scans für kontextbezogene Zwecke wird die Gesamtzahl der durchgeführten WLAN-Scans reduziert, was Strom spart.

Die Unterstützung für WLAN wurde in CHRE API v1.1 hinzugefügt, einschließlich der Möglichkeit, Scanergebnisse zu überwachen und Scans bei Bedarf auszulösen. Diese Funktionen wurden in v1.2 um die Möglichkeit erweitert, Round-Trip-Time-Messungen (RTT) für Access Points durchzuführen, die die Funktion unterstützen. Dadurch kann die relative Position genau bestimmt werden.

WWAN

Die CHRE API bietet die Möglichkeit, Zellidentifikationsinformationen für die Serving Cell und ihre Nachbarn abzurufen, die in der Regel für grobe Standortzwecke verwendet werden.

Audio

CHRE kann Batches von Audiodaten von einem Mikrofon mit geringem Stromverbrauch verarbeiten, das in der Regel Hardware nutzt, die zur Implementierung der SoundTrigger HAL verwendet wird. Durch die Verarbeitung von Audiodaten in CHRE können sie mit anderen Daten wie Bewegungssensoren kombiniert werden.

Bluetooth

CHRE bietet APIs, die eine Teilmenge der Bluetooth-Funktionen unterstützen, die von der Auslagerung mit geringem Stromverbrauch profitieren. Mit CHRE können Nanoapps BLE-Scans durchführen, RSSI überwachen und BLE-Werbedaten verarbeiten, ohne den AP aufzuwecken. Außerdem kann die Inhaberschaft einer bestehenden Bluetooth-Socket-Verbindung in die Auslagerungsdomain verschoben werden, was weniger Energie für die Wartung erfordert und Nanoapps die Kommunikation über die ausgelagerte BLE-Socket-Verbindung ermöglicht.

Referenzimplementierung

Referenzcode für das CHRE-Framework ist in AOSP im Projekt system/chre enthalten und in C++11 implementiert. Obwohl nicht unbedingt erforderlich, wird empfohlen, dass alle CHRE-Implementierungen auf dieser Codebasis basieren, um die Konsistenz zu gewährleisten und die Einführung neuer Funktionen zu beschleunigen. Dieser Code kann als Analogie zum Android-Kern-Framework betrachtet werden, da es sich um eine Open-Source-Implementierung von APIs handelt, die von Apps verwendet werden und als Grundlage und Standard für die Kompatibilität dienen. Er kann zwar angepasst und mit anbieterspezifischen Funktionen erweitert werden, aber es wird empfohlen, den gemeinsamen Code so nah wie möglich an der Referenz zu halten. Ähnlich wie die 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 Portierungsanleitung finden Sie in der README Datei im system/chre Projekt.