Kontext-Hub-Laufzeitumgebung (CHRE)

Smartphones enthalten eine Reihe von Prozessoren, die jeweils für die Ausführung verschiedener 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 zu liefern, wie z. Kleinere Prozessoren können diese Arbeitslasten effizienter bewältigen und ihre Aufgaben erledigen, ohne die Akkulaufzeit merklich zu beeinträchtigen. Allerdings sind die Softwareumgebungen in diesen Low-Power-Prozessoren eingeschränkter und können stark variieren, was eine plattformübergreifende Entwicklung erschwert.

Die Context Hub Runtime Environment (CHRE) bietet eine gemeinsame Plattform zum Ausführen von Apps auf einem stromsparenden Prozessor mit einer einfachen, standardisierten, eingebetteten benutzerfreundlichen API. CHRE macht es Geräte-OEMs und ihren vertrauenswürdigen Partnern leicht, die Verarbeitung vom AP zu entlasten, Batterie zu sparen und verschiedene Bereiche der Benutzererfahrung zu verbessern und eine Klasse von ständig aktiven, kontextbezogenen Funktionen zu ermöglichen, insbesondere solche, die die Anwendung von Maschinen beinhalten Umgebungssensor lernen.

Schlüssel Konzepte

CHRE ist die Software - Umgebung , in der kleinen native Anwendungen, genannt nanoapps, auf einem Low-Power - Prozessor und die Interaktion mit dem zugrunde liegenden System durch die gemeinsame CHRE API auszuführen. Um die ordnungsgemäße Implementierung der CHRE-APIs zu beschleunigen, ist eine plattformübergreifende Referenzimplementierung von CHRE in AOSP enthalten. Die Referenzimplementierung umfasst gemeinsamen Code und Abstraktionen zur zugrunde liegenden Hardware und Software durch eine Reihe von Plattformabstraktionsschichten (PALs). Nanoapps sind fast immer auf eine oder mehr Client - Anwendungen gebunden in Android laufen, die interact mit CHRE und nanoapps durch eingeschränkten Zugriff ContextHubManager System - APIs.

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 Ressourcen- 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. Zwar ist es üblich , die gleiche Hardware zu verwenden , um den Sensor - Hub und CHRE zu implementieren, CHRE selbst bietet keine durch die erforderliche Sensorfunktionalität Android Sensoren HAL . CHRE ist an die Context Hub HAL gebunden und fungiert als Client eines gerätespezifischen Sensor-Frameworks, um Sensordaten zu empfangen, ohne den AP einzubeziehen.

CHRE-Framework-Architektur

Abbildung 1. CHRE Rahmenarchitektur

Kontext-Hub HAL

Die Context Hub Hardwareabstraktionsschicht (HAL) ist die Schnittstelle zwischen dem Rahmen und die Android CHRE Implementierung des Geräts, an definierten hardware/interfaces/contexthub . Die Context Hub HAL definiert die APIs, über die das Android-Framework verfügbare Context Hubs und ihre Nanoapps erkennt, mit diesen Nanoapps durch Message Passing interagiert und das Laden und Entladen von Nanoapps ermöglicht. Eine Referenzimplementierung des Context Hub HAL , die mit der Referenzimplementierung von CHRE funktioniert , ist verfügbar unter system/chre/host .

Bei Widersprüchen zwischen dieser Dokumentation und der HAL-Definition hat die HAL-Definition Vorrang.

Initialisierung

Wenn Android bootet, die ContextHubService ruft die getHubs() HAL - Funktion , um zu bestimmen , ob irgendwelche Kontext Hubs auf dem Gerät verfügbar sind. Dies ist ein blockierender, einmaliger Aufruf, daher muss er schnell abgeschlossen werden, um eine Verzögerung des Startvorgangs zu vermeiden, und er muss ein genaues Ergebnis zurückgeben, da später keine neuen Kontext-Hubs eingeführt werden können.

Laden und Entladen von Nanoapps

