Context Hub-Laufzeitumgebung (CHRE)

Smartphones enthalten eine Reihe von Prozessoren, die jeweils für die Ausführung unterschiedlicher Aufgaben optimiert sind. Allerdings läuft Android nur auf einem Prozessor: dem Anwendungsprozessor (AP). Der AP ist darauf ausgelegt, eine hervorragende Leistung für Anwendungsfälle mit eingeschaltetem Bildschirm wie z. B. Spiele zu liefern, ist jedoch zu stromhungrig, um Funktionen zu unterstützen, die ständig häufige, kurze Verarbeitungsstöße erfordern, selbst wenn der Bildschirm ausgeschaltet ist. Kleinere Prozessoren sind in der Lage, diese Arbeitslasten effizienter zu bewältigen und ihre Aufgaben zu erledigen, ohne die Akkulaufzeit spürbar zu beeinträchtigen. Allerdings sind die Softwareumgebungen in diesen Prozessoren mit geringem Stromverbrauch begrenzter und können stark variieren, was eine plattformübergreifende Entwicklung erschwert.

Context Hub Runtime Environment (CHRE) bietet eine gemeinsame Plattform zum Ausführen von Apps auf einem Prozessor mit geringem Stromverbrauch und einer einfachen, standardisierten, eingebetteten API. CHRE macht es Geräte-OEMs und ihren vertrauenswürdigen Partnern leicht, die Verarbeitung vom AP zu entlasten, um Batterie zu sparen und verschiedene Bereiche des Benutzererlebnisses zu verbessern und eine Klasse ständig verfügbarer, kontextbezogener Funktionen zu ermöglichen, insbesondere solche, die die Anwendung von Maschinen beinhalten Erlernen der Umgebungswahrnehmung.

Schlüssel Konzepte

CHRE ist die Softwareumgebung, in der kleine native Anwendungen, 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 ordnungsgemäße Implementierung der CHRE-APIs zu beschleunigen, ist in AOSP eine plattformübergreifende Referenzimplementierung von CHRE enthalten. Die Referenzimplementierung umfasst allgemeinen Code und Abstraktionen zur zugrunde liegenden Hardware und Software über eine Reihe von Plattformabstraktionsschichten (PALs). Nanoapps sind fast immer an eine oder mehrere Client-Apps gebunden, die in Android ausgeführt werden und über ContextHubManager- System-APIs mit beschrä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 ist CHRE nicht für die Verwendung durch beliebige Android-Apps von Drittanbietern geöffnet. Nur vom System vertrauenswürdige Apps können darauf zugreifen.

Es gibt auch einen wichtigen Unterschied zwischen dem Konzept von CHRE und einem Sensor-Hub. Während es üblich ist, die gleiche Hardware zur Implementierung des Sensor-Hubs und von CHRE zu verwenden, stellt CHRE selbst nicht die Sensorfunktionalität bereit, die für den Android Sensors HAL erforderlich ist. CHRE ist an den Context Hub HAL gebunden und fungiert als Client eines gerätespezifischen Sensor-Frameworks, um Sensordaten zu empfangen, ohne den AP einzubeziehen.

Abbildung 1. CHRE-Framework-Architektur

Kontext-Hub HAL

Die Hardware-Abstraktionsschicht (HAL) von Context Hub ist die Schnittstelle zwischen dem Android-Framework und der CHRE-Implementierung des Geräts, definiert unter hardware/interfaces/contexthub . Der Context Hub HAL definiert die APIs, über die das Android-Framework verfügbare Context Hubs und ihre Nanoapps erkennt, mit diesen Nanoapps durch Nachrichtenübermittlung interagiert und das Laden und Entladen von Nanoapps ermöglicht. Eine Referenzimplementierung des 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

Wenn Android hochfährt, ruft der ContextHubService die HAL-Funktion getHubs() auf, um zu ermitteln, ob auf dem Gerät Kontext-Hubs verfügbar sind. Da es sich um einen blockierenden, einmaligen Aufruf handelt, muss er schnell abgeschlossen werden, um eine Verzögerung des Startvorgangs zu vermeiden, und er muss ein genaues Ergebnis zurückgeben, da im Nachhinein keine neuen Kontext-Hubs eingeführt werden können.

Laden und Entladen von Nanoapps

Ein Kontext-Hub kann eine Reihe von Nanoapps enthalten, die im Geräte-Image enthalten sind und beim Start von CHRE geladen werden. Diese werden als vorinstallierte Nanoapps bezeichnet und sollten in der ersten möglichen Antwort auf queryApps() enthalten sein.

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

