Sensorstapel

Die folgende Abbildung zeigt den Android-Sensorstapel. Jede Komponente kommuniziert nur mit den Komponenten direkt über und unter ihr, obwohl einige Sensoren den Sensor-Hub umgehen können, wenn dieser vorhanden ist. Die Steuerung fließt von den Anwendungen bis zu den Sensoren, und die Daten fließen von den Sensoren bis zu den Anwendungen.

Schichten und Besitzer des Android-Sensorstapels

Abbildung 1. Schichten des Android-Sensorstapels und ihre jeweiligen Besitzer

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 ihre bevorzugte Abtastfrequenz und ihre Latenzanforderungen an.

  • Beispielsweise könnte sich eine Anwendung beim Standardbeschleunigungsmesser registrieren, Ereignisse mit 100 Hz anfordern und die Meldung von Ereignissen mit einer Latenz von 1 Sekunde ermöglichen.
  • Die Anwendung empfängt Ereignisse vom Beschleunigungsmesser mit einer Frequenz von mindestens 100 Hz und möglicherweise bis zu einer 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 ein Single-Client. Ohne dieses Multiplexing auf Framework-Ebene könnte jeweils 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 weitere Anwendungen bei demselben Sensor registrieren, berücksichtigt das Framework die Anforderungen jeder Anwendung und sendet die aktualisierten angeforderten Parameter an den HAL.
    • Die Abtastfrequenz ist die maximale der angeforderten Abtastfrequenzen, was bedeutet, dass einige Anwendungen Ereignisse mit einer höheren Frequenz als der von ihnen angeforderten empfangen.
    • Die maximale Meldelatenz ist die minimale der angeforderten Latenzzeiten. 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 Anwendungen den Sensor mit einer maximalen Berichtslatenz ungleich Null angefordert haben. Weitere Einzelheiten finden Sie unter Batchverarbeitung .
  • Wenn die letzte bei einem Sensor registrierte Anwendung die Registrierung aufhebt, sendet das Framework eine Anfrage an die HAL, um den Sensor zu deaktivieren, damit nicht unnötig Strom verbraucht wird.

Auswirkungen des Multiplexings

Diese Notwendigkeit einer Multiplexschicht im Framework erklärt einige Designentscheidungen.

  • Wenn eine Anwendung eine bestimmte Abtastfrequenz anfordert, gibt es keine Garantie dafür, dass Ereignisse nicht schneller eintreffen. Wenn eine andere Anwendung denselben Sensor schneller angefordert hat, erhält die erste Anwendung diese ebenfalls schnell.
  • Der gleiche Mangel an Garantie gilt für die angeforderte maximale Berichtslatenz: Anwendungen empfangen Ereignisse möglicherweise mit viel kürzerer Latenz als angefordert.
  • 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 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 ein anderer einen Modus mit geringem Stromverbrauch 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 Kunden zufriedenzustellen, daher ist dies keine Option.
  • Es gibt keinen Mechanismus, um Daten von den Anwendungen an die Sensoren oder deren Treiber zu senden. Dadurch wird sichergestellt, dass eine Anwendung das Verhalten der Sensoren nicht ändern und dadurch andere Anwendungen beeinträchtigen kann.

Sensorfusion

Das Android-Framework bietet eine Standardimplementierung für einige zusammengesetzte Sensoren. 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 muss auf dem SoC ausgeführt werden, sodass sie nicht so genau und energieeffizient ist wie andere Implementierungen. Gerätehersteller sollten so weit wie möglich ihre eigenen fusionierten Sensoren definieren (Rotationsvektor, Schwerkraft und lineare Beschleunigung sowie neuere zusammengesetzte Sensoren wie der Game-Rotationsvektor ), anstatt sich auf diese Standardimplementierung zu verlassen. Gerätehersteller können auch Sensorchip-Anbieter auffordern, ihnen eine Implementierung zur Verfügung zu stellen.

Die Standardimplementierung der Sensorfusion wird nicht beibehalten und kann dazu führen, dass Geräte, die darauf angewiesen sind, CTS nicht bestehen.

Unter der Haube

Dieser Abschnitt dient als Hintergrundinformation für diejenigen, die den Framework-Code 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/ 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 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 Details 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 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, 1.0 wird jedoch bald nicht mehr unterstützt. Diese Dokumentation beschreibt das Verhalten der Version 1.3, auf die alle Geräte aktualisiert werden sollten. Einzelheiten zum Upgrade auf 1.3 finden Sie unter veraltete HAL-Version .

Kernel-Treiber

Die Sensortreiber interagieren mit den physischen Geräten. In einigen Fällen handelt es sich bei der HAL-Implementierung und den Treibern um dieselbe Softwareeinheit. In anderen Fällen fordert der Hardware-Integrator die Sensorchip-Hersteller auf, die Treiber bereitzustellen, aber sie sind diejenigen, die die HAL-Implementierung schreiben.

In allen Fällen liegen die HAL-Implementierung und die Kernel-Treiber in der Verantwortung der Hardwarehersteller, und Android bietet keine bevorzugten Ansätze zum Schreiben dieser Treiber.

Sensornabe

Der Sensorstapel eines Geräts kann optional einen Sensor-Hub enthalten, der nützlich ist, um einige Berechnungen auf niedriger Ebene bei geringem Stromverbrauch durchzuführen, während sich das SoC im Suspend-Modus befinden kann. Auf diesen Chips können beispielsweise Schrittzählung oder Sensorfusion durchgefü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: Um neue ContextHub-Funktionen zu entwickeln, die neue Sensoren oder LEDs verwenden, können Sie auch einen Neonkey SensorHub verwenden, der an ein Hikey- oder Hikey960-Entwicklungsboard angeschlossen ist.

Wie der Sensor-Hub materialisiert wird, hängt von der Architektur ab. Manchmal handelt es sich um einen separaten Chip und manchmal ist er auf demselben Chip wie der SoC enthalten. Wichtige Merkmale des Sensor-Hubs sind, dass er über ausreichend Speicher für die Stapelverarbeitung verfügen und nur 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, …) kommuniziert, wird von Android nicht spezifiziert, 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 verwenden: 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 MEM-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 Logik zur Durchführung üblicher Berechnungen wie Bewegungserkennung, Schritterkennung und 9-Achsen-Sensorfusion.

Obwohl die Leistungs- und Genauigkeitsanforderungen und -empfehlungen des CDD 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 des physischen Gyroskops. Es ist Sache des Geräteherstellers, die Anforderungen an physikalische Sensoren abzuleiten.