Context Hub-Laufzeitumgebung (CHRE)

Smartphones verfügen über eine Reihe von Prozessoren, die jeweils für optimale Leistung verschiedene Aufgaben zu erledigen. Android läuft jedoch nur auf einem Prozessor: den Anwendungen Prozessor (AP). AP ist darauf ausgelegt, eine hervorragende Leistung bei der Bildschirmaktivierung zu erzielen. wie Gaming, aber Funktionen benötigen zu viel Strom, um Funktionen zu unterstützen, die ständige, kurze Verarbeitungsphasen erfordern, auch wenn der Bildschirm ist deaktiviert. Kleinere Prozessoren sind in der Lage, diese Arbeitslasten effizienter zu verarbeiten, damit sie ihre Aufgaben erledigen können, ohne die Akkulaufzeit merklich zu beeinträchtigen. Die sind in diesen Prozessoren mit geringerem Energieverbrauch eingeschränkt variieren stark, was eine plattformübergreifende Entwicklung erschwert.

Context Hub Runtime Environment (CHRE) bietet eine gemeinsame Plattform zum Ausführen auf einem Prozessor mit geringem Stromverbrauch und einer einfachen, standardisierten für die API erstellt werden. CHRE erleichtert OEMs und ihren vertrauenswürdigen Partner entlasten, um den Akku zu schonen und Bereiche der User Experience bieten und eine Klasse von ständig aktiven, kontextsensitiven Funktionen vor, insbesondere solche, bei denen von maschinellem Lernen zur Umgebungserkennung.

Schlüsselkonzepte

CHRE ist die Softwareumgebung, in der kleine native Apps, Nanoapps, führen Sie auf einem Prozessor mit geringem Energieverbrauch aus und interagieren über die allgemeine CHRE-API. Um die ordnungsgemäße Implementierung CHRE APIs, eine plattformübergreifende Referenzimplementierung von CHRE, sind in AOSP. Die Referenzimplementierung enthält gemeinsamen Code und Abstraktionen für den zugrunde liegende Hardware und Software über eine Reihe von Plattformabstraktionsebenen. (PAL). Nano-Apps sind fast immer an eine oder mehrere Client-Apps gebunden, die in Android, die über eingeschränkten Zugriff mit CHRE und Nano-Apps interagieren ContextHubManager System-APIs.

Auf übergeordneter Ebene lassen sich Parallelen zwischen der Architektur von CHRE und Android als Ganzes. Es gibt jedoch einige wichtige Unterschiede:

• CHRE unterstützt nur Nano-Apps, die in nativem Code entwickelt wurden (C- oder C++); Java wird nicht unterstützt.
• Aufgrund von Ressourceneinschränkungen und Sicherheitsbeschränkungen ist CHRE nicht offen. zur Verwendung durch beliebige Android-Apps von Drittanbietern. Nur vom System vertrauenswürdige Apps können darauf zugreifen können.

Es gibt auch einen wichtigen Unterschied zwischen dem Konzept der CHRE und einen Sensor Hub. Es ist zwar üblich, für die Implementierung der Funktion Sensor Hub und CHRE hat CHRE selbst keine Sensorfunktionen die für die Android-Sensoren HAL ein. CHRE ist verbunden mit den Context Hub HAL und agiert als Client eines gerätespezifischen Sensors. Sensordaten ohne Einbindung des AP zu empfangen.

Abbildung 1: CHRE-Framework-Architektur

Kontext-Hub-HAL

Die Context Hub-Hardwareabstraktionsschicht (HAL) ist die Schnittstelle zwischen der Android-Framework und die CHRE-Implementierung des Geräts, definiert unter hardware/interfaces/contexthub Der Context Hub HAL definiert die APIs, über die das Android-Framework verwendet wird. findet verfügbare Kontext-Hubs und ihre Nano-Apps, interagiert mit diesen und Nanoapps zu laden und zu laden und nicht geladen. Eine Referenzimplementierung des Context Hub-HAL, die mit dem Referenzimplementierung von CHRE finden Sie unter system/chre/host

Im Falle eines Konflikts zwischen dieser Dokumentation und der HAL-Definition Die HAL-Definition hat Vorrang.

