Die folgende Abbildung zeigt den Android-Sensor-Stack. Jede Komponente kommuniziert nur mit den Komponenten direkt darüber und darunter. Einige Sensoren können den Sensor-Hub umgehen, wenn er vorhanden ist. Der Datenfluss erfolgt von den Anwendungen zu den Sensoren und von den Sensoren zu den Anwendungen.
Abbildung 1: Ebenen des Android-Sensorstacks und ihre jeweiligen Eigentümer
SDK
Anwendungen greifen über die Sensors SDK (Software Development Kit) API auf Sensoren zu. Das SDK enthält Funktionen zum Auflisten verfügbarer Sensoren und zum Registrieren für einen Sensor.
Bei der Registrierung für einen Sensor gibt die Anwendung die bevorzugte Abtastfrequenz und die Latenzanforderungen an.
- Eine Anwendung kann sich beispielsweise für den 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 1 Sekunde.
Weitere Informationen zum SDK finden Sie in der Entwicklerdokumentation.
Framework
Das Framework ist für die Verknüpfung der verschiedenen Anwendungen mit dem HAL zuständig. Das HAL selbst ist ein Einzelclient. Ohne dieses Multiplexing auf Framework-Ebene könnte jeweils nur eine Anwendung auf jeden Sensor zugreifen.
- Wenn sich eine erste Anwendung für einen Sensor registriert, sendet das Framework eine Anfrage an die HAL, um den Sensor zu aktivieren.
- Wenn sich zusätzliche Anwendungen für denselben Sensor registrieren, berücksichtigt das Framework die Anforderungen jeder Anwendung und sendet die aktualisierten angeforderten Parameter an die HAL.
- Die Abtastrate ist die maximale der angeforderten Abtastraten. Das bedeutet, dass einige Anwendungen Ereignisse mit einer höheren Häufigkeit als der angeforderten erhalten.
- Die maximale Berichtslatenz ist die niedrigste der angeforderten Latenzen. Wenn eine Anwendung einen Sensor mit einer maximalen Meldeverzögerung von 0 anfordert, erhalten alle Anwendungen die Ereignisse von diesem Sensor im kontinuierlichen Modus, auch wenn einige den Sensor mit einer maximalen Meldeverzögerung ungleich null angefordert haben. Weitere Informationen finden Sie unter Batching.
- Wenn die letzte Anwendung, die für einen Sensor registriert ist, die Registrierung aufhebt, sendet das Framework 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 Sampling-Häufigkeit anfordert, gibt es keine Garantie dafür, dass Ereignisse nicht schneller eintreffen. Wenn eine andere Anwendung denselben Sensor mit einer höheren Rate angefordert hat, erhält die erste Anwendung die Daten ebenfalls mit dieser Rate.
- Dasselbe gilt für die angeforderte maximale Latenz für Berichte: Anwendungen erhalten möglicherweise Ereignisse mit einer viel geringeren Latenz als angefordert.
- Neben der Abtastfrequenz und der maximalen Berichtslatenz können Anwendungen keine Sensorparameter konfigurieren.
- Stellen Sie sich beispielsweise einen physischen Sensor vor, der sowohl im Modus „Hohe Genauigkeit“ als auch im Modus „Geringer Stromverbrauch“ funktionieren kann.
- Auf einem Android-Gerät kann nur einer dieser beiden Modi verwendet werden, da sonst eine Anwendung den Modus mit hoher Genauigkeit und eine andere den Modus mit geringem Stromverbrauch anfordern könnte. Das Framework hätte dann keine Möglichkeit, beide Anwendungen zu bedienen. Das Framework muss immer alle seine Clients bedienen können. Daher ist dies keine Option.
- Es gibt keinen Mechanismus, um Daten von den Anwendungen an die Sensoren oder deren Treiber zu senden. So wird verhindert, dass eine Anwendung das Verhalten der Sensoren ändert und andere Anwendungen dadurch nicht mehr funktionieren.
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-, Schwerkraft- und lineare Beschleunigung>-Sensoren, implementiert das Framework diese Sensoren, damit Anwendungen sie weiterhin verwenden können.
Die Standardimplementierung hat keinen Zugriff auf alle Daten, auf die andere Implementierungen zugreifen können. Außerdem muss sie auf dem SoC ausgeführt werden. Daher ist sie nicht so genau und energieeffizient wie andere Implementierungen. Gerätehersteller sollten nach Möglichkeit eigene kombinierte Sensoren (Rotationsvektor, Schwerkraft und lineare Beschleunigung sowie neuere zusammengesetzte Sensoren wie den Game-Rotationsvektor) definieren, anstatt sich auf diese Standardimplementierung zu verlassen. Gerätehersteller können auch Sensorchipanbieter bitten, ihnen eine Implementierung zur Verfügung zu stellen.
Die Standardimplementierung der Sensorfusion wird nicht mehr gewartet und kann dazu führen, dass Geräte, die darauf angewiesen sind, den CTS-Test nicht bestehen.
Details
Dieser Abschnitt enthält Hintergrundinformationen für diejenigen, die den Framework-Code des Android Open Source Project (AOSP) verwalten. Für Hardwarehersteller ist sie 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. Mit diesem Code wird der native Code auf niedrigerer Ebene aufgerufen, um Zugriff auf die Sensorhardware zu erhalten.
Natives Framework
Das native Framework wird 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 Sensors Hardware Abstraction Layer (HAL) API ist die Schnittstelle zwischen den Hardwaretreibern und dem Android-Framework. Sie besteht aus einer HAL-Schnittstelle (sensors.h) und einer HAL-Implementierung (sensors.cpp).
Die Schnittstelle wird von Android- und AOSP-Mitwirkenden definiert und die Implementierung wird vom Hersteller des Geräts bereitgestellt.
Die Sensor-HAL-Schnittstelle befindet sich in hardware/libhardware/include/hardware.
Weitere Informationen finden Sie unter sensors.h.
Releasezyklus
Die HAL-Implementierung gibt an, welche Version der HAL-Schnittstelle sie implementiert, indem sie your_poll_device.common.version festlegt. 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, aber Version 1.0 wird bald nicht mehr unterstützt. In dieser Dokumentation wird das Verhalten von Version 1.3 beschrieben, auf die alle Geräte aktualisiert werden sollten. Weitere Informationen zum Upgrade auf Version 1.3 finden Sie unter HAL-Versionsverwerfung.
Kernel-Treiber
Die Sensortreiber interagieren mit den physischen Geräten. In einigen Fällen sind die HAL-Implementierung und die Treiber dieselbe Softwareeinheit. In anderen Fällen fordert der Hardware-Integrator die Treiber von den Herstellern der Sensorchips an, schreibt aber selbst die HAL-Implementierung.
In allen Fällen sind die Hardwarehersteller für die HAL-Implementierung und die Kerneltreiber verantwortlich. Android bietet keine bevorzugten Ansätze für das Schreiben dieser Komponenten.
Sensor-Hub
Der Sensor-Stack eines Geräts kann optional einen Sensor-Hub enthalten, der nützlich ist, um einige Low-Level-Berechnungen bei geringem Stromverbrauch durchzuführen, während sich der SoC im Ruhezustand befindet. Auf diesen Chips können beispielsweise Schritte gezählt oder Sensordaten zusammengeführt werden. Außerdem ist es ein guter Ort, um Sensor-Batching zu implementieren und Hardware-FIFOs für die Sensorereignisse hinzuzufügen. Weitere Informationen finden Sie unter Batching.
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 Sensor-Hub realisiert wird, hängt von der Architektur ab. Er ist manchmal ein separater Chip und manchmal auf demselben Chip wie der SoC enthalten. Wichtige Merkmale des Sensor-Hubs sind, dass er genügend Speicher für das Batching enthalten und sehr wenig Strom verbrauchen sollte, um die Implementierung der Android-Sensoren mit geringem Stromverbrauch zu ermöglichen. Einige Sensor-Hubs enthalten einen Mikrocontroller für allgemeine Berechnungen und Hardwarebeschleuniger, um Berechnungen mit sehr geringem Stromverbrauch für Sensoren mit geringem Stromverbrauch zu ermöglichen.
Wie der Sensor-Hub aufgebaut ist und wie er mit den Sensoren und dem SoC (I2C-Bus, SPI-Bus usw.) kommuniziert, wird von Android nicht festgelegt. Es sollte jedoch darauf geachtet werden, den Gesamtstromverbrauch zu minimieren.
Eine Option, die sich anscheinend erheblich auf die Einfachheit der Implementierung auswirkt, sind zwei Interrupt-Leitungen vom Sensor-Hub zum SoC: eine für Wake-up-Interrupts (für Wake-up-Sensoren) und die andere für Nicht-Wake-up-Interrupts (für Nicht-Wake-up-Sensoren).
Sensoren
Das sind die physischen MEMS-Chips, die die Messungen durchführen. Häufig sind mehrere physische Sensoren auf demselben Chip vorhanden. Einige Chips enthalten beispielsweise einen Beschleunigungsmesser, ein Gyroskop und ein Magnetometer. Solche Chips werden oft als 9-Achsen-Chips bezeichnet, da jeder Sensor Daten über 3 Achsen liefert.
Einige dieser Chips enthalten auch Logik für die Durchführung üblicher Berechnungen wie Bewegungserkennung, Schrittzählung und 9-Achsen-Sensorfusion.
Die Anforderungen und Empfehlungen für die Leistung und Genauigkeit von CDD beziehen sich zwar auf den Android-Sensor und nicht auf die physischen Sensoren, wirken sich aber auf die Auswahl der physischen Sensoren aus. Die Anforderung an die Genauigkeit des Rotationsvektors des Spiels hat beispielsweise Auswirkungen auf die erforderliche Genauigkeit des physischen Gyroskops. Es liegt im Ermessen des Geräteherstellers, die Anforderungen für physische Sensoren abzuleiten.