Ein Kontexthub kann eine Reihe von Nanoapps enthalten, die im Geräteimage enthalten sind und beim Start von CHRE geladen werden. Diese sind als vorgespannte nanoapps bekannt, und sollte in der ersten möglichen Antwort auf eingeschlossen sein queryApps() .

Der Context Hub HAL unterstützt auch das Be- und Entladen nanoapps dynamisch zur Laufzeit durch die loadNanoApp() und unloadNanoApp() Funktionen. Nanoapps werden der 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, z. Dies bedeutet , dass keine von dem Code des nanoapp bis einer Ausführung enableNanoapp() Anforderung wird durch die HAL empfängt. Vorinstallierte Nanoapps können im aktivierten Zustand initialisiert werden.

Context Hub wird neu gestartet

Obwohl nicht erwartet wird, dass CHRE während des normalen Betriebs neu gestartet wird, kann es erforderlich sein, sich nach unerwarteten Bedingungen wie dem Versuch, auf eine nicht zugeordnete Speicheradresse zuzugreifen, zu erholen. In diesen Situationen startet CHRE unabhängig von Android neu. Der HAL benachrichtigt Android dieser durch die RESTARTED Veranstaltung, die es nur senden muss nach CHRE bis zu dem Punkt neu initialisiert worden , dass es neue Anforderungen annehmen kann, wie queryApps() .

CHRE-Systemübersicht

CHRE basiert auf einer ereignisgesteuerten Architektur, bei der die primäre Berechnungseinheit ein Ereignis ist, das an den Eintrittspunkt für die Ereignisbehandlung einer Nanoapp übergeben wird. Während das CHRE-Framework multithreaded sein kann, wird eine bestimmte Nanoapp niemals von mehreren Threads parallel ausgeführt. Der CHRE Rahmen wirkt mit einem gegebenen nanoapp durch eine der drei nanoapp Einspeisepunkten ( nanoappStart() , nanoappHandleEvent() und nanoappEnd() ) , oder durch einen Rückruf in einem vorherigen CHRE API - Aufruf zur Verfügung gestellt, und nanoapps interagieren mit dem CHRE Rahmen und das zugrunde liegende System über die CHRE-API. Die CHRE-API bietet eine Reihe grundlegender Funktionen sowie Einrichtungen für den Zugriff auf kontextbezogene Signale, einschließlich Sensoren, GNSS, Wi-Fi, WWAN und Audio, und kann mit zusätzlichen herstellerspezifischen Funktionen zur Verwendung durch herstellerspezifische Nanoapps erweitert werden .

Build-System

Während die Context Hub HAL und andere notwendige AP-seitige Komponenten zusammen mit Android erstellt werden, kann Code, der innerhalb von 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 basierend auf GNU Make zum Kompilieren von Nanoapps und optional das CHRE-Framework in Bibliotheken, die in das System integriert werden können. Gerätehersteller, die Unterstützung für CHRE hinzufügen, sollten die Build-Systemunterstützung für ihre Zielgeräte in AOSP integrieren.

Die CHRE-API ist nach dem Sprachstandard C99 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 wurde entwickelt, um Nanoapps-Code auf allen Geräten kompatibel zu machen, die CHRE unterstützen, was 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 Application Binary Interface (ABI). Die CHRE-Architektur und das API-Design stellen außerdem sicher, dass Nanoapps über verschiedene Versionen der CHRE-API binärkompatibel sind, was 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 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 aktualisiert wird, um CHRE API v1.4 zu unterstützen, funktioniert dieselbe Nanoapp-Binärdatei weiterhin. In ähnlicher Weise kann die Nanoapp auf CHRE API v1.2 ausgeführt werden und kann zur Laufzeit feststellen, ob sie Funktionalität von API v1.3 benötigt, um ihre Funktionalität zu erreichen, oder ob sie möglicherweise mit einer ordnungsgemässen Funktionsverschlechterung betrieben werden kann.

Neue Versionen der CHRE API neben Android freigegeben werden, aber als die CHRE Implementierung ist Teil der Anbieter Implementierung wird die CHRE API - Version auf einem Gerät unterstützt nicht unbedingt auf ein Android - Version verknüpft.

Versionszusammenfassung