Initialisierung

Beim Start von Android ContextHubService. Ruft die HAL-Funktion getHubs() auf, um festzustellen, ob Kontext-Hubs vorhanden sind auf dem Gerät verfügbar sind. Dies ist ein einmaliger Anruf, der blockieren muss und daher abgeschlossen werden muss um eine Verzögerung des Bootvorgangs zu vermeiden, und es muss ein genaues Ergebnis zurückgegeben werden, wenn Context Hubs können später nicht mehr eingeführt werden.

Nanoapps laden und entladen

Ein Context Hub kann eine Reihe von Nano-Apps enthalten, die im Gerät enthalten sind und werden beim Start von CHRE geladen. Diese werden als vorinstallierte Nano-Apps bezeichnet, und sollte in der ersten möglichen Antwort auf queryApps() enthalten sein.

Der Context Hub HAL unterstützt auch das dynamische Laden und Entladen von Nanoanwendungen loadNanoApp() und unloadNanoApp() verwenden. Nano-Apps werden dem HAL in einem für die CHRE-Hardware spezifischen Binärformat zur Verfügung gestellt und Softwareimplementierung des Geräts.

Wenn die Implementierung zum Laden einer Nanoapp in einen nichtflüchtigen Speicher erforderlich ist wie dem Flash-Speicher am Prozessor, auf dem CHRE ausgeführt wird, Die CHRE-Implementierung muss immer mit diesen dynamischen Nano-Apps im deaktiviert. Das bedeutet, dass erst dann der Code der Nanoapp ausgeführt wird, Die enableNanoapp()-Anfrage wird über den HAL empfangen. Vorinstallierte Nano-Apps können wenn die Initialisierung im aktivierten Zustand ist.

Context Hub-Neustarts

Es wird zwar nicht erwartet, dass CHRE im normalen Betrieb neu gestartet wird, kann notwendig sein, um sich von unerwarteten Bedingungen wie dem Versuch zu erholen, auf eine nicht zugeordnete Speicheradresse zugreifen. In diesen Situationen wird CHRE neu gestartet. unabhängig von Android. Der HAL informiert Android über die RESTARTED-Ereignis, das erst gesendet werden darf, nachdem CHRE neu initialisiert wurde. den Punkt, an dem neue Anfragen akzeptiert werden, z. B. queryApps().

CHRE-Systemübersicht

CHRE basiert auf einer ereignisgesteuerten Architektur, in der die Haupteinheit Berechnung ist ein Ereignis, das an den Einstiegspunkt für die Ereignisverarbeitung einer Nanoapp übergeben wird. Während Das CHRE-Framework kann Multithreading nutzen. Eine bestimmte Nanoapp wird nie aus der mehrere Threads parallel ausführen. Das CHRE-Framework interagiert mit einer bestimmten Nano-App über einen der drei Nanoapp-Einstiegspunkte (nanoappStart(), nanoappHandleEvent() und nanoappEnd()) oder über einen Callback in einem und Nanoapps interagieren mit dem CHRE-Framework und dem zugrunde liegendes System über die CHRE API. Die CHRE API bietet eine Reihe grundlegender Funktionen sowie Möglichkeiten für den Zugriff auf Kontextsignale, einschließlich Sensoren, GNSS, Wi-Fi, WWAN und Audio, und kann mit zusätzlichen anbieterspezifische Funktionen für anbieterspezifische Nano-Apps.

System erstellen

Während der Context Hub-HAL und andere erforderliche AP-Seiten-Komponenten erstellt werden, neben Android kann Code, der in CHRE ausgeführt wird, Anforderungen haben, nicht mit dem Android-Build-System kompatibel, d. h., es ist ein spezialisierter Toolchain. Daher bietet das CHRE-Projekt in AOSP einen vereinfachten Build System basierend auf GNU Make, um Nano-Apps zu kompilieren, und optional die CHRE in Bibliotheken umzuwandeln, die in das System integriert werden können. Gerät Hersteller, die CHRE unterstützen, sollten die Build-Systemunterstützung für ihre Zielgeräte in AOSP zu übertragen.

