Context Hub-Laufzeitumgebung (CHRE)

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 Anwendungen auf einem Prozessor mit geringem Energieverbrauch, mit einer einfachen, standardisierten, eingebetteten, nutzerfreundlichen API. CHRE erleichtert es Geräte-OEMs und ihren vertrauenswürdigen Partnern, die Verarbeitung von AP zu entlasten, den Akku zu schonen, verschiedene Bereiche der Nutzererfahrung zu verbessern und eine Klasse immer aktiver, kontextsensitiver 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 Ressourceneinschrä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 eines 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. Im Context Hub HAL werden die APIs definiert, über die das Android-Framework verfügbare Context Hubs und ihre Nano-Apps ermittelt, über 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 vorab geladene 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 für die CHRE-Hardware und -Softwareimplementierung des Geräts spezifisch 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 Zustand initialisiert werden.

Context Hub-Neustarts

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 über das Ereignis RESTARTED. Dieses Ereignis darf nur gesendet werden, 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 Nano-App wird nie parallel in 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 früheren 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 von grundlegenden Funktionen sowie Möglichkeiten für den Zugriff auf Kontextsignale, einschließlich Sensoren, GNSS, Wi-Fi, WWAN und Audio. Sie kann mit zusätzlichen anbieterspezifischen Funktionen zur Verwendung durch anbieterspezifische Nano-Apps erweitert werden.

System erstellen

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 Build-System 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 Nanoanwendung 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 ein Nano-App-Binary 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 umgestellt wird, funktioniert dasselbe Nano-App-Binary 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 HIDL-Versionsverwaltungsschema für Android folgt auch die CHRE API einer semantischen Versionsverwaltung. 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 Quellcodeanmerkungen, mit denen angegeben wird, 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 anzeigt, wenn Fehlerkorrekturen oder kleinere Updates in der Implementierung vorgenommen werden.

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 Kommunikation zwischen Nano-Apps und andere Verbesserungen.

Version 1.2 (Android 9)

Unterstützung für Daten von einem energiesparenden Mikrofon, WLAN-RTT-Range, AP-Wach- und Schlafbenachrichtigungen sowie weitere Verbesserungen

Version 1.3 (Android 10)

Die Funktionen für 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.

Obligatorische Systemfunktionen

Quellen für kontextbezogene Signale wie Sensoren werden in optionale Funktionsbereiche kategorisiert. Für alle CHRE-Implementierungen sind jedoch einige Kernfunktionen erforderlich. Dies gilt auch für Kernsystem-APIs, z. B. zum Einstellen von Timern, zum Senden und Empfangen von Nachrichten an Clients auf dem Anwendungsprozessor, zum Logging und für andere. 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. Das Wichtigste ist die Möglichkeit, Nanoanwendungen dynamisch zu laden und zu entladen.

C/C++-Standardbibliothek

Um die Arbeitsspeichernutzung und die Systemkomplexität zu minimieren, dürfen CHRE-Implementierungen nur einen Teil der standardmäßigen C- und C++-Bibliotheken und Sprachfeatures 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)
• 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>, abort und 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 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. Es liegt an der Plattformimplementierung, diese über statische Bibliotheken für die Aufnahme in eine Nanoapp-Binärdatei oder durch eine dynamische Verknüpfung zwischen der Nanoapp und dem System verfügbar zu machen. 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

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 keine bestimmten APIs unterstützt, müssen Nanoanwendungen, die auf diese Funktionen verweisen, in der Lage sein, zu erstellen und zu laden.

Sensoren

Die CHRE API bietet die Möglichkeit, Daten von Sensoren anzufordern, darunter Beschleunigungsmesser, Gyroskop, Magnetometer, Umgebungslicht-Sensor und Näherung. Diese APIs sollen ein ähnliches Funktionspaket wie die Android-Sensor-APIs bieten, einschließlich Unterstützung für Batch-Sensor-Samples zur Reduzierung des Energieverbrauchs. Die Verarbeitung von Sensordaten in CHRE ermöglicht im Vergleich zur Ausführung auf dem ZP eine wesentlich geringere Energie und eine geringere Latenz bei der Verarbeitung von Bewegungssignalen.

Logo: 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. Beide Funktionen sind unabhängig voneinander. 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 ermöglicht die Interaktion mit dem WLAN-Chip, hauptsächlich zu Standortzwecken. GNSS funktioniert zwar 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 WLAN unterstützt, 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.

Logo: 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 wir empfehlen, dass alle CHRE-Implementierungen auf dieser Codebasis basieren, um für Einheitlichkeit zu sorgen und die Einführung neuer Funktionen zu beschleunigen. Dieser Code ist analog zum zentralen Android-Framework insofern, als es sich um eine Open-Source-Implementierung von APIs handelt, die von Apps verwendet werden und als Referenz 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 platzieren. Ähnlich wie die HALs von Android verwendet die CHRE-Referenzimplementierung verschiedene Plattformabstraktionen, um sie an jedes Gerät anzupassen, das die Mindestanforderungen erfüllt.

Technische Details und eine Anleitung zur Portierung finden Sie in der README-Datei im system/chre-Projekt.