Wie der Android HIDL Versionsschema folgt die CHRE API semantische Versionierung . Die Hauptversion zeigt Binärkompatibilität an, während die Nebenversion erhöht wird, wenn abwärtskompatible Funktionen eingeführt werden. Die API umfasst CHRE Annotationen Quellcode zu ermitteln , welche Version eine Funktion oder einen Parameter, beispielsweise eingeführt @since v1.1 .

Die CHRE Implementierung macht auch eine plattformspezifische Patch - Version durch chreGetVersion() , das anzeigt , wenn Fehlerbehebung oder kleineres Updates bei der Umsetzung gemacht werden.

Version 1.0 (Android 7)

Beinhaltet Unterstützung für Sensoren und Kernfunktionen von Nanoapps, wie Ereignisse und Timer.

Version 1.1 (Android 8)

Führt Standortfunktionen durch GNSS-Standort- und Rohmessungen, Wi-Fi-Scans und Mobilfunknetzinformationen zusammen mit allgemeinen Verfeinerungen zur Ermöglichung der Nanoapp-zu-Nanoapp-Kommunikation und anderen Verbesserungen ein.

Version 1.2 (Android 9)

Fügt Unterstützung für Daten von einem Low-Power-Mikrofon, Wi-Fi RTT-Bereich, AP-Weck-/Schlaf-Benachrichtigungen und andere Verbesserungen hinzu.

Version 1.3 (Android 10)

Verbessert die Funktionen in Bezug auf Sensorkalibrierungsdaten, fügt Unterstützung für das Spülen von gestapelten Sensordaten bei Bedarf hinzu, definiert den Schritterkennungssensortyp und erweitert GNSS-Standortereignisse um zusätzliche Genauigkeitsfelder.

Version 1.4 (Android 11)

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

Obligatorische Systemfunktionen

Während Quellen kontextbezogener Signale, wie Sensoren, in optionale Funktionsbereiche kategorisiert werden, sind einige Kernfunktionen für alle CHRE-Implementierungen erforderlich. Dazu gehören Kernsystem-APIs, wie z. B. zum Einstellen von Zeitgebern, Senden und Empfangen von Nachrichten an Clients auf dem Anwendungsprozessor, Protokollierung und andere. Ausführliche Informationen finden Sie in der API - Header .

Zusätzlich zu den in der CHRE-API kodifizierten Kernsystemfunktionen gibt es auch obligatorische CHRE-Funktionen auf Systemebene, die auf Context Hub HAL-Ebene spezifiziert sind. Die wichtigste davon ist die Fähigkeit, 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 standardmäßigen C- und C++-Bibliotheken und Sprachfeatures unterstützen, die Laufzeitunterstützung erfordern. Nach diesen Prinzipien werden einige Funktionen aufgrund ihres Speichers und/oder umfangreicher Abhängigkeiten auf Betriebssystemebene ausdrücklich ausgeschlossen, und andere, weil sie durch geeignetere CHRE-spezifische APIs ersetzt werden. Obwohl die Liste nicht vollständig ist, sollen die folgenden Funktionen Nanoapps nicht zur Verfügung gestellt werden:

  • C++-Ausnahmen und Laufzeittypinformationen (RTTI)
  • Standardbibliothek Multithreading - Unterstützung, einschließlich C ++ 11 - Header <thread> , <mutex> , <atomic> , <future>
  • C- und C++-Standard-Ein-/Ausgabebibliotheken
  • C++ Standardvorlagenbibliothek (STL)
  • C++ Standardbibliothek für reguläre Ausdrücke
  • Dynamische Speicherzuweisung durch Standardfunktionen (zum Beispiel malloc , calloc , realloc , free , operator new ), und andere Standard - Bibliotheksfunktionen , die von Natur aus einem dynamischen Zuordnung verwenden, wie std::unique_ptr
  • Lokalisierung und Unterstützung von Unicode-Zeichen
  • Datums- und Zeitbibliotheken
  • 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 ist eine gleichwertige Funktionalität von CHRE-API-Funktionen und/oder Dienstprogrammbibliotheken verfügbar. Zum Beispiel chreLog kann für die Debug - Protokollierung auf das Android logcat System gezielt eingesetzt werden, wo ein traditionelles Programm verwenden könnte printf oder std::cout .