Die CHRE API ist in den Sprachstandard C99 geschrieben und die Referenz -Implementierung verwendet eine eingeschränkte Teilmenge von C++11, die für ressourcenbeschränkte Apps.

CHRE API

Die CHRE API ist eine Sammlung von C-Header-Dateien, die die Software definieren. zwischen einer Nanoapp und dem System. Es wurde entwickelt, um Nano-Apps ist der Code auf allen Geräten kompatibel, die CHRE unterstützen. Der Quellcode einer Nanoapp muss nicht geändert werden, um ein neues Gerät zu unterstützen. Typ, obwohl er möglicherweise speziell für den Namen des Zielgeräts neu kompiliert werden muss. Prozessoranweisungssatz oder Anwendungsbinärschnittstelle (Application Binary Interface, ABI) Die CHRE Architektur und API-Design stellen außerdem sicher, dass Nano-Apps mit Binärprogrammen kompatibel sind. Versionen der CHRE API testen, was bedeutet, dass eine Nano-App müssen neu kompiliert werden, damit sie auf einem System laufen, das eine andere Version der CHRE API im Vergleich zur Ziel-API, für die die Nanoapp kompiliert ist. Mit anderen Worten: Wenn ein Nanoapp-Binärprogramm auf einem Gerät ausgeführt wird, das die CHRE API unterstützt und das Gerät wurde aktualisiert, um CHRE API v1.4 zu unterstützen. funktioniert das Binärprogramm weiterhin. Genauso kann die Nanoapp mit der CHRE API v1.2 ausgeführt werden, und kann während der Laufzeit feststellen, ob Funktionen von API v1.3 bis zum oder ob sie möglicherweise mit alltagstauglichem Beeinträchtigung der Funktionen.

Neue Versionen der CHRE API werden zusammen mit Android veröffentlicht, aber als CHRE -Implementierung ist Teil der Implementierung von Anbietern, die auf einem Gerät unterstützte CHRE-API-Version nicht unbedingt mit einem Android-Version

Versionsübersicht

Zum Beispiel Android HIDL Versionsverwaltungsschema Die CHRE API folgt der semantischen Versionsverwaltung. Die Hauptversion zeigt die Binärkompatibilität an, während die Nebenversion bei Einführung abwärtskompatibler Funktionen erhöht. Die CHRE API enthält Quellcodeanmerkungen, um zu ermitteln, mit welcher Version eine Funktion eingeführt wurde. oder einen Parameter haben, z. B. @since v1.1.

Die CHRE-Implementierung stellt auch eine plattformspezifische Patchversion über chreGetVersion(), die angibt, wenn Fehlerkorrekturen oder kleinere Aktualisierungen in der Implementierung.

Version 1.0 (Android 7)

Umfasst Unterstützung für Sensoren und grundlegende Nanoapp-Funktionen wie Ereignisse und Timer.

Version 1.1 (Android 8)

Erläuterung der Standortfunktionen durch GNSS-Standort- und Rohdatenmessungen, WLAN-Suche, Informationen zum Mobilfunknetz sowie allgemeine Optimierungen um die Kommunikation zwischen Nanoapp und Nanoapp zu ermöglichen, sowie weitere Verbesserungen.

Version 1.2 (Android 9)

Unterstützung für Daten von einem energiesparenden Mikrofon, WLAN-RTT-Bereichsbestimmung, AP Benachrichtigungen zum Aufwachen und Schlafen sowie weitere Verbesserungen.

Version 1.3 (Android 10)

Verbesserte Funktionen in Bezug auf Sensorkalibrierungsdaten, Unterstützung für Löschen von Sensordaten in Batches bei Bedarf, Definition des Sensortyps der Schritterkennung und erweitert GNSS-Standortereignisse um zusätzliche Genauigkeitsfelder.

Version 1.4 (Android 11)

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

Obligatorische Systemfunktionen

Während Quellen von Kontextsignalen wie Sensoren in optionale sind einige Kernfunktionen in der gesamten CHRE erforderlich. Implementierungen. Dazu gehören wichtige System-APIs, z. B. diejenigen zum Festlegen Timer, das Senden und Empfangen von Nachrichten an Clients auf dem Anwendungsprozessor Logging usw. Detaillierte Informationen finden Sie in der API-Header:

