Sensorstapel

Die Abbildung unten zeigt den Android-Sensorstack. Jede Komponente kommuniziert nur mit den Komponenten direkt darüber und darunter, obwohl einige können Sensoren den Sensor Hub umgehen, wenn dieser vorhanden ist. Abläufe steuern über die Anwendungen bis hin zu den Sensoren und die Daten fließen von den Sensoren zum Anwendungen.

Abbildung 1: Schichten 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 bei einem Sensor.

Bei der Registrierung bei einem Sensor gibt die Anwendung die bevorzugte Probenahme an. und ihre Latenzanforderungen.

• Eine Anwendung registriert sich z. B. beim Standard-Beschleunigungsmesser, Ereignisse bei 100 Hz anfordern und Ereignisse mit einer Sekunde Latenz.
• Die App empfängt Ereignisse vom Beschleunigungsmesser mit einer Geschwindigkeit von mindestens 100 Hz und möglicherweise um bis zu 1 Sekunde verzögert.

Weitere Informationen zum SDK finden Sie in der Entwicklerdokumentation.

Framework

Das Framework ist für die Verknüpfung der verschiedenen Anwendungen mit dem HAL verantwortlich. Der HAL selbst ist Einzelclient. Ohne dieses Multiplexing im Framework-Ebene kann jeweils nur eine Anwendung auf jeden Sensor zugreifen. zu einer bestimmten Zeit.

• Wenn sich eine erste Anwendung bei einem Sensor registriert, sendet das Framework eine Anfrage zum HAL, um den Sensor zu aktivieren.
• Wenn weitere Anwendungen beim selben Sensor registriert werden, nimmt das Framework Anforderungen der einzelnen Anwendungen zu berücksichtigen und die aktualisierten angeforderten an den HAL.
  • Die Abtastrate ist das Maximum der angeforderten Abtastraten. Anwendungen häufiger Ereignisse empfangen als angefordert.
  • Die maximale Berichtslatenz ist das Minimum der angeforderten Latenz. Wenn eine Anwendung eine Anfrage anfordert mit einer maximalen Berichtslatenz von 0 verwenden, erhalten alle Anwendungen Ereignisse von diesem Sensor im fortlaufenden Modus, selbst wenn einige den Sensor mit einer maximalen Berichterstellungslatenz ungleich null. Weitere Informationen finden Sie unter Batching.
• Wenn sich die letzte bei einem Sensor registrierte Anwendung von diesem abmeldet, Frameworks sendet eine Anfrage an das HAL, den Sensor zu deaktivieren, damit die Stromversorgung unnötig konsumiert werden.

Auswirkungen des Multiplexing

Diese Notwendigkeit einer Multiplexing-Schicht im Framework erklärt einige Designelemente. Entscheidungen zu treffen.

• Wenn eine Anwendung eine bestimmte Stichprobenhäufigkeit anfordert, gibt es keine dass Termine nicht schneller ankommen. Wenn eine andere Anwendung denselben Sensor schneller angefordert haben, schnell erhalten.
• Die gleiche Mangel an Garantie gilt auch für die angeforderte maximale Berichtslatenz: Anwendungen Ereignisse mit viel kürzerer Latenz empfangen, als sie angefordert haben.
• Abgesehen von der Stichprobenhäufigkeit und der maximalen Berichtslatenz können Anwendungen Sensorparameter konfigurieren.
  • Stellen Sie sich zum Beispiel einen physischen Sensor vor, der sowohl in der Genauigkeit und Energiesparmodus.
  • Auf einem Android-Gerät kann nur einer dieser beiden Modi verwendet werden, Andernfalls könnte eine Anwendung den Modus für hohe Genauigkeit anfordern und einen anderen Energiesparmodus gäbe es keine Möglichkeit für das Framework, Anwendungen. Das Framework muss immer in der Lage sein, alle Kunden zufriedenzustellen. ist das keine Option.
• Es gibt keinen Mechanismus, mit dem Daten von den Anwendungen an die Sensoren oder ihre Fahrer. Dadurch wird sichergestellt, dass eine Anwendung das Verhalten des und auch andere Anwendungen funktionieren.

Sensor fusion

Das Android-Framework bietet eine Standardimplementierung für einige zusammengesetzte Sensoren. Wenn an einem Gerät ein Gyroskop, ein Beschleunigungsmesser und ein Magnetometer vorhanden sind, aber keine Sensoren für Drehvektor, Schwerkraft und lineare Beschleunigung vorhanden sind, implementiert das Framework diese Sensoren weiterhin verwenden können.