Im Gegensatz dazu sind einige Standardbibliotheksfunktionen erforderlich. Es liegt an der Plattformimplementierung, diese durch statische Bibliotheken für die Aufnahme in eine Nanoapp-Binärdatei oder durch dynamisches Verknüpfen zwischen der Nanoapp und dem System bereitzustellen. Dies beinhaltet, ist aber nicht beschränkt auf:

  • 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 / Leistungsfunktionen: 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, wird eine Nanoapp nicht als portabel über CHRE-Implementierungen betrachtet, 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 angesehen werden. Obwohl diese Funktionen möglicherweise nicht erforderlich sind, um eine kompatible CHRE-Implementierung zu unterstützen, sind sie möglicherweise erforderlich, um eine bestimmte Nanoapp zu unterstützen. Auch wenn eine Plattform einen bestimmten Satz von APIs nicht unterstützt, müssen Nanoapps, 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 wie Beschleunigungsmesser, Gyroskop, Magnetometer, Umgebungslichtsensor und Näherungssensor anzufordern. Diese APIs sollen einen ähnlichen Funktionsumfang wie die Android-Sensor-APIs bereitstellen, einschließlich der Unterstützung für die Stapelverarbeitung von Sensorproben, um den Stromverbrauch zu reduzieren. Die Verarbeitung von Sensordaten innerhalb von CHRE ermöglicht im Vergleich zur Ausführung auf dem AP eine viel geringere Leistung und eine geringere Latenz bei der Verarbeitung von Bewegungssignalen.

GNSS

CHRE liefert APIs zum Anfordern von Standortdaten von einem globalen Navigationssatellitensystem (GNSS), einschließlich GPS und anderen Satellitenkonstellationen. Dies umfasst Anforderungen für periodische Positionsfixierungen sowie Rohmessdaten, obwohl beides unabhängige Funktionen sind. Da CHRE über eine direkte Verbindung zum GNSS-Subsystem verfügt, wird die Leistung 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 bebauten Gebieten liefern. CHRE vermeidet nicht nur die Kosten für das Aufwecken des AP 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, die normalerweise aus Stromgründen nicht an den AP geliefert werden. Die Nutzung von Konnektivitätsscans für kontextbezogene Zwecke hilft, die Gesamtzahl der durchgeführten Wi-Fi-Scans zu reduzieren und Energie zu sparen.

Unterstützung für Wi-Fi wurde in CHRE API v1.1 hinzugefügt, einschließlich der Möglichkeit, Scanergebnisse zu überwachen und Scans bei Bedarf auszulösen. Diese Fähigkeiten wurden in v1.2 mit der Fähigkeit erweitert auszuführen Round-Trip Time (RTT) Messungen gegen Access Points, die diese Funktion unterstützen, die genaue relative Positionsbestimmung ermöglicht.

WWAN

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

Audio

CHRE kann Batches von Audiodaten von einem Low-Power-Mikrofon verarbeiten, das normalerweise die Hardware nutzt, die zum Implementieren des SoundTrigger HAL verwendet wird. Durch die Verarbeitung von Audiodaten in CHRE können diese mit anderen Daten, wie beispielsweise Bewegungssensoren, fusioniert werden.

Referenzimplementierung

Referenzcode für den CHRE Rahmen ist in AOSP in dem mitgelieferten system/chre Projekt, implementiert in C ++ 11. 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 Analogon zum Kern-Android-Framework angesehen werden, da es sich um eine Open-Source-Implementierung von APIs handelt, die von Anwendungen verwendet werden und als Basis und Standard für die Kompatibilität dienen. Obwohl er mit herstellerspezifischen Funktionen angepasst und erweitert werden kann, 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, um eine Anpassung an jedes Gerät zu ermöglichen, das die Mindestanforderungen erfüllt.

Für technische Details und eine Portierung Führung finden Sie in der Readme in der mitgelieferten system/chre Projekt.