Wenn die Implementierung zum Laden einer Nanoapp das Schreiben in einen nichtflüchtigen Speicher umfasst, beispielsweise einen 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. Dies bedeutet, dass kein Code der Nanoapp ausgeführt wird, bis eine enableNanoapp() Anfrage über die HAL empfangen wird. Vorinstallierte Nanoapps können im aktivierten Zustand initialisiert werden.

Der Kontext-Hub wird neu gestartet

Während im Normalbetrieb kein Neustart von CHRE zu erwarten ist, kann eine Wiederherstellung nach unerwarteten Bedingungen wie dem Versuch, auf eine nicht zugeordnete Speicheradresse zuzugreifen, erforderlich sein. In diesen Situationen startet CHRE unabhängig von Android neu. Der HAL benachrichtigt Android darüber über das RESTARTED Ereignis, das es erst senden darf, nachdem CHRE so weit neu initialisiert wurde, dass es neue Anfragen wie queryApps() annehmen kann.

Übersicht über das CHRE-System

CHRE basiert auf einer ereignisgesteuerten Architektur, bei der die primäre Recheneinheit ein Ereignis ist, das an den Eintrittspunkt für die Ereignisverarbeitung einer Nanoapp übergeben wird. Während das CHRE-Framework multithreadfähig ist, wird eine bestimmte Nanoapp niemals von mehreren Threads parallel ausgeführt. Das CHRE-Framework interagiert mit einer bestimmten Nanoapp über einen der drei Nanoapp-Einstiegspunkte ( nanoappStart() , nanoappHandleEvent() und nanoappEnd() ) oder über einen Rückruf, der in einem vorherigen CHRE-API-Aufruf bereitgestellt wurde, und Nanoapps interagieren mit dem CHRE-Framework und das zugrunde liegende System über die CHRE-API. Die CHRE-API bietet eine Reihe grundlegender Funktionen sowie Möglichkeiten für den Zugriff auf kontextbezogene Signale, einschließlich Sensoren, GNSS, Wi-Fi, WWAN und Audio, und kann um zusätzliche herstellerspezifische Funktionen zur Verwendung durch herstellerspezifische Nanoapps erweitert werden .

System aufbauen

Während der Context Hub HAL und andere notwendige AP-seitige Komponenten zusammen mit Android erstellt werden, kann Code, der in CHRE ausgeführt wird, Anforderungen haben, die ihn mit dem Android-Build-System inkompatibel machen, wie z. B. die Notwendigkeit einer speziellen Toolchain. Daher bietet das CHRE-Projekt in AOSP ein vereinfachtes Build-System auf Basis von GNU Make zum Kompilieren von Nanoapps und optional des CHRE-Frameworks in Bibliotheken, die in das System integriert werden können. Gerätehersteller, die Unterstützung für CHRE hinzufügen, sollten die Build-System-Unterstützung für ihre Zielgeräte in AOSP integrieren.

Die CHRE-API ist im C99-Sprachstandard geschrieben und die Referenzimplementierung verwendet eine eingeschränkte Teilmenge von C++11, die für Anwendungen mit begrenzten Ressourcen geeignet ist.

CHRE-API

Die CHRE-API ist eine Sammlung von C-Header-Dateien, die die Softwareschnittstelle zwischen einer Nanoapp und dem System definieren. Es soll Nanoapps-Code auf allen Geräten kompatibel machen, die CHRE unterstützen. Das bedeutet, dass der Quellcode für eine Nanoapp nicht geändert werden muss, um einen neuen Gerätetyp zu unterstützen, obwohl er möglicherweise speziell für den Prozessor des Zielgeräts neu kompiliert werden muss Befehlssatz oder Anwendungsbinärschnittstelle (ABI). Die CHRE-Architektur und das API-Design stellen außerdem sicher, dass Nanoapps mit verschiedenen Versionen der CHRE-API binär kompatibel sind. Dies 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 die Ziel-API, mit der die Nanoapp kompiliert wird. Mit anderen Worten: Wenn eine Nanoapp-Binärdatei auf einem Gerät ausgeführt wird, das CHRE API v1.3 unterstützt, und dieses Gerät auf die Unterstützung von 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 bestimmen, ob sie Funktionalität von API v1.3 benötigt, um ihre Funktionalität zu erreichen, oder ob sie betrieben werden kann, möglicherweise mit einer ordnungsgemäßen Funktionsverschlechterung.

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.

Versionszusammenfassung

