Dieser Abschnitt beschreibt Sensorachsen, Basissensoren und zusammengesetzte Sensoren (Aktivität, Lage, unkalibriert und Interaktion).
Sensorachsen
Sensorereigniswerte von vielen Sensoren werden in einem bestimmten Rahmen ausgedrückt, der relativ zum Gerät statisch ist.
Achsen für mobile Geräte
Die Sensor-API ist nur relativ zur natürlichen Ausrichtung des Bildschirms (Achsen werden nicht vertauscht, wenn sich die Bildschirmausrichtung des Geräts ändert.

Abbildung 1. Koordinatensystem (relativ zu einem mobilen Gerät), das von der Sensor-API verwendet wird
Kfz-Achsen
In Android Automotive-Implementierungen werden Achsen in Bezug auf den Fahrzeugkarosserierahmen definiert. Der Ursprung des Fahrzeugbezugssystems ist die Mitte der Hinterachse. Der Fahrzeugreferenzrahmen ist so ausgerichtet, dass:
- Die X-Achse zeigt nach rechts und liegt auf einer horizontalen Ebene senkrecht zur Symmetrieebene des Fahrzeugs.
- Die Y-Achse zeigt nach vorne und liegt auf einer horizontalen Ebene.

Abbildung 2. Koordinatensystem (relativ zu einem Fahrzeuggerät), das von der Sensor-API verwendet wird
Das Fahrzeugbezugssystem ist ein rechtshändiges Koordinatensystem. Daher zeigt die Z-Achse nach oben.
Die Z-Achse des Referenzrahmens ist auf die Schwerkraft ausgerichtet, was bedeutet, dass die X-Achse und die Y-Achse beide horizontal sind. Infolgedessen geht die Y-Achse möglicherweise nicht immer durch die Vorderachse.
Basissensoren
Basissensortypen werden nach den physischen Sensoren benannt, die sie darstellen. Diese Sensoren leiten Daten von einem einzelnen physischen Sensor weiter (im Gegensatz zu zusammengesetzten Sensoren, die Daten aus anderen Sensoren generieren). Beispiele für Basissensortypen sind:
-
SENSOR_TYPE_ACCELEROMETER
-
SENSOR_TYPE_GYROSCOPE
-
SENSOR_TYPE_MAGNETOMETER
Basissensoren sind jedoch nicht gleichbedeutend mit ihrem zugrunde liegenden physischen Sensor und sollten nicht mit ihm verwechselt werden. Die Daten von einem Basissensor sind nicht die Rohausgabe des physischen Sensors, da Korrekturen (wie z. B. Bias-Kompensation und Temperaturkompensation) angewendet werden.
Beispielsweise können sich die Eigenschaften eines Basissensors in den folgenden Anwendungsfällen von den Eigenschaften seines zugrunde liegenden physischen Sensors unterscheiden:
- Ein Gyroskop-Chip mit einem Bias-Bereich von 1 Grad/Sek.
- Nach der Werkskalibrierung werden Temperaturkompensation und Bias-Kompensation angewendet, die tatsächliche Bias des Android-Sensors wird reduziert, möglicherweise bis zu einem Punkt, an dem die Bias garantiert unter 0,01 Grad/Sekunde liegt.
- In dieser Situation sagen wir, dass der Android-Sensor eine Abweichung von weniger als 0,01 Grad/Sek. hat, obwohl das Datenblatt des zugrunde liegenden Sensors 1 Grad/Sek.
- Ein Barometer mit einer Leistungsaufnahme von 100 uW.
- Da die generierten Daten vom Chip zum SoC transportiert werden müssen, können die tatsächlichen Stromkosten zum Sammeln von Daten vom Barometer-Android-Sensor viel höher sein, beispielsweise 1000 uW.
- In dieser Situation sagen wir, dass der Android-Sensor einen Stromverbrauch von 1000 uW hat, obwohl der am Barometer-Chip gemessene Stromverbrauch 100 uW beträgt.
- Ein Magnetometer, das beim Kalibrieren 100 uW verbraucht, beim Kalibrieren jedoch mehr verbraucht.
- Seine Kalibrierungsroutine erfordert möglicherweise die Aktivierung des Gyroskops, das 5000 uW verbraucht, und die Ausführung eines Algorithmus, was weitere 900 uW kostet.
- In dieser Situation sagen wir, dass der maximale Stromverbrauch des (Magnetometer-) Android-Sensors 6000 uW beträgt.
- In diesem Fall ist der durchschnittliche Stromverbrauch das sinnvollere Maß, und es ist das, was in den statischen Eigenschaften des Sensors durch die HAL gemeldet wird.
Beschleunigungsmesser
Reporting-Modus: Kontinuierlich
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER)
gibt einen Nicht- Aktivierungssensor zurück
Ein Beschleunigungssensor meldet die Beschleunigung des Geräts entlang der drei Sensorachsen. Die gemessene Beschleunigung umfasst sowohl die physikalische Beschleunigung (Geschwindigkeitsänderung) als auch die Schwerkraft. Die Messung wird in den x-, y- und z-Feldern von sensors_event_t.acceleration gemeldet.
Alle Werte sind in SI-Einheiten (m/s^2) und messen die Beschleunigung des Geräts abzüglich der Schwerkraft entlang der drei Sensorachsen.
Hier sind Beispiele:
- Die Norm von (x, y, z) sollte im freien Fall nahe 0 sein.
- Wenn das Gerät flach auf einem Tisch liegt und auf der linken Seite nach rechts geschoben wird, ist der Beschleunigungswert x positiv.
- Wenn das Gerät flach auf einem Tisch liegt, beträgt der Beschleunigungswert entlang z +9,81 alo, was der Beschleunigung des Geräts (0 m/s^2) minus der Schwerkraft (-9,81 m/s^2) entspricht.
- Wenn das Gerät flach auf einem Tisch liegt und gen Himmel geschoben wird, ist der Beschleunigungswert größer als +9,81, was der Beschleunigung des Geräts (+A·m/s^2) minus der Schwerkraft (–9,81 m) entspricht /s^2).
Die Messwerte werden kalibriert mit:
- Temperaturkompensation
- Online-Bias-Kalibrierung
- Waagenkalibrierung online
Die Bias- und Skalenkalibrierung darf nur bei deaktiviertem Sensor aktualisiert werden, um beim Streaming keine Wertesprünge zu verursachen.
Der Beschleunigungsmesser meldet auch, wie genau seine Messwerte über sensors_event_t.acceleration.status
erwartet werden. Weitere Informationen zu möglichen Werten für dieses Feld finden Sie in den Konstanten SENSOR_STATUS_*
des SensorManager
.
Umgebungstemperatur
Meldemodus: Bei Änderung
getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE)
gibt einen Nicht- Aktivierungssensor zurück
Dieser Sensor liefert die Umgebungs- (Raum-) Temperatur in Grad Celsius.
Magnetfeldsensor
Reporting-Modus: Kontinuierlich
getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD)
gibt einen Nicht- Aktivierungssensor zurück
SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD
Ein Magnetfeldsensor (auch Magnetometer genannt) meldet das Umgebungsmagnetfeld, gemessen entlang der drei Sensorachsen.
Die Messung wird in den x-, y- und z-Feldern von sensors_event_t.magnetic
und alle Werte sind in Mikro-Tesla (uT) angegeben.
Das Magnetometer meldet auch, wie genau es seine Messwerte erwartet, durch sensors_event_t.magnetic.status
. Weitere Informationen zu möglichen Werten für dieses Feld finden Sie in den Konstanten SENSOR_STATUS_*
des SensorManager
.
Die Messwerte werden kalibriert mit:
- Temperaturkompensation
- Werkseitige (oder Online-) Weicheisenkalibrierung
- Online-Harteisenkalibrierung
Gyroskop
Reporting-Modus: Kontinuierlich
getDefaultSensor(SENSOR_TYPE_GYROSCOPE)
gibt einen Nicht- Aktivierungssensor zurück
Ein Gyroskopsensor meldet die Rotationsgeschwindigkeit des Geräts um die drei Sensorachsen.
Die Rotation im Gegenuhrzeigersinn ist positiv (Rechte-Hand-Regel). Das heißt, ein Beobachter, der von einem positiven Ort auf der x-, y- oder z-Achse auf ein Gerät blickt, das auf dem Ursprung positioniert ist, würde eine positive Drehung melden, wenn das Gerät scheinbar gegen den Uhrzeigersinn rotiert. Beachten Sie, dass dies die mathematische Standarddefinition der positiven Rotation ist und nicht mit der Luft- und Raumfahrtdefinition des Rollens übereinstimmt.
Die Messung wird in den x-, y- und z-Feldern von sensors_event_t.gyro
und alle Werte sind in Radiant pro Sekunde (rad/s).
Die Messwerte werden kalibriert mit:
- Temperaturkompensation
- Waagenkompensation ab Werk (oder online).
- Online-Bias-Kalibrierung (um Drift zu entfernen)
Das Gyroskop meldet auch, wie genau seine Messwerte über sensors_event_t.gyro.status
erwartet werden. Weitere Informationen zu möglichen Werten für dieses Feld finden Sie in den Konstanten SENSOR_STATUS_*
des SensorManager
.
Das Gyroskop kann nicht basierend auf Magnetometern und Beschleunigungsmessern emuliert werden, da dies dazu führen würde, dass es eine verringerte lokale Konsistenz und Reaktionsfähigkeit aufweist. Es muss auf einem üblichen Gyroskop-Chip basieren.
Pulsschlag
Meldemodus: Bei Änderung
getDefaultSensor(SENSOR_TYPE_HEART_RATE)
gibt einen Nicht- Aktivierungssensor zurück
Ein Herzfrequenzsensor meldet die aktuelle Herzfrequenz der Person, die das Gerät berührt.
Die aktuelle Herzfrequenz in Schlägen pro Minute (BPM) wird in sensors_event_t.heart_rate.bpm
gemeldet und der Status des Sensors wird in sensors_event_t.heart_rate.status
gemeldet. Weitere Informationen zu möglichen Werten für dieses Feld finden Sie in den Konstanten SENSOR_STATUS_*
des SensorManager
. Insbesondere muss bei der ersten Aktivierung das Statusfeld des ersten Ereignisses auf SENSOR_STATUS_UNRELIABLE
gesetzt werden, es sei denn, es ist bekannt, dass sich das Gerät nicht am Körper befindet. Da sich dieser Sensor bei Änderungen befindet, werden Ereignisse nur dann generiert, wenn sich heart_rate.bpm
oder heart_rate.status
seit dem letzten Ereignis geändert haben. Die Ereignisse werden nicht schneller als jede sampling_period
generiert.
sensor_t.requiredPermission
ist immer SENSOR_PERMISSION_BODY_SENSORS
.
Licht
Meldemodus: Bei Änderung
getDefaultSensor(SENSOR_TYPE_LIGHT)
gibt einen Nicht- Aktivierungssensor zurück
Ein Lichtsensor meldet die aktuelle Beleuchtung in SI-Lux-Einheiten.
Die Messung wird in sensors_event_t.light
gemeldet.
Nähe
Meldemodus: Bei Änderung
Üblicherweise als Wecksensor definiert
getDefaultSensor(SENSOR_TYPE_PROXIMITY)
gibt einen Wecksensor zurück
Ein Näherungssensor meldet die Entfernung vom Sensor zur nächsten sichtbaren Oberfläche.
Bis Android 4.4 waren die Näherungssensoren immer Wecksensoren, die den SoC aufweckten, wenn sie eine Änderung der Nähe erkannten. Nach Android 4.4 empfehlen wir, zuerst die Wake-up-Version dieses Sensors zu implementieren, da dieser zum Ein- und Ausschalten des Bildschirms beim Telefonieren verwendet wird.
Die Messung wird in Sensoren_event_t.distance in Zentimetern sensors_event_t.distance
. Beachten Sie, dass einige Näherungssensoren nur eine binäre „Nah“- oder „Fern“-Messung unterstützen. In diesem Fall meldet der Sensor im Zustand „fern“ seinen Wert sensor_t.maxRange
und im Zustand „nah“ einen Wert kleiner als sensor_t.maxRange
.
Druck
Reporting-Modus: Kontinuierlich
getDefaultSensor(SENSOR_TYPE_PRESSURE)
gibt einen nicht aktivierten Sensor zurück
Ein Drucksensor (auch Barometer genannt) meldet den Luftdruck in Hektopascal (hPa).
Die Messwerte werden mit kalibriert
- Temperaturkompensation
- Werkseitige Bias-Kalibrierung
- Kalibrierung im Werksmaßstab
Das Barometer wird oft verwendet, um Höhenänderungen abzuschätzen. Um die absolute Höhe abzuschätzen, muss der Meeresspiegeldruck (der sich je nach Wetter ändert) als Referenz verwendet werden.
Relative Luftfeuchtigkeit
Meldemodus: Bei Änderung
getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY)
gibt einen Nicht- Aktivierungssensor zurück
Ein Relative-Feuchte-Sensor misst die relative Luftfeuchtigkeit der Umgebung und gibt einen Wert in Prozent zurück.
Zusammengesetzte Sensortypen
Ein zusammengesetzter Sensor erzeugt Daten, indem er Daten von einem oder mehreren physikalischen Sensoren verarbeitet und/oder fusioniert. (Jeder Sensor, der kein Basissensor ist, wird als zusammengesetzter Sensor bezeichnet.) Beispiele für zusammengesetzte Sensoren sind:
- Schrittdetektor und signifikante Bewegung , die normalerweise auf einem Beschleunigungsmesser basieren, aber auch auf anderen Sensoren basieren könnten, wenn der Stromverbrauch und die Genauigkeit akzeptabel wären.
- Spielrotationsvektor , basierend auf einem Beschleunigungsmesser und einem Gyroskop.
- Unkalibriertes Gyroskop , das dem Gyroskop-Basissensor ähnelt, wobei jedoch die Bias-Kalibrierung separat gemeldet wird, anstatt in der Messung korrigiert zu werden.
Wie bei Basissensoren stammen die Eigenschaften der zusammengesetzten Sensoren aus den Eigenschaften ihrer endgültigen Daten. Beispielsweise ist der Stromverbrauch eines Spielrotationsvektors wahrscheinlich gleich der Summe des Stromverbrauchs des Beschleunigungsmesser-Chips, des Gyroskop-Chips, des Chips, der die Daten verarbeitet, und der Busse, die die Daten transportieren. Als weiteres Beispiel hängt die Drift eines Wildrotationsvektors sowohl von der Qualität des Kalibrierungsalgorithmus als auch von den physikalischen Sensoreigenschaften ab.
Die folgende Tabelle listet verfügbare Verbundsensortypen auf. Jeder zusammengesetzte Sensor stützt sich auf Daten von einem oder mehreren physikalischen Sensoren. Vermeiden Sie es, andere zugrunde liegende physische Sensoren auszuwählen, um die Ergebnisse anzunähern, da diese eine schlechte Benutzererfahrung bieten.
Sensorart | Kategorie | Zugrunde liegende physikalische Sensoren | Meldemodus |
---|---|---|---|
Attitüde | Beschleunigungsmesser, Gyroskop, Magnetometer DÜRFEN NICHT VERWENDET WERDEN | Kontinuierlich | |
Attitüde | Beschleunigungsmesser, Magnetometer, Gyroskop DARF NICHT VERWENDET WERDEN | Kontinuierlich | |
Blickgeste ![]() | Interaktion | Nicht definiert | One-Shot |
Attitüde | Beschleunigungsmesser, Gyroskop | Kontinuierlich | |
Unkalibriert | Gyroskop | Kontinuierlich | |
Aktivität | Beschleunigungsmesser, Gyroskop (falls vorhanden) oder Magnetometer (falls kein Gyroskop vorhanden) | Kontinuierlich | |
Unkalibriert | Magnetometer | Kontinuierlich | |
Ausrichtung (veraltet) | Attitüde | Beschleunigungsmesser, Magnetometer, Gyroskop (falls vorhanden) | Kontinuierlich |
Interaktion | Nicht definiert | One-Shot | |
Attitüde | Beschleunigungsmesser, Magnetometer, Gyroskop | Kontinuierlich | |
Aktivität | Beschleunigungsmesser (oder ein anderer, solange sehr geringer Stromverbrauch) | One-Shot | |
Aktivität | Beschleunigungsmesser | Bei Änderung | |
Aktivität | Beschleunigungsmesser | Speziell | |
Aktivität | Beschleunigungsmesser | Speziell | |
Interaktion | Nicht definiert | One-Shot |
= Low-Power-Sensor
Aktivitäts-Verbundsensoren
Lineare Beschleunigung
Zugrunde liegende physikalische Sensoren: Beschleunigungsmesser und (falls vorhanden) Gyroskop (oder Magnetometer, falls Gyroskop nicht vorhanden)
Reporting-Modus: Kontinuierlich
getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION)
gibt einen Nicht- Aktivierungssensor zurück
Ein linearer Beschleunigungssensor meldet die lineare Beschleunigung des Geräts im Sensorrahmen, ohne die Schwerkraft.
Die Ausgabe ist konzeptionell: Ausgabe des Beschleunigungsmessers minus Ausgabe des Schwerkraftsensors . Sie wird in m/s^2 in den x-, y- und z-Feldern von sensors_event_t.acceleration
.
Die Messwerte auf allen Achsen sollten nahe 0 sein, wenn das Gerät nicht bewegt wird.
Wenn das Gerät über ein Gyroskop verfügt, muss der lineare Beschleunigungssensor das Gyroskop und den Beschleunigungsmesser als Eingang verwenden.
Wenn das Gerät kein Gyroskop besitzt, muss der lineare Beschleunigungssensor den Beschleunigungsmesser und den Magnetometer als Eingang verwenden.
Bedeutende Bewegung
Zugrundeliegender physikalischer Sensor: Beschleunigungsmesser (oder ein anderer, solange er wenig Strom hat)
Meldemodus: One-Shot
Geringer Strom
Implementieren Sie nur die Aktivierungsversion dieses Sensors.
getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION)
gibt einen Wecksensor zurück
Ein Detektor für signifikante Bewegungen löst aus, wenn er eine signifikante Bewegung erkennt: eine Bewegung, die zu einer Änderung des Standorts des Benutzers führen könnte.
Beispiele für solche bedeutenden Bewegungen sind:
- Wandern oder Radfahren
- Sitzen in einem fahrenden Auto, Bus oder Zug
Beispiele für Situationen, die keine signifikante Bewegung auslösen:
- Telefon in der Tasche und Person bewegt sich nicht
- Das Telefon liegt auf einem Tisch und der Tisch wackelt ein wenig aufgrund des Verkehrs oder der Waschmaschine in der Nähe
Auf der hohen Ebene wird der signifikante Bewegungsdetektor verwendet, um den Stromverbrauch der Standortbestimmung zu reduzieren. Wenn die Lokalisierungsalgorithmen erkennen, dass das Gerät statisch ist, können sie in einen Energiesparmodus wechseln, in dem sie auf eine erhebliche Bewegung angewiesen sind, um das Gerät aufzuwecken, wenn der Benutzer den Standort wechselt.
Dieser Sensor muss eine geringe Leistung haben. Es macht einen Kompromiss für den Stromverbrauch, der zu einer kleinen Menge falscher negativer Ergebnisse führen kann. Dies geschieht aus mehreren Gründen:
- Das Ziel dieses Sensors ist es, Strom zu sparen.
- Das Auslösen eines Ereignisses, wenn sich der Benutzer nicht bewegt (falsch positiv), ist energieintensiv und sollte daher vermieden werden.
- Es ist akzeptabel, kein Ereignis auszulösen, wenn sich der Benutzer bewegt (falsch negativ), solange dies nicht wiederholt geschieht. Wenn der Benutzer 10 Sekunden lang gegangen ist, ist es nicht akzeptabel, innerhalb dieser 10 Sekunden kein Ereignis auszulösen.
Jedes Sensorereignis meldet 1
in sensors_event_t.data[0]
.
Schrittdetektor
Zugrundeliegender physikalischer Sensor: Beschleunigungsmesser (+ möglicherweise andere, solange niedriger Stromverbrauch)
Meldemodus: Spezial (ein Ereignis pro gemachtem Schritt)
Geringer Strom
getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR)
gibt einen Nicht- Aktivierungssensor zurück
Ein Schrittdetektor generiert jedes Mal ein Ereignis, wenn der Benutzer einen Schritt macht.
Der Zeitstempel des Ereignisses sensors_event_t.timestamp
entspricht dem Aufsetzen des Fußes auf den Boden, wodurch eine hohe Beschleunigungsschwankung erzeugt wird.
Im Vergleich zum Schrittzähler sollte der Schrittdetektor eine geringere Latenz haben (weniger als zwei Sekunden). Sowohl der Schrittdetektor als auch der Schrittzähler erkennen, wenn der Benutzer geht, läuft und die Treppe hinaufgeht. Sie sollten nicht ausgelöst werden, wenn der Benutzer Rad fährt, fährt oder in anderen Fahrzeugen sitzt.
Dieser Sensor muss eine geringe Leistung haben. Das heißt, wenn die Schritterkennung nicht in Hardware durchgeführt werden kann, sollte dieser Sensor nicht definiert werden. Insbesondere wenn der Schrittdetektor aktiviert ist und der Beschleunigungsmesser nicht, sollten nur Schritte Interrupts auslösen (nicht jeder Messwert des Beschleunigungsmessers).
sampling_period_ns
hat keinen Einfluss auf Schrittdetektoren.
Jedes Sensorereignis meldet 1
in sensors_event_t.data[0]
.
Schrittzähler
Zugrundeliegender physikalischer Sensor: Beschleunigungsmesser (+ möglicherweise andere, solange niedriger Stromverbrauch)
Meldemodus: Bei Änderung
Geringer Strom
getDefaultSensor(SENSOR_TYPE_STEP_COUNTER)
gibt einen Nicht- Aktivierungssensor zurück
Ein Schrittzähler meldet die Anzahl der Schritte, die der Benutzer seit dem letzten Neustart im aktivierten Zustand zurückgelegt hat.
Die Messung wird als uint64_t
in sensors_event_t.step_counter
und nur bei einem Systemneustart auf Null zurückgesetzt.
Der Zeitstempel des Ereignisses wird auf die Zeit gesetzt, zu der der letzte Schritt für dieses Ereignis unternommen wurde.
Siehe Sensortyp Schrittdetektor für die Bedeutung der Zeit eines Schritts.
Im Vergleich zum Schrittdetektor kann der Schrittzähler eine höhere Latenz haben (bis zu 10 Sekunden). Dank dieser Latenz hat dieser Sensor eine hohe Genauigkeit; Die Schrittzahl nach einem ganzen Tag mit Maßnahmen sollte innerhalb von 10 % der tatsächlichen Schrittzahl liegen. Sowohl der Schrittdetektor als auch der Schrittzähler erkennen, wenn der Benutzer geht, läuft und die Treppe hinaufgeht. Sie sollten nicht ausgelöst werden, wenn der Benutzer Rad fährt, fährt oder in anderen Fahrzeugen sitzt.
Die Hardware muss sicherstellen, dass die interne Schrittzahl niemals überläuft. Die Mindestgröße des internen Zählers der Hardware soll 16 Bit betragen. Im Falle eines bevorstehenden Überlaufs (höchstens alle ~2^16 Schritte) kann der SoC aufgeweckt werden, damit der Treiber die Zählerwartung durchführen kann.
Wie in Interaktion angegeben, darf dieser Sensor, während er arbeitet, keine anderen Sensoren stören, insbesondere den Beschleunigungsmesser, der sehr wohl in Gebrauch sein könnte.
Wenn ein bestimmtes Gerät diese Betriebsarten nicht unterstützen kann, darf dieser Sensortyp nicht von der HAL gemeldet werden. Das heißt, es ist nicht akzeptabel, diesen Sensor in der HAL zu "emulieren".
Dieser Sensor muss eine geringe Leistung haben. Das heißt, wenn die Schritterkennung nicht in Hardware erfolgen kann, sollte dieser Sensor nicht definiert werden. Insbesondere wenn der Schrittzähler aktiviert ist und der Beschleunigungsmesser nicht, sollten nur Schritte Interrupts auslösen (keine Beschleunigungsmesserdaten).
Neigungsdetektor
Zugrundeliegender physikalischer Sensor: Beschleunigungsmesser (+ möglicherweise andere, solange niedriger Stromverbrauch)
Meldemodus: Spezial
Geringer Strom
Implementieren Sie nur die Aktivierungsversion dieses Sensors.
getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR)
gibt einen Wecksensor zurück
Ein Neigungsdetektor erzeugt jedes Mal ein Ereignis, wenn ein Neigungsereignis erkannt wird.
Ein Neigungsereignis wird durch die Richtung der durchschnittlichen Schwerkraft des 2-Sekunden-Fensters definiert, die sich seit der Aktivierung oder dem letzten vom Sensor erzeugten Ereignis um mindestens 35 Grad ändert. Hier ist der Algorithmus:
-
reference_estimated_gravity
= Durchschnitt der Beschleunigungsmessermessungen über die erste Sekunde nach der Aktivierung oder die geschätzte Schwerkraft, als das letzte Neigungsereignis erzeugt wurde. -
current_estimated_gravity
= Durchschnitt der Beschleunigungsmessermessungen der letzten 2 Sekunden. - Trigger wenn
angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees
Große Beschleunigungen ohne Änderung der Telefonausrichtung sollten kein Neigungsereignis auslösen. Beispielsweise sollte eine scharfe Kurve oder starke Beschleunigung beim Autofahren kein Neigungsereignis auslösen, auch wenn der Winkel der durchschnittlichen Beschleunigung um mehr als 35 Grad variieren kann. Typischerweise wird dieser Sensor nur mit Hilfe eines Beschleunigungsmessers implementiert. Andere Sensoren können ebenfalls verwendet werden, wenn sie den Stromverbrauch nicht wesentlich erhöhen. Dies ist ein Low-Power-Sensor, der es dem SoC ermöglichen sollte, in den Suspend-Modus zu wechseln. Emulieren Sie diesen Sensor nicht in der HAL. Jedes Sensorereignis meldet 1
in sensors_event_t.data[0]
.
Composite-Sensoren für die Lage
Rotationsvektor
Zugrunde liegende physikalische Sensoren: Beschleunigungsmesser, Magnetometer und Gyroskop
Reporting-Modus: Kontinuierlich
getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR)
gibt einen Nicht- Aktivierungssensor zurück
Ein Rotationsvektorsensor meldet die Ausrichtung des Geräts relativ zum Ost-Nord-Oben-Koordinatenrahmen. Es wird normalerweise durch Integration von Beschleunigungsmesser-, Gyroskop- und Magnetometermesswerten erhalten. Das East-North-Up-Koordinatensystem ist als direkte orthonormale Basis definiert, wobei:
- X zeigt nach Osten und ist tangential zum Boden.
- Y zeigt nach Norden und ist tangential zum Boden.
- Z zeigt zum Himmel und steht senkrecht zum Boden.
Die Ausrichtung des Telefons wird durch die Drehung dargestellt, die erforderlich ist, um die Ost-Nord-Oben-Koordinaten mit den Koordinaten des Telefons auszurichten. Das heißt, das Anwenden der Drehung auf den Weltrahmen (X, Y, Z) würde sie an den Telefonkoordinaten (x, y, z) ausrichten.
Die Drehung kann als Drehen des Telefons um einen Winkel Theta um eine Achse rot_axis
werden, um von der Referenzgeräteausrichtung (Ost-Nord-oben ausgerichtet) zu der aktuellen Geräteausrichtung zu gelangen. Die Drehung wird als die vier einheitslosen x-, y-, z-, w-Komponenten einer Einheitsquaternion kodiert:
-
sensors_event_t.data[0] = rot_axis.x*sin(theta/2)
-
sensors_event_t.data[1] = rot_axis.y*sin(theta/2)
-
sensors_event_t.data[2] = rot_axis.z*sin(theta/2)
-
sensors_event_t.data[3] = cos(theta/2)
Wo:
- Die x-, y- und z-Felder von
rot_axis
sind die Ost-Nord-Oben-Koordinaten eines Einheitslängenvektors, der die Rotationsachse darstellt -
theta
ist der Rotationswinkel
Die Quaternion ist eine Einheitsquaternion: Sie muss die Norm 1
haben. Wird dies nicht sichergestellt, führt dies zu fehlerhaftem Verhalten des Clients.
Zusätzlich meldet dieser Sensor eine geschätzte Kursgenauigkeit:
sensors_event_t.data[4] = estimated_accuracy
(in Radiant)
Der Steuerkursfehler muss in 95 % der Fälle kleiner als estimated_accuracy
sein. Dieser Sensor muss ein Gyroskop als Haupteingabe für die Orientierungsänderung verwenden.
Dieser Sensor verwendet auch Beschleunigungsmesser- und Magnetometereingaben, um die Gyroskopdrift auszugleichen, und er kann nicht nur mit Beschleunigungsmesser und Magnetometer implementiert werden.
Rotationsvektor des Spiels
Zugrunde liegende physikalische Sensoren: Beschleunigungsmesser und Gyroskop (kein Magnetometer)
Reporting-Modus: Kontinuierlich
getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR)
gibt einen Nicht- Aktivierungssensor zurück
Ein Wildrotationsvektorsensor ähnelt einem Rotationsvektorsensor, verwendet jedoch nicht das Erdmagnetfeld. Daher zeigt die Y-Achse nicht nach Norden, sondern auf eine andere Referenz. Diese Referenz darf um die gleiche Größenordnung driften wie das Gyroskop um die Z-Achse driftet.
Einzelheiten zum Festlegen von sensors_event_t.data[0-3]
Sie unter Rotationsvektorsensor . Dieser Sensor meldet keine geschätzte Kursgenauigkeit: sensors_event_t.data[4]
ist reserviert und sollte auf 0
gesetzt werden.
Im Idealfall sollte ein Telefon, das gedreht und in dieselbe reale Ausrichtung zurückgebracht wird, denselben Spielrotationsvektor melden.
Dieser Sensor muss auf einem Gyroskop und einem Beschleunigungsmesser basieren. Es kann kein Magnetometer als Eingabe verwenden, außer indirekt durch Schätzung der Gyroskop-Vorspannung.
Schwere
Zugrunde liegende physikalische Sensoren: Beschleunigungsmesser und (falls vorhanden) Gyroskop (oder Magnetometer, falls Gyroskop nicht vorhanden)
Reporting-Modus: Kontinuierlich
getDefaultSensor(SENSOR_TYPE_GRAVITY)
gibt einen nicht aktivierten Sensor zurück
Ein Schwerkraftsensor meldet die Richtung und Größe der Schwerkraft in den Koordinaten des Geräts.
Die Gravitationsvektorkomponenten werden in m/s^2 in den x-, y- und z-Feldern von sensors_event_t.acceleration
.
Wenn sich das Gerät im Ruhezustand befindet, sollte die Ausgabe des Schwerkraftsensors mit der des Beschleunigungsmessers identisch sein. Auf der Erde beträgt die Magnitude etwa 9,8 m/s^2.
Wenn das Gerät über ein Gyroskop verfügt, muss der Schwerkraftsensor das Gyroskop und den Beschleunigungsmesser als Eingang verwenden.
Wenn das Gerät kein Gyroskop besitzt, muss der Schwerkraftsensor den Beschleunigungsmesser und den Magnetometer als Eingang verwenden.
Geomagnetischer Rotationsvektor
Zugrunde liegende physikalische Sensoren: Beschleunigungsmesser und Magnetometer (kein Gyroskop)
Reporting-Modus: Kontinuierlich
Geringer Strom
getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR)
gibt einen Nicht- Aktivierungssensor zurück
Ein geomagnetischer Rotationsvektor ähnelt einem Rotationsvektorsensor, verwendet jedoch ein Magnetometer und kein Gyroskop.
Dieser Sensor muss auf einem Magnetometer basieren. Es kann nicht mit einem Gyroskop implementiert werden, und der Gyroskopeingang kann von diesem Sensor nicht verwendet werden.
Einzelheiten zum Festlegen von sensors_event_t.data[0-4]
Sie unter Rotationsvektorsensor .
Genau wie beim Rotationsvektorsensor muss der Kursfehler zu 95 % der Zeit unter der geschätzten Genauigkeit ( sensors_event_t.data[4]
) liegen.
Dieser Sensor muss einen geringen Stromverbrauch haben, also muss er in Hardware implementiert werden.
Ausrichtung (veraltet)
Zugrunde liegende physikalische Sensoren: Beschleunigungsmesser, Magnetometer und (falls vorhanden) Gyroskop
Reporting-Modus: Kontinuierlich
getDefaultSensor(SENSOR_TYPE_ORIENTATION)
gibt einen Nicht- Aktivierungssensor zurück
Hinweis: Dies ist ein älterer Sensortyp, der im Android SDK veraltet ist. Er wurde durch den klarer definierten Rotationsvektorsensor ersetzt. Verwenden Sie nach Möglichkeit den Rotationsvektorsensor anstelle des Ausrichtungssensors.
Ein Orientierungssensor meldet die Lage des Geräts. Die Messungen werden in Grad in den x-, y- und z-Feldern von sensors_event_t.orientation
:
-
sensors_event_t.orientation.x
: Azimut, der Winkel zwischen der magnetischen Nordrichtung und der Y-Achse um die Z-Achse (0<=azimuth<360
). 0=Norden, 90=Osten, 180=Süden, 270=Westen. -
sensors_event_t.orientation.y
: Pitch, Drehung um die X-Achse (-180<=pitch<=180
), mit positiven Werten, wenn sich die Z-Achse in Richtung der Y-Achse bewegt. -
sensors_event_t.orientation.z
: roll, Drehung um die Y-Achse (-90<=roll<=90
), mit positiven Werten, wenn sich die X-Achse in Richtung der Z-Achse bewegt.
Bitte beachten Sie, dass der Rollwinkel aus historischen Gründen im Uhrzeigersinn positiv ist. (Mathematisch gesehen sollte es gegen den Uhrzeigersinn positiv sein):

