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
undremainderf
- Exponentialfunktionen und Potenzfunktionen:
expf
,log2f
,powf
,sqrtf
- Trigonometrische und hyperbolische Funktionen:
sinf
,cosf
,tanf
,asinf
acosf
,atan2f
,tanhf
- Grundlegende Vorgänge:
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.