Wie das Android-HIDL-Versionierungsschema folgt auch die CHRE-API der semantischen Versionierung . 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, um zu identifizieren, welche Version eine Funktion oder einen Parameter eingeführt hat, zum Beispiel @since v1.1 .

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

Version 1.0 (Android 7)

Beinhaltet Unterstützung für Sensoren und Kernfunktionen der Nanoapp, wie z. B. Ereignisse und Timer.

Version 1.1 (Android 8)

Führt Standortfunktionen durch GNSS-Standort- und Rohmessungen, Wi-Fi-Scanning und Mobilfunknetzinformationen ein, zusammen mit allgemeinen Verfeinerungen, um die Kommunikation von Nanoapp zu Nanoapp und anderen Verbesserungen zu ermöglichen.

Version 1.2 (Android 9)

Fügt Unterstützung für Daten von einem Mikrofon mit geringem Stromverbrauch, Wi-Fi RTT-Ranging, AP-Wake-/Sleep-Benachrichtigungen und andere Verbesserungen hinzu.

Version 1.3 (Android 10)

Verbessert die Funktionen im Zusammenhang mit Sensorkalibrierungsdaten, fügt Unterstützung für das Spülen gestapelter Sensordaten bei Bedarf hinzu, definiert den Schritterkennungssensortyp und erweitert GNSS-Standortereignisse um zusätzliche Genauigkeitsfelder.

Version 1.4 (Android 11)

Integriert Unterstützung für 5G-Zelleninformationen, Nanoapp-Debug-Dump und andere Verbesserungen.

Obligatorische Systemfunktionen

Während Quellen kontextbezogener Signale, wie etwa Sensoren, in optionale Funktionsbereiche kategorisiert werden, sind in allen CHRE-Implementierungen einige Kernfunktionen erforderlich. Dazu gehören Kernsystem-APIs, beispielsweise solche zum Einstellen von Timern, zum Senden und Empfangen von Nachrichten an Clients auf dem Anwendungsprozessor, zur Protokollierung und mehr. Ausführliche Informationen finden Sie in den API-Headern .

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

C/C++-Standardbibliothek

Um die Speichernutzung 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. Nach diesen Grundsätzen werden einige Funktionen aufgrund ihres Speichers und/oder umfangreicher Abhängigkeiten auf Betriebssystemebene explizit ausgeschlossen, andere wiederum, weil sie durch geeignetere CHRE-spezifische APIs ersetzt werden. Die folgenden Funktionen erheben zwar keinen Anspruch auf Vollständigkeit, sollen Nanoapps jedoch nicht zur Verfügung gestellt werden:

• C++-Ausnahmen und Laufzeittypinformationen (RTTI)
• Multithreading-Unterstützung der Standardbibliothek, einschließlich C++11-Header <thread> , <mutex> , <atomic> , <future>
• C- und C++-Standard-Eingabe-/Ausgabebibliotheken
• C++-Standardvorlagenbibliothek (STL)
• C++-Standardbibliothek für reguläre Ausdrücke
• Dynamische Speicherzuweisung durch Standardfunktionen (z. B. malloc , calloc , realloc , free , operator new ) und andere Standardbibliotheksfunktionen, die von Natur aus 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 , std::terminate
• Zugriff auf die Host-Umgebung, einschließlich system , getenv
• POSIX und andere Bibliotheken, die nicht in den Sprachstandards C99 oder C++11 enthalten sind

In vielen Fällen sind gleichwertige Funktionen über CHRE-API-Funktionen und/oder Dienstprogrammbibliotheken verfügbar. Beispielsweise kann chreLog für die Debug-Protokollierung verwendet werden, die auf das Android-Logcat-System ausgerichtet ist, wo ein traditionelleres Programm möglicherweise printf oder std::cout verwendet.

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

• String-/Array-Dienstprogramme: memcmp , memcpy , memmove , memset , strlen

• Mathematikbibliothek: Häufig verwendete Gleitkommafunktionen mit einfacher Genauigkeit:

  • Grundoperationen: ceilf , fabsf , floorf , fmaxf , fminf , fmodf , roundf , lroundf , remainderf
  • Exponential-/Potenzfunktionen: expf , log2f , powf , sqrtf
  • Trigonometrische/hyperbolische Funktionen: sinf , cosf , tanf , asinf , acosf , atan2f , tanhf

Während einige zugrunde liegende Plattformen zusätzliche Funktionen unterstützen, gilt eine Nanoapp nicht als über CHRE-Implementierungen hinweg portierbar, es sei denn, sie beschränkt ihre externen Abhängigkeiten auf CHRE-API-Funktionen und genehmigte Standardbibliotheksfunktionen.

