Die folgende Abbildung zeigt den Android-Sensorstack. Jede Komponente kommuniziert nur mit den Komponenten direkt über und unter ihr. Einige Sensoren können den Sensorhub jedoch umgehen, wenn er vorhanden ist. Die Steuerung fließt von den Anwendungen zu den Sensoren und die Daten von den Sensoren zu den Anwendungen.
Abbildung 1: Schichten des Android-Sensorstacks und ihre jeweiligen Eigentümer
SDK
Anwendungen greifen über die Sensors SDK API (Software Development Kit) auf Sensoren zu. Das SDK enthält Funktionen zum Auflisten verfügbarer Sensoren und zum Registrieren bei einem Sensor.
Bei der Registrierung bei einem Sensor gibt die Anwendung die gewünschte Abtastrate und die Latenzanforderungen an.
- Eine Anwendung kann sich beispielsweise beim Standardbeschleunigungsmesser registrieren, Ereignisse mit 100 Hz anfordern und zulassen, dass Ereignisse mit einer Latenz von 1 Sekunde gemeldet werden.
- Die Anwendung empfängt Ereignisse vom Beschleunigungsmesser mit einer Rate von mindestens 100 Hz und möglicherweise mit einer Verzögerung von bis zu einer Sekunde.
Weitere Informationen zum SDK finden Sie in der Entwicklerdokumentation.
Framework
Das Framework ist für die Verknüpfung der verschiedenen Anwendungen mit der HAL verantwortlich. Die HAL selbst ist ein einzelner Client. Ohne dieses Multiplexing auf Frameworkebene könnte jeweils nur eine Anwendung auf jeden Sensor zugreifen.
- Wenn eine erste Anwendung bei einem Sensor registriert wird, sendet das Framework eine Anfrage an die HAL, um den Sensor zu aktivieren.
- Wenn sich zusätzliche Anwendungen beim selben Sensor registrieren, berücksichtigt das Framework die Anforderungen jeder Anwendung und sendet die aktualisierten angeforderten Parameter an die HAL.
- Die Abtastrate ist das Maximum der angeforderten Abtastfrequenzen. Das bedeutet, dass einige Anwendungen Ereignisse mit einer höheren Frequenz als der angeforderten erhalten.
- Die maximale Berichtslatenz ist der kleinste Wert der angeforderten Latenzen. Wenn eine Anwendung einen Sensor mit einer maximalen Berichtslatenz von 0 anfordert, erhalten alle Anwendungen die Ereignisse von diesem Sensor im kontinuierlichen Modus, auch wenn einige den Sensor mit einer maximalen Berichtslatenz angefordert haben, die nicht null ist. Weitere Informationen finden Sie unter Batch-Verarbeitung.
- Wenn die letzte Anwendung, die bei einem Sensor registriert war, die Registrierung aufhebt, senden die Frameworks eine Anfrage an die HAL, um den Sensor zu deaktivieren, damit nicht unnötig Strom verbraucht wird.
Auswirkungen von Multiplexing
Diese Notwendigkeit einer Multiplexing-Ebene im Framework erklärt einige Designentscheidungen.
- Wenn eine Anwendung eine bestimmte Stichprobenfrequenz anfordert, kann nicht garantiert werden, dass Ereignisse nicht mit einer höheren Rate eintreffen. Wenn eine andere Anwendung denselben Sensor mit einer höheren Rate anfordert, erhält die erste Anwendung die Daten ebenfalls mit der höheren Rate.
- Das Gleiche gilt für die angeforderte maximale Berichtslatenz: Anwendungen können Ereignisse mit einer viel geringeren Latenz als angefordert erhalten.
- Neben der Abtastrate und der maximalen Berichtslatenz können in Apps keine Sensorparameter konfiguriert werden.
- Stellen Sie sich beispielsweise einen physischen Sensor vor, der sowohl im Modus „Hohe Genauigkeit“ als auch im Modus „Niedriger Energieverbrauch“ funktionieren kann.
- Auf einem Android-Gerät kann nur einer dieser beiden Modi verwendet werden, da andernfalls eine Anwendung den Modus mit hoher Genauigkeit und eine andere einen Modus mit niedrigem Energieverbrauch anfordern könnte. Das Framework könnte dann nicht beide Anwendungen zufriedenstellen. Das Framework muss immer alle Kunden zufriedenstellen können. Das ist also keine Option.
- Es gibt keinen Mechanismus, um Daten von den Anwendungen an die Sensoren oder ihre Treiber weiterzuleiten. So kann eine Anwendung das Verhalten der Sensoren nicht ändern und andere Anwendungen beeinträchtigen.
Sensor fusion
Das Android-Framework bietet eine Standardimplementierung für einige zusammengesetzte Sensoren. Wenn auf einem Gerät ein Gyroskop, ein Beschleunigungsmesser und ein Magnetometer vorhanden sind, aber keine Rotationsvektor-, Gravitation- und lineare Beschleunigung-Sensoren, implementiert das Framework diese Sensoren, damit sie von Anwendungen verwendet werden können.
Die Standardimplementierung hat keinen Zugriff auf alle Daten, auf die andere Implementierungen zugreifen können, und muss auf dem SoC ausgeführt werden. Daher ist sie nicht so genau und energieeffizient wie andere Implementierungen. Gerätehersteller sollten nach Möglichkeit eigene Fusionssensoren (Rotationsvektor, Schwerkraft und lineare Beschleunigung sowie neuere zusammengesetzte Sensoren wie den Rotationsvektor für Spiele) definieren, anstatt sich auf diese Standardimplementierung zu verlassen. Gerätehersteller können auch Sensorchip-Anbieter bitten, ihnen eine Implementierung zur Verfügung zu stellen.
Die Standardimplementierung der Sensorfusion wird nicht mehr gepflegt und kann dazu führen, dass Geräte, die darauf angewiesen sind, die CTS-Zertifizierung nicht bestehen.
Details
Dieser Abschnitt enthält Hintergrundinformationen für Personen, die den Framework-Code des Android Open Source Project (AOSP) verwalten. Für Hardwarehersteller ist er nicht relevant.
JNI
Das Framework verwendet ein Java Native Interface (JNI), das mit android.hardware verknüpft ist und sich im Verzeichnis frameworks/base/core/jni/ befindet. Dieser Code ruft den nativen Code der unteren Ebene auf, um Zugriff auf die Sensorhardware zu erhalten.
Natives Framework
Das native Framework ist in frameworks/native/ definiert und bietet ein natives Äquivalent zum Paket android.hardware. Das native Framework ruft die Binder-IPC-Proxys auf, um Zugriff auf sensorspezifische Dienste zu erhalten.
Binder IPC
Die Binder-IPC-Proxys erleichtern die Kommunikation über Prozessgrenzen hinweg.
HAL
Die HAL-API (Sensors Hardware Abstraction Layer) ist die Schnittstelle zwischen den Hardwaretreibern und dem Android-Framework. Es besteht aus einer HAL-Schnittstelle (sensors.h) und einer HAL-Implementierung, die wir als sensors.cpp bezeichnen.
Die Benutzeroberfläche wird von Android- und AOSP-Mitarbeitern definiert und die Implementierung wird vom Hersteller des Geräts bereitgestellt.
Die HAL-Schnittstelle des Sensors befindet sich in hardware/libhardware/include/hardware.
Weitere Informationen finden Sie unter sensors.h.
Release-Zyklus
Die HAL-Implementierung gibt an, welche Version der HAL-Schnittstelle implementiert wird, indem your_poll_device.common.version festgelegt wird. Die vorhandenen HAL-Schnittstellenversionen sind in „sensors.h“ definiert und die Funktionalität ist an diese Versionen gebunden.
Das Android-Framework unterstützt derzeit die Versionen 1.0 und 1.3. Version 1.0 wird jedoch bald nicht mehr unterstützt. In dieser Dokumentation wird das Verhalten von Version 1.3 beschrieben, auf die alle Geräte umgestellt werden sollten. Weitere Informationen zum Upgrade auf Version 1.3 finden Sie unter Einstellung der HAL-Version.
Kernel-Treiber
Die Sensortreiber interagieren mit den physischen Geräten. In einigen Fällen sind die HAL-Implementierung und die Treiber dieselbe Softwareentität. In anderen Fällen bittet der Hardwareintegrator die Sensorchiphersteller, die Treiber bereitzustellen, schreibt aber selbst die HAL-Implementierung.
In allen Fällen liegen die Implementierung der HAL und die Kernel-Treiber in der Verantwortung der Hardwarehersteller. Android bietet keine bevorzugten Ansätze für die Erstellung dieser Komponenten.
Sensor-Hub
Der Sensorstack eines Geräts kann optional einen Sensorhub enthalten, der für die Ausführung einiger Low-Level-Berechnungen bei geringem Stromverbrauch nützlich ist, während sich das SoC im Ruhemodus befinden kann. So können beispielsweise die Schrittzählung oder die Sensorfusion auf diesen Chips ausgeführt werden. Es ist auch ein guter Ort, um Sensor-Batching zu implementieren und Hardware-FIFOs für die Sensorereignisse hinzuzufügen. Weitere Informationen finden Sie unter Batchverarbeitung.
Hinweis:Wenn Sie neue ContextHub-Funktionen entwickeln möchten, die neue Sensoren oder LEDs verwenden, können Sie auch einen Neonkey SensorHub verwenden, der mit einem Hikey- oder Hikey960-Entwicklungsboard verbunden ist.
Wie der Sensorhub materialisiert wird, hängt von der Architektur ab. Manchmal ist er ein separater Chip, manchmal ist er auf demselben Chip wie das SoC enthalten. Wichtige Eigenschaften des Sensorhubs sind, dass er genügend Speicher für die Batchverarbeitung enthalten und sehr wenig Strom verbrauchen sollte, um die Implementierung der energieeffizienten Android-Sensoren zu ermöglichen. Einige Sensorhubs enthalten einen Mikrocontroller für allgemeine Berechnungen und Hardwarebeschleuniger, die eine sehr energieeffiziente Berechnung für Sensoren mit geringem Energieverbrauch ermöglichen.
Die Architektur des Sensorhubs und die Kommunikation mit den Sensoren und dem SoC (I2C-Bus, SPI-Bus usw.) werden von Android nicht spezifiziert. Sie sollten jedoch darauf abzielen, den Gesamtenergieverbrauch zu minimieren.
Eine Option, die sich erheblich auf die Einfachheit der Implementierung auswirken kann, besteht darin, zwei Interrupt-Leitungen vom Sensorhub zum SoC zu haben: eine für Weck-Interrupts (für Wecksensoren) und die andere für Nicht-Weck-Interrupts (für Nicht-Wecksensoren).
Sensoren
Das sind die physischen MEMS-Chips, die die Messungen vornehmen. In vielen Fällen sind mehrere physische Sensoren auf demselben Chip vorhanden. Einige Chips enthalten beispielsweise einen Beschleunigungsmesser, ein Gyroskop und ein Magnetometer. (Diese Chips werden oft als 9‑Achsen-Chips bezeichnet, da jeder Sensor Daten über 3 Achsen liefert.)
Einige dieser Chips enthalten auch Logik für gängige Berechnungen wie Bewegungserkennung, Schritterkennung und 9‑Achsen-Sensorfusion.
Die Anforderungen und Empfehlungen an die Leistung und Genauigkeit von CDD beziehen sich zwar auf den Android-Sensor und nicht auf die physischen Sensoren, sie wirken sich jedoch auf die Auswahl der physischen Sensoren aus. Die Anforderung an die Genauigkeit des Drehvektors im Spiel hat beispielsweise Auswirkungen auf die erforderliche Genauigkeit des physischen Gyroskops. Es liegt in der Verantwortung des Geräteherstellers, die Anforderungen für physische Sensoren abzuleiten.