Neben den in der CHRE API kodifizierten Kernsystemfunktionen gibt es obligatorische CHRE-Funktionen auf Systemebene, die auf der HAL-Ebene von Context Hub angegeben sind. Die Das bedeutendste ist die Fähigkeit, Nanoapps.

C/C++-Standardbibliothek

Um die Arbeitsspeichernutzung und die Systemkomplexität zu minimieren, werden CHRE-Implementierungen die nur einen Teil der Standard-C- und C++-Bibliotheken unterstützen Sprachfunktionen, die Laufzeitunterstützung erfordern. In Anbetracht dieser Prinzipien Funktionen werden aufgrund ihres Arbeitsspeichers und ihres umfangreichen Betriebssystems und andere, weil sie durch geeignetere CHRE-spezifische APIs Die folgende Liste erhebt keinen Anspruch auf Vollständigkeit. Funktionen sollen nicht für Nano-Apps verfügbar gemacht werden:

• C++-Ausnahmen und Informationen zum Laufzeittyp (Laufzeittypinformationen, RTTI)
• Multithreading-Unterstützung in der Standardbibliothek, einschließlich C++11-Header <thread>, <mutex>, <atomic>, <future>
• Standard-Eingabe-/-Ausgabebibliotheken für C und C++
• C++ Standard Template Library (STL)
• Bibliothek für reguläre Ausdrücke in C++
• Dynamische Arbeitsspeicherzuweisung durch Standardfunktionen (z. B. malloc, calloc, realloc, free, operator new) und anderer Standard Bibliotheksfunktionen, die grundsätzlich die dynamische Zuordnung verwenden, wie z. B. std::unique_ptr.
• Lokalisierung und Unterstützung von Unicode-Zeichen
• Datums- und Uhrzeitbibliotheken
• Funktionen, die den normalen Programmablauf ändern, einschließlich <setjmp.h>, <signal.h>, abort, std::terminate
• Auf die Hostumgebung zugreifen, einschließlich system, getenv
• POSIX und andere Bibliotheken, die nicht in der C99- oder C++11-Sprache enthalten sind Standards

In vielen Fällen sind gleichwertige Funktionen durch CHRE-API-Funktionen verfügbar. und Dienstprogrammbibliotheken. chreLog kann beispielsweise für das Debugging-Logging verwendet werden auf das Logcat-System von Android abzielt, bei dem ein traditionelleres Programm Verwenden Sie printf oder std::cout.

Im Gegensatz dazu sind einige Funktionen der Standardbibliothek erforderlich. Es liegt an der Plattformimplementierung, um diese über statische Bibliotheken zur Einbeziehung verfügbar zu machen. in einer Nanoapp-Binärdatei oder durch eine dynamische Verknüpfung zwischen der Nanoapp und dem System. Dieses umfasst unter anderem Folgendes:

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

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

  • Grundlegende Vorgänge: ceilf, fabsf, floorf, fmaxf, fminf, fmodf, roundf, lroundf und remainderf
  • Exponentialfunktionen und Potenzfunktionen: expf, log2f, powf, sqrtf
  • Trigonometrische und hyperbolische Funktionen: sinf, cosf, tanf, asinf acosf, atan2f, tanhf

Während einige zugrunde liegende Plattformen zusätzliche Funktionen unterstützen, wird nicht als übertragbar in CHRE-Implementierungen betrachtet, es sei denn, dies schränkt externe Abhängigkeiten zu CHRE API-Funktionen und eine genehmigte Standardbibliothek Funktionen.

Optionale Funktionen

Um Hardware und Software zu bewerben, ist die CHRE API in Funktionsbereiche, die aus Sicht der API als optional gelten. Während diese Funktionen sind möglicherweise nicht für die Unterstützung einer kompatiblen CHRE-Implementierung erforderlich, die zur Unterstützung einer bestimmten Nano-App erforderlich sind. Auch wenn eine Plattform kein Nanoapps, die auf diese Funktionen verweisen, müssen in der Lage sein, und laden.

Sensoren