Optionale Funktionen

Zur Förderung von Hardware und Software ist die CHRE API in Funktionsbereiche unterteilt, die aus API-Sicht als optional gelten. Während diese Funktionen möglicherweise nicht zur Unterstützung einer kompatiblen CHRE-Implementierung erforderlich sind, können sie zur Unterstützung einer bestimmten Nanoapp erforderlich sein. Selbst wenn eine Plattform einen bestimmten Satz 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-Sensor-APIs bieten, einschließlich der Unterstützung für die Batchverarbeitung von Sensorproben zur Reduzierung des Stromverbrauchs. Die Verarbeitung von Sensordaten innerhalb von CHRE ermöglicht im Vergleich zur Ausführung auf dem AP einen wesentlich geringeren Stromverbrauch und eine geringere Latenz bei der Verarbeitung von Bewegungssignalen.

GNSS

CHRE stellt APIs zum Anfordern von Standortdaten von einem globalen Navigationssatellitensystem (GNSS) bereit, einschließlich GPS und anderen Satellitenkonstellationen. Dazu gehören Anfragen nach regelmäßigen Positionsbestimmungen sowie Rohmessdaten, obwohl es sich bei beiden um unabhängige Funktionen handelt. Da CHRE über eine direkte Verbindung zum GNSS-Subsystem verfügt, wird der Stromverbrauch im Vergleich zu AP-basierten GNSS-Anfragen reduziert, da der AP während des gesamten Lebenszyklus einer Standortsitzung im Ruhezustand bleiben kann.

W-lan

CHRE bietet die Möglichkeit, mit dem Wi-Fi-Chip zu interagieren, hauptsächlich zu Standortzwecken. Während GNSS für Außenstandorte gut funktioniert, können die Ergebnisse von Wi-Fi-Scans genaue Standortinformationen in Innenräumen und in erschlossenen Gebieten liefern. CHRE vermeidet nicht nur die Kosten für das Aufwecken des APs für einen Scan, sondern kann auch die Ergebnisse von Wi-Fi-Scans abhören, die von der Wi-Fi-Firmware zu Konnektivitätszwecken durchgeführt werden und aus Energiegründen normalerweise nicht an den AP übermittelt werden. Die Nutzung von Konnektivitätsscans für kontextbezogene Zwecke trägt dazu bei, die Gesamtzahl der durchgeführten WLAN-Scans zu reduzieren und so Strom zu sparen.

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 Version 1.2 um die Möglichkeit erweitert , Round-Trip-Time (RTT) -Messungen für Access Points durchzuführen, die diese Funktion unterstützen, was eine genaue relative Positionsbestimmung ermöglicht.

WWAN

Die CHRE-API bietet die Möglichkeit, Zellidentifikationsinformationen für die versorgende Zelle und ihre Nachbarn abzurufen, die typischerweise für grobkörnige Standortzwecke verwendet werden.

Audio

CHRE kann Stapel von Audiodaten von einem Mikrofon mit geringer Leistung verarbeiten, was normalerweise die Hardware nutzt, die zur Implementierung des SoundTrigger HAL verwendet wird. Durch die Verarbeitung von Audiodaten in CHRE können diese mit anderen Daten, beispielsweise Bewegungssensoren, fusioniert werden.

Referenzimplementierung

Referenzcode für das CHRE-Framework ist in AOSP im system/chre Projekt enthalten und in C++11 implementiert. Obwohl dies nicht unbedingt erforderlich ist, wird empfohlen, dass alle CHRE-Implementierungen auf dieser Codebasis basieren, um die Konsistenz sicherzustellen und die Einführung neuer Funktionen zu beschleunigen. Dieser Code kann als Analogie zum Android-Kernframework angesehen werden, da es sich um eine Open-Source-Implementierung von APIs handelt, die von Anwendungen verwendet werden, und die als Basis und Standard für die Kompatibilität dient. Obwohl er mit herstellerspezifischen Funktionen angepasst und erweitert werden kann, wird empfohlen, den gemeinsamen Code so nah wie möglich an der Referenz beizubehalten. Ähnlich wie die HALs von Android nutzt die CHRE-Referenzimplementierung verschiedene Plattformabstraktionen, um eine Anpassung an jedes Gerät zu ermöglichen, das die Mindestanforderungen erfüllt.

Technische Details und eine Portierungsanleitung finden Sie in der README-Datei , die im system/chre Projekt enthalten ist.