Abbildung 3. Ausrichtung relativ zu einem Gerät
Diese Definition unterscheidet sich von Gieren, Nicken und Rollen, die in der Luftfahrt verwendet werden, wo sich die X-Achse entlang der langen Seite des Flugzeugs (Heck bis Nase) befindet.
Der Orientierungssensor meldet auch, wie genau seine Messwerte über sensors_event_t.orientation.status
erwartet werden. Weitere Informationen zu möglichen Werten für dieses Feld finden Sie in den Konstanten SENSOR_STATUS_*
des SensorManager
.
Nicht kalibrierte Sensoren
Unkalibrierte Sensoren liefern rohere Ergebnisse und können eine gewisse Abweichung enthalten, enthalten aber auch weniger "Sprünge" von Korrekturen, die durch Kalibrierung angewendet werden. Einige Apps bevorzugen diese unkalibrierten Ergebnisse möglicherweise als glatter und zuverlässiger. Wenn beispielsweise eine App versucht, ihre eigene Sensorfusion durchzuführen, kann das Einführen von Kalibrierungen die Ergebnisse tatsächlich verfälschen.
Beschleunigungsmesser nicht kalibriert
Zugrunde liegender physikalischer Sensor: Beschleunigungsmesser
Reporting-Modus: Kontinuierlich
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED)
gibt einen nicht aktivierten Sensor zurück
Ein unkalibrierter Beschleunigungssensor meldet die Beschleunigung des Geräts entlang der drei Sensorachsen ohne Bias-Korrektur (werkseitige Bias und Temperaturkompensation werden auf unkalibrierte Messungen angewendet) zusammen mit einer Bias-Schätzung. Alle Werte sind in SI-Einheiten (m/s^2) und werden in den Feldern von sensors_event_t.uncalibrated_accelerometer
:
-
x_uncalib
: Beschleunigung (ohne Bias-Kompensation) entlang der X-Achse -
y_uncalib
: Beschleunigung (ohne Bias-Kompensation) entlang der Y-Achse -
z_uncalib
: Beschleunigung (ohne Bias-Kompensation) entlang der Z-Achse -
x_bias
: geschätzte Abweichung entlang der X-Achse -
y_bias
: geschätzte Abweichung entlang der Y-Achse -
z_bias
: geschätzte Abweichung entlang der Z-Achse
Gyroskop unkalibriert
Zugrundeliegender physikalischer Sensor: Gyroskop
Reporting-Modus: Kontinuierlich
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED)
gibt einen nicht aktivierten Sensor zurück
Ein unkalibriertes Gyroskop meldet die Rotationsgeschwindigkeit um die Sensorachsen, ohne eine Bias-Kompensation auf sie anzuwenden, zusammen mit einer Bias-Schätzung. Alle Werte sind in Radiant/Sekunde und werden in den Feldern von sensors_event_t.uncalibrated_gyro
:
-
x_uncalib
: Winkelgeschwindigkeit (ohne Driftkompensation) um die X-Achse -
y_uncalib
: Winkelgeschwindigkeit (ohne Driftkompensation) um die Y-Achse -
z_uncalib
: Winkelgeschwindigkeit (ohne Driftkompensation) um die Z-Achse -
x_bias
: geschätzte Drift um die X-Achse -
y_bias
: geschätzte Abweichung um die Y-Achse -
z_bias
: geschätzte Drift um die Z-Achse
Konzeptionell ist die unkalibrierte Messung die Summe der kalibrierten Messung und der Bias-Schätzung: _uncalibrated = _calibrated + _bias
.
Es wird erwartet, dass die Werte x_bias
, y_bias
und z_bias
springen, sobald sich die Schätzung der Abweichung ändert, und sie sollten für den Rest der Zeit stabil sein.
Einzelheiten zum verwendeten Koordinatensystem finden Sie in der Definition des Gyroskopsensors .
Die Messungen müssen werkseitig kalibriert und temperaturkompensiert werden. Außerdem muss eine Gyroskop-Driftschätzung implementiert werden, damit vernünftige Schätzungen in x_bias
, y_bias
und z_bias
gemeldet werden können. Wenn die Implementierung die Drift nicht abschätzen kann, darf dieser Sensor nicht implementiert werden.
Wenn dieser Sensor vorhanden ist, muss auch der entsprechende Gyroskop-Sensor vorhanden sein und beide Sensoren müssen dieselben sensor_t.name
und sensor_t.vendor
Werte aufweisen.
Magnetfeld unkalibriert
Zugrundeliegender physikalischer Sensor: Magnetometer
Reporting-Modus: Kontinuierlich
getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED)
gibt einen nicht aktivierten Sensor zurück
Ein unkalibrierter Magnetfeldsensor meldet das Umgebungsmagnetfeld zusammen mit einer Schätzung der Harteisenkalibrierung. Alle Werte sind in Mikro-Tesla (uT) angegeben und werden in den Feldern von sensors_event_t.uncalibrated_magnetic
:
-
x_uncalib
: Magnetfeld (ohne Harteisenkompensation) entlang der X-Achse -
y_uncalib
: Magnetfeld (ohne Harteisenkompensation) entlang der Y-Achse -
z_uncalib
: Magnetfeld (ohne Harteisenkompensation) entlang der Z-Achse -
x_bias
: geschätzte Vorspannung entlang der X-Achse -
y_bias
: geschätzte Vorspannung entlang der Y-Achse -
z_bias
: geschätzte Vorspannung entlang der Z-Achse
Konzeptionell ist die unkalibrierte Messung die Summe der kalibrierten Messung und der Bias-Schätzung: _uncalibrated = _calibrated + _bias
.
Das unkalibrierte Magnetometer ermöglicht Algorithmen auf höherer Ebene, eine schlechte Harteisenschätzung zu handhaben. Es wird erwartet, dass die Werte x_bias
, y_bias
und z_bias
springen, sobald sich die Schätzung des Harteisens ändert, und sie sollten den Rest der Zeit stabil bleiben.
Die Messungen müssen mit Weicheisenkalibrierung und Temperaturkompensation durchgeführt werden. Außerdem muss eine harte Eisenschätzung implementiert werden, damit vernünftige Schätzungen in x_bias
, y_bias
und z_bias
gemeldet werden können. Wenn die Implementierung den Bias nicht schätzen kann, darf dieser Sensor nicht implementiert werden.
Wenn dieser Sensor vorhanden ist, muss der entsprechende Magnetfeldsensor vorhanden sein und beide Sensoren müssen dieselben sensor_t.name
und sensor_t.vendor
Werte aufweisen.
Scharnierwinkel
Meldemodus: Bei Änderung
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
gibt einen Wecksensor zurück
Ein Scharnierwinkelsensor misst den Winkel in Grad zwischen zwei integralen Teilen des Geräts. Es wird erwartet, dass die von diesem Sensortyp gemessene Bewegung eines Scharniers die Art und Weise verändert, wie der Benutzer mit dem Gerät interagieren kann, beispielsweise durch Aufklappen oder Aufdecken eines Displays.
Interaktionsverbundsensoren
Einige Sensoren werden hauptsächlich verwendet, um Interaktionen mit dem Benutzer zu erkennen. We don't define how those sensors must be implemented, but they must be low power and it's the responsibility of the device manufacturer to verify their quality in terms of user experience.
Wake up gesture
Underlying physical sensors: Undefined (anything low power)
Reporting-mode: One-shot
Low-power
Implement only the wake-up version of this sensor.
getDefaultSensor(SENSOR_TYPE_WAKE_GESTURE)
returns a wake-up sensor
A wake up gesture sensor enables waking up the device based on a device specific motion. When this sensor triggers, the device behaves as if the power button was pressed, turning the screen on. This behavior (turning on the screen when this sensor triggers) might be deactivated by the user in the device settings. Changes in settings don't impact the behavior of the sensor: only whether the framework turns the screen on when it triggers. The actual gesture to be detected isn't specified, and can be chosen by the manufacturer of the device.
This sensor must be low power, as it's likely to be activated 24/7.
Each sensor event reports 1
in sensors_event_t.data[0]
.
Pick up gesture
Underlying physical sensors: Undefined (anything low power)
Reporting-mode: One-shot
Low-power
Implement only the wake-up version of this sensor.
getDefaultSensor(SENSOR_TYPE_PICK_UP_GESTURE)
returns a wake-up sensor
A pick-up gesture sensor triggers when the device is picked up regardless of wherever it was before (desk, pocket, bag).
Each sensor event reports 1
in sensors_event_t.data[0]
.
Glance gesture
Underlying physical sensors: Undefined (anything low power)
Reporting-mode: One-shot
Low-power
Implement only the wake-up version of this sensor.
getDefaultSensor(SENSOR_TYPE_GLANCE_GESTURE)
returns a wake-up sensor
A glance gesture sensor enables briefly turning the screen on to enable the user to glance content on screen based on a specific motion. When this sensor triggers, the device will turn the screen on momentarily to allow the user to glance notifications or other content while the device remains locked in a non-interactive state (dozing), then the screen will turn off again. This behavior (briefly turning on the screen when this sensor triggers) might be deactivated by the user in the device settings. Changes in settings do not impact the behavior of the sensor: only whether the framework briefly turns the screen on when it triggers. The actual gesture to be detected isn't specified, and can be chosen by the manufacturer of the device.
This sensor must be low power, as it's likely to be activated 24/7. Each sensor event reports 1
in sensors_event_t.data[0]
.