Die CHRE API bietet die Möglichkeit, Daten von Sensoren anzufordern, darunter Beschleunigungsmesser, Gyroskop, Magnetometer, Umgebungslicht-Sensor und Näherungssensor. Diese APIs sollen einen Funktionssatz bieten, der den Android-Sensoren ähnelt APIs, einschließlich Unterstützung für die Batch-Verarbeitung von Sensorproben zur Reduzierung des Stromverbrauchs Die Verarbeitung von Sensordaten innerhalb von CHRE ermöglicht viel geringerer Energieverbrauch und geringere Latenz bei der Verarbeitung von Bewegungssignalen im Vergleich zum AP-System.

Logo: GNSS

CHRE stellt APIs zum Anfordern von Standortdaten von einer globalen Navigation bereit. Satellitensystem (GNSS), einschließlich GPS und anderer Satellitenkonstellationen. Dieses beinhaltet Anfragen für regelmäßige Positionskorrekturen sowie Rohdaten zur Messung. obwohl beide unabhängige Fähigkeiten sind. Da CHRE einen direkten Link zum GNSS hat, verringert sich der Stromverbrauch im Vergleich zu AP-basierten GNSS-Anfragen, können während des gesamten Lebenszyklus einer Standortsitzung durchschlafen.

WLAN

CHRE ermöglicht die Interaktion mit dem WLAN-Chip, hauptsächlich für zur Standortermittlung verwendet werden. Obwohl GNSS für Standorte im Freien gut funktioniert, WLAN-Scans können genaue Standortinformationen in Innenräumen und in Entwicklungsländern liefern . CHRE entlastet nicht nur die Kosten für das Aktivieren des AP für einen Scan, sondern kann auch die Ergebnisse der vom WLAN durchgeführten WLAN-Scans anhören, Firmware für Verbindungszwecke, die in der Regel nicht an den ZP übertragen werden. aus Gründen der Macht. Die Nutzung von Konnektivitätsscans zu kontextabhängigen Zwecken um die Gesamtzahl der durchgeführten WLAN-Scans zu reduzieren und Energie zu sparen.

In der CHRE API v1.1 wurde WLAN unterstützt, einschließlich der Möglichkeit, und lösen Scans bei Bedarf aus. Diese Funktionen wurden in Version 1.2 mit der Fähigkeit, Umlaufzeit (Round Trip Time, RTT) mit Zugangspunkten vergleichen, die diese Funktion unterstützen. genaue relative Positionsbestimmung.

Logo: WWAN

Die CHRE API bietet die Möglichkeit, Informationen zur Identifizierung von Zellen abzurufen. für die Bereitstellungszelle und ihre Nachbarn, die normalerweise für den Standort grob abgrenzen.

Audio

CHRE kann Batches von Audiodaten aus einem stromsparenden Mikrofon verarbeiten, das nutzt in der Regel Hardware zur Implementierung des SoundTrigger HAL. Wird verarbeitet... Audiodaten in CHRE können die Verschmelzung mit anderen Daten ermöglichen, z. B. Bewegungsdaten. Sensoren.

Referenzimplementierung

Der Referenzcode für das CHRE-Framework ist in AOSP in der system/chre enthalten in C++11 implementiert. Es ist zwar nicht unbedingt erforderlich, wird aber empfohlen für dass alle CHRE-Implementierungen auf dieser Codebasis basieren sollen, und die Einführung neuer Funktionen zu beschleunigen. Dieser Code ist sichtbar als Analog zum zentralen Android-Framework, da es ein Implementierung der von Apps verwendeten APIs, die als Referenz und Standard dienen aus Gründen der Kompatibilität. Er lässt sich zwar mit anbieterspezifischen sollten Sie den gemeinsamen Code so nah wie möglich Referenzen wie möglich. Ähnlich wie bei den HALs von Android ist auch die CHRE-Referenz Bei der Implementierung werden verschiedene Plattformabstraktionen verwendet, um eine Anpassung an jedes Gerät, das die Mindestanforderungen erfüllt.

Technische Details und eine Anleitung zur Rufnummernmitnahme finden Sie in der README im Projekt system/chre enthalten.