Die Standardimplementierung hat keinen Zugriff auf alle Daten, die andere Implementierungen haben Zugriff und muss auf dem SoC ausgeführt werden. genau oder so energieeffizient wie andere Implementierungen sein können. So viel wie sollten Gerätehersteller ihre eigenen fusionierten Sensoren (Drehung Vektor-, Schwerkraft- und lineare Beschleunigung sowie neuere Verbundsensoren Spielrotationsvektor, anstatt sich auf diese Standardimplementierung zu verlassen. Gerätehersteller können Anbieter von Sensorchips um Implementierung bitten.

Die standardmäßige Sensorfusionsimplementierung wird nicht beibehalten und kann dies dazu führen, dass Geräte, die darauf angewiesen sind, CTS nicht mehr funktionieren.

Details

Dieser Abschnitt dient als Hintergrundinformation für diejenigen, die die Framework-Code für Android Open Source Project (AOSP). Nicht relevant für Hardware-Herstellern.

JNI

Das Framework verwendet eine Java Native Interface (JNI), die mit android.hardware verknüpft ist und sich im Verzeichnis frameworks/base/core/jni/ befindet. Mit diesem Code wird die Methode niedrigerer nativer Code, um Zugriff auf die Sensorhardware zu erhalten.

Natives Framework

Das native Framework ist in frameworks/native/ definiert und bietet die dem Paket android.hardware entsprechen. Das native Framework ruft die Binder IPC-Proxys auf, um Zugriff auf sensorspezifischen Diensten.

Binder IPC

Die Binder IPC-Proxys erleichtern die Kommunikation über Prozessgrenzen hinweg.

HAL

Die HAL-API (Sensors Hardware Extraction Layer) ist die Schnittstelle zwischen der die Hardwaretreiber und das Android-Framework. Es besteht aus einer HAL-Schnittstelle. sensor.h und eine HAL-Implementierung bezeichnen wir als sensor.cpp.

Die Benutzeroberfläche wird von Android- und AOSP-Beitragenden definiert und die wird vom Hersteller des Geräts bereitgestellt.

Die HAL-Schnittstelle des Sensors befindet sich in hardware/libhardware/include/hardware. Siehe sensors.h .

Releasezyklus

Die HAL-Implementierung gibt an, welche Version der HAL-Schnittstelle sie durch Festlegen von your_poll_device.common.version implementieren. Der vorhandene HAL Schnittstellenversionen werden in sensor.h definiert und die Funktionalität ist an diese gebunden Versionen.

Das Android-Framework unterstützt derzeit die Versionen 1.0 und 1.3, aber 1.0 wird bald nicht mehr unterstützt. In dieser Dokumentation wird das Verhalten der Version 1.3, auf die alle Geräte aktualisiert werden sollten. Weitere Informationen zum Upgrade auf 1.3 finden Sie unter Einstellung der HAL-Version.

Kernel-Treiber

Die Sensortreiber interagieren mit den physischen Geräten. In einigen Fällen kann der HAL Implementierung und die Treiber sind dieselbe Softwareentität. In anderen Fällen fordert der Hardwareintegrator die Hersteller der Sensorchips Treiber, aber sie schreiben die HAL-Implementierung.

In allen Fällen sind die HAL-Implementierung und die Kernel-Treiber Hardwareherstellern und Android bietet keine bevorzugten Methoden zur schreiben Sie sie auf.

Sensor-Hub

Der Sensorstack eines Geräts kann optional einen Sensor Hub enthalten, der für Berechnungen auf niedriger Ebene mit geringer Leistung ausführen, während das SoC gesperrt. Zum Beispiel kann die Schrittzählung oder Sensorfusion diese Chips. Hier können Sie auch Sensor-Batching implementieren, Hardware-FIFOs für Sensorereignisse Weitere Informationen finden Sie unter Batching.

Hinweis:Wenn Sie neue ContextHub-Funktionen entwickeln, neue Sensoren oder LEDs haben, können Sie auch Neonkey SensorHub verbunden mit einem Hikey- oder Hikey960-Entwicklungsboard.

Wie der Sensor Hub materialisiert wird, hängt von der Architektur ab. Manchmal ist es einen separaten Chip, der manchmal auf demselben Chip enthalten ist wie das SoC. Wichtig Der Sensor Hub sollte genügend Speicher enthalten. und sehr wenig Strom verbrauchen, um die niedrige Android-Sensoren nutzen. Einige Sensor-Hubs enthalten einen Mikrocontroller für generische und Hardwarebeschleunigern ermöglichen, um den Rechenleistung stromsparend sein.

Wie der Sensor Hub aufgebaut ist und wie er mit den Sensoren kommuniziert und das SoC (I2C-Bus, SPI-Bus usw.) wird nicht von Android angegeben, es sollte aber darauf abzielen, den Stromverbrauch insgesamt zu minimieren.

Eine Option, die sich offenbar erheblich auf die Implementierung auswirkt besteht darin, zwei Interrupt-Linien zu haben, die vom Sensor Hub zum SoC führen: eine für Aufwachunterbrechungen (für Aufwachsensoren) und eine für Nicht-Aufwachunterbrechungen (bei Nicht-Aktivierungssensoren).

Sensoren

Das sind die physischen MEMs-Chips, die die Messungen vornehmen. In vielen Fällen Auf demselben Chip sind mehrere physische Sensoren vorhanden. Einige Chips ein Beschleunigungsmesser, ein Gyroskop und ein Magnetometer. Solche Chips werden oft sogenannte 9-Achsen-Chips, da jeder Sensor Daten über drei Achsen bereitstellt.)

Einige dieser Chips enthalten auch Logik für die Durchführung normaler Berechnungen wie Bewegungserkennung, Schritterkennung und 9-Achsen-Sensorfusion.

Obwohl die Anforderungen und Empfehlungen zu Leistung und Genauigkeit der CDDs auf die und nicht die physischen Sensoren, wirken sich diese physikalischen Sensoren. Zum Beispiel die Anforderungen an die Genauigkeit Der Rotationsvektor hat Auswirkungen auf die erforderliche Genauigkeit des physischen Gyroskop. Es ist Aufgabe des Geräteherstellers, die Anforderungen für physischen Sensoren.