Die folgende Abbildung zeigt den Android-Sensorstapel. Jede Komponente kommuniziert nur mit den Komponenten direkt darüber und darunter, obwohl einige Sensoren den Sensor-Hub umgehen können, wenn er vorhanden ist. Die Steuerung fließt von den Anwendungen nach unten zu den Sensoren, und Daten fließen von den Sensoren nach oben zu den Anwendungen.
Abbildung 1. Schichten des Android-Sensorstapels und ihre jeweiligen Besitzer
SDK
Anwendungen greifen über die API des Sensors SDK (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 ihre bevorzugte Abtastfrequenz und ihre Latenzanforderungen an.
- Beispielsweise kann sich eine Anwendung beim Standardbeschleunigungsmesser registrieren, Ereignisse mit 100 Hz anfordern und zulassen, dass Ereignisse mit einer Latenzzeit von 1 Sekunde gemeldet werden.
- Die Anwendung empfängt Ereignisse vom Beschleunigungsmesser mit einer Rate von mindestens 100 Hz und möglicherweise bis zu 1 Sekunde verzögert.
Weitere Informationen zum SDK finden Sie in der Entwicklerdokumentation .
Rahmen
Das Framework ist für die Verknüpfung der verschiedenen Anwendungen mit dem HAL zuständig. Der HAL selbst ist Single-Client. Ohne dieses Multiplexing auf Framework-Ebene könnte immer nur eine einzige Anwendung auf jeden Sensor zugreifen.
- Wenn sich eine erste Anwendung bei einem Sensor registriert, sendet das Framework eine Anfrage an die HAL, um den Sensor zu aktivieren.
- Wenn sich zusätzliche Anwendungen bei demselben Sensor registrieren, berücksichtigt das Framework Anforderungen von jeder Anwendung und sendet die aktualisierten angeforderten Parameter an die HAL.
- Die Abtastfrequenz ist das Maximum der angeforderten Abtastfrequenzen, was bedeutet, dass einige Anwendungen Ereignisse mit einer höheren Frequenz als der angeforderten empfangen.
- Die maximale Berichtslatenz ist das Minimum der angeforderten. Wenn eine Anwendung einen Sensor mit einer maximalen Berichtslatenz von 0 anfordert, empfangen alle Anwendungen die Ereignisse von diesem Sensor im kontinuierlichen Modus, selbst wenn einige den Sensor mit einer maximalen Berichtslatenz ungleich Null angefordert haben. Weitere Einzelheiten finden Sie unter Stapelverarbeitung .
- Wenn sich die letzte Anwendung, die bei einem Sensor registriert ist, von ihm abmeldet, sendet das Framework eine Anfrage an die HAL, um den Sensor zu deaktivieren, damit nicht unnötig Strom verbraucht wird.
Auswirkungen des Multiplexing
Diese Notwendigkeit einer Multiplexing-Schicht im Framework erklärt einige Entwurfsentscheidungen.
- Wenn eine Anwendung eine bestimmte Abtastfrequenz anfordert, gibt es keine Garantie dafür, dass Ereignisse nicht mit einer schnelleren Rate eintreffen. Wenn eine andere Anwendung denselben Sensor mit einer schnelleren Rate angefordert hat, erhält die erste Anwendung sie ebenfalls mit der schnellen Rate.
- Der gleiche Mangel an Garantie gilt für die angeforderte maximale Meldelatenz: Anwendungen erhalten möglicherweise Ereignisse mit viel geringerer Latenz als sie angefordert haben.
- Abgesehen von der Abtastfrequenz und der maximalen Berichtslatenz können Anwendungen keine Sensorparameter konfigurieren.
- Stellen Sie sich zum Beispiel einen physischen Sensor vor, der sowohl im „High Accuracy“- als auch im „Low Power“-Modus 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 einen Modus mit geringer Leistung anfordern könnte. es gäbe keine Möglichkeit für das Framework, beide Anwendungen zu erfüllen. Das Framework muss immer in der Lage sein, alle seine Clients zufriedenzustellen, daher ist dies keine Option.
- Es gibt keinen Mechanismus, um Daten von den Anwendungen an die Sensoren oder ihre Treiber zu senden. Dadurch wird sichergestellt, dass eine Anwendung das Verhalten der Sensoren nicht ändern und andere Anwendungen beschädigen kann.
Sensorfusion
Das Android-Framework bietet eine Standardimplementierung für einige Verbundsensoren. Wenn ein Gyroskop , ein Beschleunigungsmesser und ein Magnetometer auf einem Gerät vorhanden sind, aber keine Rotationsvektor- , Schwerkraft- und Linearbeschleunigungssensoren vorhanden sind, implementiert das Framework diese Sensoren, sodass Anwendungen sie weiterhin verwenden können.
Die Standardimplementierung hat keinen Zugriff auf alle Daten, auf die andere Implementierungen Zugriff haben, und sie muss auf dem SoC ausgeführt werden, sodass sie weder so genau noch so energieeffizient ist wie andere Implementierungen. Gerätehersteller sollten so weit wie möglich ihre eigenen verschmolzenen Sensoren (Rotationsvektor, Schwerkraft und lineare Beschleunigung sowie neuere zusammengesetzte Sensoren wie den Spielrotationsvektor ) definieren, anstatt sich auf diese Standardimplementierung zu verlassen. Gerätehersteller können auch Sensorchip-Anbieter auffordern, ihnen eine Implementierung bereitzustellen.
Die standardmäßige Sensorfusionsimplementierung wird nicht beibehalten und kann dazu führen, dass Geräte, die sich darauf verlassen, CTS nicht bestehen.
Unter der Haube
Dieser Abschnitt dient als Hintergrundinformationen für diejenigen, die den Rahmencode des Android Open Source Project (AOSP) verwalten. Für Hardwarehersteller ist es 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/ . 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 stellt ein natives Äquivalent zum android.hardware -Paket bereit. 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. Es besteht aus einer HAL-Schnittstelle sensors.h und einer HAL-Implementierung, die wir als sensors.cpp bezeichnen.
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 Einzelheiten finden Sie unter sensors.h .
Release-Zyklus
Die HAL-Implementierung gibt an, welche Version der HAL-Schnittstelle sie implementiert, indem sie your_poll_device.common.version . 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 1.0 wird bald nicht mehr unterstützt. Diese Dokumentation beschreibt das Verhalten der Version 1.3, auf die alle Geräte upgraden sollten. Einzelheiten zum Upgrade auf 1.3 finden Sie unter Veraltung 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 Softwareeinheit. In anderen Fällen fordert der Hardware-Integrator die Hersteller von Sensorchips auf, die Treiber bereitzustellen, aber sie sind diejenigen, die die HAL-Implementierung schreiben.
In allen Fällen liegen HAL-Implementierung und Kernel-Treiber in der Verantwortung der Hardwarehersteller, und Android bietet keine bevorzugten Ansätze, um sie zu schreiben.
Sensor-Hub
Der Sensorstapel eines Geräts kann optional einen Sensorhub enthalten, der nützlich ist, um einige Berechnungen auf niedriger Ebene bei geringem Stromverbrauch durchzuführen, während sich das SoC in einem Suspend-Modus befinden kann. Auf diesen Chips kann beispielsweise Schrittzählung oder Sensorfusion durchgeführt werden. Es ist auch ein guter Ort, um Sensor-Batching zu implementieren, indem Hardware-FIFOs für die Sensorereignisse hinzugefügt werden. Weitere Informationen finden Sie unter Stapelverarbeitung .
Hinweis: Um neue ContextHub-Funktionen zu entwickeln, 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 materialisiert wird, hängt von der Architektur ab. Es ist manchmal ein separater Chip und manchmal auf demselben Chip wie der SoC enthalten. Wichtige Eigenschaften des Sensor-Hubs sind, dass er ausreichend Speicher für das Batching enthalten und sehr wenig Strom verbrauchen sollte, um die Implementierung der Low-Power-Android-Sensoren zu ermöglichen. Einige Sensor-Hubs enthalten einen Mikrocontroller für generische Berechnungen und Hardwarebeschleuniger, um eine Berechnung mit sehr geringer Leistung für Sensoren mit geringer Leistung zu ermöglichen.
Wie der Sensor-Hub aufgebaut ist und wie er mit den Sensoren und dem SoC (I2C-Bus, SPI-Bus, …) kommuniziert, wird von Android nicht vorgegeben, sollte aber darauf abzielen, den Gesamtstromverbrauch zu minimieren.
Eine Option, die einen erheblichen Einfluss auf die Einfachheit der Implementierung zu haben scheint, besteht darin, zwei Interrupt-Leitungen vom Sensor-Hub zum SoC zu haben: eine für Wake-up-Interrupts (für Wake-up-Sensoren) und die andere für Non-Wake-up-Interrupts (für Nicht-Wecksensoren).
Sensoren
Das sind die physischen MEMs-Chips, die die Messungen durchführen. In vielen Fällen sind mehrere physikalische Sensoren auf demselben Chip vorhanden. Einige Chips umfassen 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 eine gewisse Logik, um übliche Berechnungen wie Bewegungserkennung, Schritterkennung und 9-Achsen-Sensorfusion durchzuführen.
Obwohl die CDD-Leistungs- und Genauigkeitsanforderungen und -empfehlungen auf den Android-Sensor und nicht auf die physischen Sensoren abzielen, wirken sich diese Anforderungen auf die Wahl der physischen Sensoren aus. Beispielsweise hat die Genauigkeitsanforderung an den Spielrotationsvektor Auswirkungen auf die erforderliche Genauigkeit für das physische Gyroskop. Die Ableitung der Anforderungen an physikalische Sensoren obliegt dem Gerätehersteller.