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 Radianten)
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]
.
Limited axes IMU sensors
Available from Android 13, limited axes IMU sensors are sensors that support use cases where not all three axes (x, y, z) are available. Standard IMU types in Android (such as SENSOR_TYPE_ACCELEROMETER
and SENSOR_TYPE_GYROSCOPE
) assume that all three axes are supported. However, not all form factors and devices support 3-axis accelerometers and 3-axis gyroscopes.
Accelerometer limited axes
Underlying physical sensors: Accelerometer
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES)
returns a non-wake-up sensor
An accelerometer limited axes sensor is equivalent to TYPE_ACCELEROMETER
but supports cases where one or two axes aren't supported.
The last three sensor event values reported by the sensor represent whether the acceleration value for the x, y, and z axes are supported. A value of 1.0
indicates that the axis is supported, and a value of 0
indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.
Device manufacturers must set the acceleration values for unused axes to 0
, instead of having undefined values.
Gyroscope limited axes
Underlying physical sensors: Gyroscope
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES)
returns a non-wake-up sensor
A gyroscope limited axes sensor is equivalent to TYPE_GYROSCOPE
but supports cases where one or two axes aren't supported.
The last three sensor event values reported by the sensor represent whether the angular speed value for the x, y, and z axes are supported. A value of 1.0
indicates that the axis is supported, and a value of 0
indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.
Device manufacturers must set the angular speed values for unused axes to 0
.
Accelerometer limited axes uncalibrated
Underlying physical sensors: Accelerometer
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED)
returns a non-wake-up sensor
An accelerometer limited axes uncalibrated sensor is equivalent to TYPE_ACCELEROMETER_UNCALIBRATED
but supports cases where one or two axes aren't supported.
The last three sensor event values reported by the sensor represent whether the acceleration and bias values for the x, y, and z axes are supported. A value of 1.0
indicates that the axis is supported, and a value of 0
indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.
Device manufacturers must set the acceleration and bias values for unused axes to 0
.
Gyroscope limited axes uncalibrated
Underlying physical sensors: Gyroscope
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED)
returns a non-wake-up sensor
A gyroscope limited axes uncalibrated sensor is equivalent to TYPE_GYROSCOPE_UNCALIBRATED
but supports cases where one or two axes aren't supported.
The last three sensor event values reported by the sensor represent whether the angular speed and drift values for the x, y, and z axes are supported. A value of 1.0
indicates that the axis is supported, and a value of 0
indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.
Device manufacturers must set the angular speed and drift values for unused axes to 0
.
Composite limited axes IMU
Underlying physical sensors: Any combination of 3-axis accelerometer, 3-axis gyroscope, 3-axis accelerometer uncalibrated, and 3-axis gyroscope uncalibrated sensors.
Reporting-mode: Continuous
A composite limited axes IMU sensor is equivalent to a limited axes IMU sensor but instead of being supported at the HAL, it converts the 3-axis sensor data into the equivalent limited axes variants. These composite sensors are only enabled for automotive devices.
The following table shows an example conversion from a standard 3-axis accelerometer to a composite limited axes accelerometer.
SensorEvent Values for SENSOR_TYPE_ACCELEROMETER | Example SENSOR_TYPE_ACCELEROMETER SensorEvent | Composite SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES SensorEvent |
---|---|---|
values[0] | -0.065 | -0.065 |
values[1] | 0.078 | 0.078 |
values[2] | 9.808 | 9.808 |
values[3] | N/A | 1.0 |
values[4] | N/A | 1.0 |
values[5] | N/A | 1.0 |
Automotive sensors
Sensors to support automotive use cases.
Heading
Underlying physical sensors: Any combination of GPS, magnetometer, accelerometer, and gyroscope.
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_HEADING)
returns a non-wake-up sensor
Available from Android 13, a heading sensor measures the direction in which the device is pointing relative to true north in degrees. The heading sensor includes two SensorEvent
values. One for the measured device heading and one for the accuracy of the provided heading value.
Heading values reported by this sensor must be between 0.0
(inclusive) and 360.0
(exclusive), with 0
indicating north, 90
east, 180
south, and 270
west.
Accuracy for this sensor is defined at 68 percent confidence. In the case where the underlying distribution is Gaussian normal, the accuracy is one standard deviation. For example, if the heading sensor returns a heading value of 60 degrees and an accuracy value of 10 degrees, there's a 68 percent probability of the true heading being between 50 degrees and 70 degrees.
,This section describes sensor axes, base sensors, and composite sensors (activity, attitude, uncalibrated, and interaction).
Sensor axes
Sensor event values from many sensors are expressed in a specific frame that is static relative to the device.
Mobile device axes
The Sensor API is relative only to the natural orientation of the screen (axes aren't swapped when the device's screen orientation changes.

Figure 1. Coordinate system (relative to a mobile device) used by the Sensor API
Automotive axes
In Android Automotive implementations, axes are defined with respect to the vehicle body frame. The origin of the vehicle reference frame is the center of the rear axle. The vehicle reference frame is oriented so that the:
- X-axis points to the right and is on a horizontal plane, perpendicular to the vehicle plane of symmetry.
- Y-axis points forward and is on a horizontal plane.

Figure 2. Coordinate system (relative to an automotive device) used by the Sensor API
The vehicle reference frame is a right-handed coordinate system. Therefore, the Z-axis points up.
The Z-axis of the reference frame is aligned to gravity, which means that the X-axis and Y-axis are both horizontal. As a result, the Y-axis may not always go through the front axle.
Base sensors
Base sensor types are named after the physical sensors they represent. These sensors relay data from a single physical sensor (as opposed to composite sensors that generate data out of other sensors). Examples of base sensor types include:
-
SENSOR_TYPE_ACCELEROMETER
-
SENSOR_TYPE_GYROSCOPE
-
SENSOR_TYPE_MAGNETOMETER
However, base sensors aren't equal to and shouldn't be confused with their underlying physical sensor. The data from a base sensor is not the raw output of the physical sensor because corrections (such as bias compensation and temperature compensation) are applied.
For example, the characteristics of a base sensor might be different from the characteristics of its underlying physical sensor in the following use cases:
- A gyroscope chip rated to have a bias range of 1 deg/sec.
- After factory calibration, temperature compensation and bias compensation are applied, the actual bias of the Android sensor will be reduced, may be to a point where the bias is guaranteed to be below 0.01 deg/sec.
- In this situation, we say that the Android sensor has a bias below 0.01 deg/sec, even though the data sheet of the underlying sensor said 1 deg/sec.
- A barometer with a power consumption of 100 uW.
- Because the generated data needs to be transported from the chip to the SoC, the actual power cost to gather data from the barometer Android sensor might be much higher, for example 1000 uW.
- In this situation, we say that the Android sensor has a power consumption of 1000 uW, even though the power consumption measured at the barometer chip leads is 100uW.
- A magnetometer that consumes 100uW when calibrated, but consumes more when calibrating.
- Its calibration routine might require activating the gyroscope, consuming 5000 uW, and running some algorithm, costing another 900 uW.
- In this situation, we say that the maximum power consumption of the (magnetometer) Android sensor is 6000 uW.
- In this case, the average power consumption is the more useful measure, and it's what is reported in the sensor static characteristics through the HAL.
Accelerometer
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER)
returns a non-wake-up sensor
An accelerometer sensor reports the acceleration of the device along the three sensor axes. The measured acceleration includes both the physical acceleration (change of velocity) and the gravity. The measurement is reported in the x, y, and z fields of sensors_event_t.acceleration.
All values are in SI units (m/s^2) and measure the acceleration of the device minus the force of gravity along the three sensor axes.
Here are examples:
- The norm of (x, y, z) should be close to 0 when in free fall.
- When the device lies flat on a table and is pushed on its left side toward the right, the x acceleration value is positive.
- When the device lies flat on a table, the acceleration value along z is +9.81 alo, which corresponds to the acceleration of the device (0 m/s^2) minus the force of gravity (-9.81 m/s^2).
- When the device lies flat on a table and is pushed toward the sky, the acceleration value is greater than +9.81, which corresponds to the acceleration of the device (+A m/s^2) minus the force of gravity (-9.81 m/s^2).
The readings are calibrated using:
- Temperature compensation
- Online bias calibration
- Online scale calibration
The bias and scale calibration must only be updated while the sensor is deactivated, so as to avoid causing jumps in values during streaming.
The accelerometer also reports how accurate it expects its readings to be through sensors_event_t.acceleration.status
. See the SensorManager
's SENSOR_STATUS_*
constants for more information on possible values for this field.
Ambient temperature
Reporting-mode: On-change
getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE)
returns a non-wake-up sensor
This sensor provides the ambient (room) temperature in degrees Celsius.
Magnetic field sensor
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD)
returns a non-wake-up sensor
SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD
A magnetic field sensor (also known as magnetometer) reports the ambient magnetic field, as measured along the three sensor axes.
The measurement is reported in the x, y, and z fields of sensors_event_t.magnetic
and all values are in micro-Tesla (uT).
The magnetometer also reports how accurate it expects its readings to be through sensors_event_t.magnetic.status
. See the SensorManager
's SENSOR_STATUS_*
constants for more information on possible values for this field.
The readings are calibrated using:
- Temperature compensation
- Factory (or online) soft-iron calibration
- Online hard-iron calibration
Gyroscope
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GYROSCOPE)
returns a non-wake-up sensor
A gyroscope sensor reports the rate of rotation of the device around the three sensor axes.
Rotation is positive in the counterclockwise direction (right-hand rule). That is, an observer looking from some positive location on the x, y, or z axis at a device positioned on the origin would report positive rotation if the device appeared to be rotating counter clockwise. Note that this is the standard mathematical definition of positive rotation and does not agree with the aerospace definition of roll.
The measurement is reported in the x, y, and z fields of sensors_event_t.gyro
and all values are in radians per second (rad/s).
The readings are calibrated using:
- Temperature compensation
- Factory (or online) scale compensation
- Online bias calibration (to remove drift)
The gyroscope also reports how accurate it expects its readings to be through sensors_event_t.gyro.status
. See the SensorManager
's SENSOR_STATUS_*
constants for more information on possible values for this field.
The gyroscope can't be emulated based on magnetometers and accelerometers, as this would cause it to have reduced local consistency and responsiveness. It must be based on a usual gyroscope chip.
Heart Rate
Reporting-mode: On-change
getDefaultSensor(SENSOR_TYPE_HEART_RATE)
returns a non-wake-up sensor
A heart rate sensor reports the current heart rate of the person touching the device.
The current heart rate in beats per minute (BPM) is reported in sensors_event_t.heart_rate.bpm
and the status of the sensor is reported in sensors_event_t.heart_rate.status
. See the SensorManager
's SENSOR_STATUS_*
constants for more information on possible values for this field. In particular, upon the first activation, unless the device is known to not be on the body, the status field of the first event must be set to SENSOR_STATUS_UNRELIABLE
. Because this sensor is on-change, events are generated when and only when heart_rate.bpm
or heart_rate.status
have changed since the last event. The events are generated no faster than every sampling_period
.
sensor_t.requiredPermission
is always SENSOR_PERMISSION_BODY_SENSORS
.
Light
Reporting-mode: On-change
getDefaultSensor(SENSOR_TYPE_LIGHT)
returns a non-wake-up sensor
A light sensor reports the current illumination in SI lux units.
The measurement is reported in sensors_event_t.light
.
Proximity
Reporting-mode: On-change
Usually defined as a wake-up sensor
getDefaultSensor(SENSOR_TYPE_PROXIMITY)
returns a wake-up sensor
A proximity sensor reports the distance from the sensor to the closest visible surface.
Up to Android 4.4, the proximity sensors were always wake-up sensors, waking up the SoC when detecting a change in proximity. After Android 4.4, we advise to implement the wake-up version of this sensor first, as it's the one that is used to turn the screen on and off while making phone calls.
The measurement is reported in centimeters in sensors_event_t.distance
. Note that some proximity sensors only support a binary "near" or "far" measurement. In this case, the sensor report its sensor_t.maxRange
value in the "far" state and a value less than sensor_t.maxRange
in the "near" state.
Pressure
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_PRESSURE)
returns a non-wake-up sensor
A pressure sensor (also known as barometer) reports the atmospheric pressure in hectopascal (hPa).
The readings are calibrated using
- Temperature compensation
- Factory bias calibration
- Factory scale calibration
The barometer is often used to estimate elevation changes. To estimate absolute elevation, the sea-level pressure (changing depending on the weather) must be used as a reference.
Relative humidity
Reporting-mode: On-change
getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY)
returns a non-wake-up sensor
A relative humidity sensor measures relative ambient air humidity and returns a value in percent.
Composite sensor types
A composite sensor generates data by processing and/or fusing data from one or several physical sensors. (Any sensor that isn't a base sensor is called a composite sensor.) Examples of composite sensors include:
- Step detector and significant motion , which are usually based on an accelerometer, but could be based on other sensors as well, if the power consumption and accuracy was acceptable.
- Game rotation vector , based on an accelerometer and a gyroscope.
- Uncalibrated gyroscope , which is similar to the gyroscope base sensor, but with the bias calibration being reported separately instead of being corrected in the measurement.
As with base sensors, the characteristics of the composite sensors come from the characteristics of their final data. For example, the power consumption of a game rotation vector is probably equal to the sum of the power consumptions of the accelerometer chip, the gyroscope chip, the chip processing the data, and the buses transporting the data. As another example, the drift of a game rotation vector depends as much on the quality of the calibration algorithm as on the physical sensor characteristics.
The following table lists available composite sensor types. Each composite sensor relies on data from one or several physical sensors. Avoid choosing other underlying physical sensors to approximate results as they provide a poor user experience.
Sensor type | Category | Underlying physical sensors | Reporting mode |
---|---|---|---|
Attitude | Accelerometer, gyroscope, MUST NOT USE magnetometer | Continuous | |
Attitude | Accelerometer, magnetometer, MUST NOT USE gyroscope | Continuous | |
Glance gesture ![]() | Interaction | Undefined | One-shot |
Attitude | Accelerometer, gyroscope | Continuous | |
Uncalibrated | Gyroscope | Continuous | |
Activity | Accelerometer, gyroscope (if present), or magnetometer (if gyro not present) | Continuous | |
Uncalibrated | Magnetometer | Continuous | |
Orientation (deprecated) | Attitude | Accelerometer, magnetometer, gyroscope (if present) | Continuous |
Interaction | Undefined | One-shot | |
Attitude | Accelerometer, magnetometer, gyroscope | Continuous | |
Activity | Accelerometer (or another as long as very low power) | One-shot | |
Activity | Accelerometer | On-change | |
Activity | Accelerometer | Special | |
Activity | Accelerometer | Special | |
Interaction | Undefined | One-shot |
= Low power sensor
Activity composite sensors
Linear acceleration
Underlying physical sensors: Accelerometer and (if present) gyroscope (or magnetometer if gyroscope not present)
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION)
returns a non-wake-up sensor
A linear acceleration sensor reports the linear acceleration of the device in the sensor frame, not including gravity.
The output is conceptually: output of the accelerometer minus the output of the gravity sensor . It's reported in m/s^2 in the x, y, and z fields of sensors_event_t.acceleration
.
Readings on all axes should be close to 0 when the device is immobile.
If the device possesses a gyroscope, the linear acceleration sensor must use the gyroscope and accelerometer as input.
If the device doesn't possess a gyroscope, the linear acceleration sensor must use the accelerometer and the magnetometer as input.
Significant motion
Underlying physical sensor: Accelerometer (or another as long as low power)
Reporting-mode: One-shot
Low power
Implement only the wake-up version of this sensor.
getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION)
returns a wake-up sensor
A significant motion detector triggers when detecting a significant motion : a motion that might lead to a change in the user location.
Examples of such significant motions are:
- Walking or biking
- Sitting in a moving car, coach, or train
Examples of situations that don't trigger significant motion:
- Phone in pocket and person isn't moving
- Phone is on a table and the table shakes a bit due to nearby traffic or washing machine
At the high level, the significant motion detector is used to reduce the power consumption of location determination. When the localization algorithms detect that the device is static, they can switch to a low-power mode, where they rely on significant motion to wake the device up when the user is changing location.
This sensor must be low power. It makes a tradeoff for power consumption that may result in a small amount of false negatives. This is done for a few reasons:
- The goal of this sensor is to save power.
- Triggering an event when the user isn't moving (false positive) is costly in terms of power, so it should be avoided.
- Not triggering an event when the user is moving (false negative) is acceptable as long as it isn't done repeatedly. If the user has been walking for 10 seconds, not triggering an event within those 10 seconds isn't acceptable.
Each sensor event reports 1
in sensors_event_t.data[0]
.
Step detector
Underlying physical sensor: Accelerometer (+ possibly others as long as low power)
Reporting-mode: Special (one event per step taken)
Low power
getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR)
returns a non-wake-up sensor
A step detector generates an event each time a step is taken by the user.
The timestamp of the event sensors_event_t.timestamp
corresponds to when the foot hit the ground, generating a high variation in acceleration.
Compared to the step counter, the step detector should have a lower latency (less than two seconds). Both the step detector and the step counter detect when the user is walking, running, and walking up the stairs. They shouldn't trigger when the user is biking, driving, or in other vehicles.
This sensor must be low power. That is, if the step detection cannot be done in hardware, this sensor shouldn't be defined. In particular, when the step detector is activated and the accelerometer isn't, only steps should trigger interrupts (not every accelerometer reading).
sampling_period_ns
has no impact on step detectors.
Each sensor event reports 1
in sensors_event_t.data[0]
.
Step counter
Underlying physical sensor: Accelerometer (+ possibly others as long as low power)
Reporting-mode: On-change
Low-power
getDefaultSensor(SENSOR_TYPE_STEP_COUNTER)
returns a non-wake-up sensor
A step counter reports the number of steps taken by the user since the last reboot while activated.
The measurement is reported as a uint64_t
in sensors_event_t.step_counter
and is reset to zero only on a system reboot.
The timestamp of the event is set to the time when the last step for that event was taken.
See the Step detector sensor type for the signification of the time of a step.
Compared to the step detector, the step counter can have a higher latency (up to 10 seconds). Thanks to this latency, this sensor has a high accuracy; the step count after a full day of measures should be within 10% of the actual step count. Both the step detector and the step counter detect when the user is walking, running, and walking up the stairs. They shouldn't trigger when the user is biking, driving, or in other vehicles.
The hardware must ensure the internal step count never overflows. The minimum size of the hardware's internal counter shall be 16 bits. In case of imminent overflow (at most every ~2^16 steps), the SoC can be woken up so the driver can do the counter maintenance.
As stated in Interaction , while this sensor operates, it shall not disrupt any other sensors, in particular, the accelerometer, which might very well be in use.
If a particular device can't support these modes of operation, then this sensor type must not be reported by the HAL. That is, it isn't acceptable to "emulate" this sensor in the HAL.
This sensor must be low power. That is, if the step detection can't be done in hardware, this sensor shouldn't be defined. In particular, when the step counter is activated and the accelerometer isn't, only steps should trigger interrupts (not accelerometer data).
Tilt detector
Underlying physical sensor: Accelerometer (+ possibly others as long as low power)
Reporting-mode: Special
Low-power
Implement only the wake-up version of this sensor.
getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR)
returns a wake-up sensor
A tilt detector generates an event each time a tilt event is detected.
A tilt event is defined by the direction of the 2-seconds window average gravity changing by at least 35 degrees since the activation or the last event generated by the sensor. Here is the algorithm:
-
reference_estimated_gravity
= average of accelerometer measurements over the first second after activation or the estimated gravity when the last tilt event was generated. -
current_estimated_gravity
= average of accelerometer measurements over the last 2 seconds. - Trigger when
angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees
Large accelerations without a change in phone orientation shouldn't trigger a tilt event. For example, a sharp turn or strong acceleration while driving a car shouldn't trigger a tilt event, even though the angle of the average acceleration might vary by more than 35 degrees. Typically, this sensor is implemented with the help of only an accelerometer. Other sensors can be used as well if they do not increase the power consumption significantly. This is a low-power sensor that should allow the SoC to go into suspend mode. Do not emulate this sensor in the HAL. Each sensor event reports 1
in sensors_event_t.data[0]
.
Attitude composite sensors
Rotation vector
Underlying physical sensors: Accelerometer, magnetometer, and gyroscope
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR)
returns a non-wake-up sensor
A rotation vector sensor reports the orientation of the device relative to the East-North-Up coordinates frame. It's usually obtained by integration of accelerometer, gyroscope, and magnetometer readings. The East-North-Up coordinate system is defined as a direct orthonormal basis where:
- X points east and is tangential to the ground.
- Y points north and is tangential to the ground.
- Z points towards the sky and is perpendicular to the ground.
The orientation of the phone is represented by the rotation necessary to align the East-North-Up coordinates with the phone's coordinates. That is, applying the rotation to the world frame (X,Y,Z) would align them with the phone coordinates (x,y,z).
The rotation can be seen as rotating the phone by an angle theta around an axis rot_axis
to go from the reference (East-North-Up aligned) device orientation to the current device orientation. The rotation is encoded as the four unit-less x, y, z, w components of a unit quaternion:
-
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)
Where:
- The x, y, and z fields of
rot_axis
are the East-North-Up coordinates of a unit length vector representing the rotation axis -
theta
is the rotation angle
The quaternion is a unit quaternion: It must be of norm 1
. Failure to ensure this will cause erratic client behavior.
In addition, this sensor reports an estimated heading accuracy:
sensors_event_t.data[4] = estimated_accuracy
(in radians)
The heading error must be less than estimated_accuracy
95% of the time. This sensor must use a gyroscope as the main orientation change input.
This sensor also uses accelerometer and magnetometer input to make up for gyroscope drift, and it can't be implemented using only the accelerometer and magnetometer.
Game rotation vector
Underlying physical sensors: Accelerometer and gyroscope (no magnetometer)
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR)
returns a non-wake-up sensor
A game rotation vector sensor is similar to a rotation vector sensor but not using the geomagnetic field. Therefore the Y axis doesn't point north but instead to some other reference. That reference is allowed to drift by the same order of magnitude as the gyroscope drifts around the Z axis.
See the Rotation vector sensor for details on how to set sensors_event_t.data[0-3]
. This sensor doesn't report an estimated heading accuracy: sensors_event_t.data[4]
is reserved and should be set to 0
.
In an ideal case, a phone rotated and returned to the same real-world orientation should report the same game rotation vector.
This sensor must be based on a gyroscope and an accelerometer. It can't use magnetometer as an input, besides, indirectly, through estimation of the gyroscope bias.
Gravity
Underlying physical sensors: Accelerometer and (if present) gyroscope (or magnetometer if gyroscope not present)
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GRAVITY)
returns a non-wake-up sensor
A gravity sensor reports the direction and magnitude of gravity in the device's coordinates.
The gravity vector components are reported in m/s^2 in the x, y, and z fields of sensors_event_t.acceleration
.
When the device is at rest, the output of the gravity sensor should be identical to that of the accelerometer. On Earth, the magnitude is around 9.8 m/s^2.
If the device possesses a gyroscope, the gravity sensor must use the gyroscope and accelerometer as input.
If the device doesn't possess a gyroscope, the gravity sensor must use the accelerometer and the magnetometer as input.
Geomagnetic rotation vector
Underlying physical sensors: Accelerometer and magnetometer (no gyroscope)
Reporting-mode: Continuous
Low-power
getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR)
returns a non-wake-up sensor
A geomagnetic rotation vector is similar to a rotation vector sensor but using a magnetometer and no gyroscope.
This sensor must be based on a magnetometer. It can't be implemented using a gyroscope, and gyroscope input can't be used by this sensor.
See the Rotation vector sensor for details on how to set sensors_event_t.data[0-4]
.
Just like for the rotation vector sensor, the heading error must be less than the estimated accuracy ( sensors_event_t.data[4]
) 95% of the time.
This sensor must be low power, so it has to be implemented in hardware.
Orientation (deprecated)
Underlying physical sensors: Accelerometer, magnetometer and (if present) gyroscope
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ORIENTATION)
returns a non-wake-up sensor
Note: This is an older sensor type that has been deprecated in the Android SDK. It has been replaced by the rotation vector sensor, which is more clearly defined. Use the rotation vector sensor over the orientation sensor whenever possible.
An orientation sensor reports the attitude of the device. The measurements are reported in degrees in the x, y, and z fields of sensors_event_t.orientation
:
-
sensors_event_t.orientation.x
: azimuth, the angle between the magnetic north direction and the Y axis, around the Z axis (0<=azimuth<360
). 0=North, 90=East, 180=South, 270=West. -
sensors_event_t.orientation.y
: pitch, rotation around X axis (-180<=pitch<=180
), with positive values when the Z axis moves toward the Y axis. -
sensors_event_t.orientation.z
: roll, rotation around Y axis (-90<=roll<=90
), with positive values when the X axis moves towards the Z axis.
Please note, for historical reasons the roll angle is positive in the clockwise direction. (Mathematically speaking, it should be positive in the counter-clockwise direction):

Figure 3. Orientation relative to a device
This definition is different from yaw, pitch, and roll used in aviation where the X axis is along the long side of the plane (tail to nose).
The orientation sensor also reports how accurate it expects its readings to be through sensors_event_t.orientation.status
. See the SensorManager
's SENSOR_STATUS_*
constants for more information on possible values for this field.
Uncalibrated sensors
Uncalibrated sensors provide more raw results and may include some bias but also contain fewer "jumps" from corrections applied through calibration. Some apps may prefer these uncalibrated results as smoother and more reliable. For instance, if an app is attempting to conduct its own sensor fusion, introducing calibrations can actually distort results.
Accelerometer uncalibrated
Underlying physical sensor: Accelerometer
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED)
returns a non-wake-up sensor
An uncalibrated accelerometer sensor reports the acceleration of the device along the three sensor axes without any bias correction (factory bias and temperature compensation are applied to uncalibrated measurements), along with a bias estimate. All values are in SI units (m/s^2) and are reported in the fields of sensors_event_t.uncalibrated_accelerometer
:
-
x_uncalib
: acceleration (without bias compensation) along the X axis -
y_uncalib
: acceleration (without bias compensation) along the Y axis -
z_uncalib
: acceleration (without bias compensation) along the Z axis -
x_bias
: estimated bias along X axis -
y_bias
: estimated bias along Y axis -
z_bias
: estimated bias along Z axis
Gyroscope uncalibrated
Underlying physical sensor: Gyroscope
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED)
returns a non-wake-up sensor
An uncalibrated gyroscope reports the rate of rotation around the sensor axes without applying bias compensation to them, along with a bias estimate. All values are in radians/second and are reported in the fields of sensors_event_t.uncalibrated_gyro
:
-
x_uncalib
: angular speed (without drift compensation) around the X axis -
y_uncalib
: angular speed (without drift compensation) around the Y axis -
z_uncalib
: angular speed (without drift compensation) around the Z axis -
x_bias
: estimated drift around X axis -
y_bias
: estimated drift around Y axis -
z_bias
: estimated drift around Z axis
Conceptually, the uncalibrated measurement is the sum of the calibrated measurement and the bias estimate: _uncalibrated = _calibrated + _bias
.
The x_bias
, y_bias
and z_bias
values are expected to jump as soon as the estimate of the bias changes, and they should be stable the rest of the time.
See the definition of the gyroscope sensor for details on the coordinate system used.
Factory calibration and temperature compensation must be applied to the measurements. Also, gyroscope drift estimation must be implemented so that reasonable estimates can be reported in x_bias
, y_bias
and z_bias
. If the implementation isn't able to estimate the drift, then this sensor must not be implemented.
If this sensor is present, then the corresponding Gyroscope sensor must also be present and both sensors must share the same sensor_t.name
and sensor_t.vendor
values.
Magnetic field uncalibrated
Underlying physical sensor: Magnetometer
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED)
returns a non-wake-up sensor
An uncalibrated magnetic field sensor reports the ambient magnetic field together with a hard iron calibration estimate. All values are in micro-Tesla (uT) and are reported in the fields of sensors_event_t.uncalibrated_magnetic
:
-
x_uncalib
: magnetic field (without hard-iron compensation) along the X axis -
y_uncalib
: magnetic field (without hard-iron compensation) along the Y axis -
z_uncalib
: magnetic field (without hard-iron compensation) along the Z axis -
x_bias
: estimated hard-iron bias along the X axis -
y_bias
: estimated hard-iron bias along the Y axis -
z_bias
: estimated hard-iron bias along the Z axis
Conceptually, the uncalibrated measurement is the sum of the calibrated measurement and the bias estimate: _uncalibrated = _calibrated + _bias
.
The uncalibrated magnetometer allows higher level algorithms to handle bad hard iron estimation. The x_bias
, y_bias
and z_bias
values are expected to jump as soon as the estimate of the hard-iron changes, and they should be stable the rest of the time.
Soft-iron calibration and temperature compensation must be applied to the measurements. Also, hard-iron estimation must be implemented so that reasonable estimates can be reported in x_bias
, y_bias
and z_bias
. If the implementation isn't able to estimate the bias, then this sensor must not be implemented.
If this sensor is present, then the corresponding magnetic field sensor must be present and both sensors must share the same sensor_t.name
and sensor_t.vendor
values.
Hinge angle
Reporting-mode: On-change
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
returns a wake-up sensor
A hinge angle sensor measures the angle, in degrees, between two integral parts of the device. Movement of a hinge measured by this sensor type is expected to alter the ways in which the user can interact with the device, for example, by unfolding or revealing a display.
Interaction composite sensors
Some sensors are mostly used to detect interactions with the user. 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]
.
Limited axes IMU sensors
Available from Android 13, limited axes IMU sensors are sensors that support use cases where not all three axes (x, y, z) are available. Standard IMU types in Android (such as SENSOR_TYPE_ACCELEROMETER
and SENSOR_TYPE_GYROSCOPE
) assume that all three axes are supported. However, not all form factors and devices support 3-axis accelerometers and 3-axis gyroscopes.
Accelerometer limited axes
Underlying physical sensors: Accelerometer
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES)
returns a non-wake-up sensor
An accelerometer limited axes sensor is equivalent to TYPE_ACCELEROMETER
but supports cases where one or two axes aren't supported.
The last three sensor event values reported by the sensor represent whether the acceleration value for the x, y, and z axes are supported. A value of 1.0
indicates that the axis is supported, and a value of 0
indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.
Device manufacturers must set the acceleration values for unused axes to 0
, instead of having undefined values.
Gyroscope limited axes
Underlying physical sensors: Gyroscope
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES)
returns a non-wake-up sensor
A gyroscope limited axes sensor is equivalent to TYPE_GYROSCOPE
but supports cases where one or two axes aren't supported.
The last three sensor event values reported by the sensor represent whether the angular speed value for the x, y, and z axes are supported. A value of 1.0
indicates that the axis is supported, and a value of 0
indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.
Device manufacturers must set the angular speed values for unused axes to 0
.
Accelerometer limited axes uncalibrated
Underlying physical sensors: Accelerometer
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED)
returns a non-wake-up sensor
An accelerometer limited axes uncalibrated sensor is equivalent to TYPE_ACCELEROMETER_UNCALIBRATED
but supports cases where one or two axes aren't supported.
The last three sensor event values reported by the sensor represent whether the acceleration and bias values for the x, y, and z axes are supported. A value of 1.0
indicates that the axis is supported, and a value of 0
indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.
Device manufacturers must set the acceleration and bias values for unused axes to 0
.
Gyroscope limited axes uncalibrated
Underlying physical sensors: Gyroscope
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED)
returns a non-wake-up sensor
A gyroscope limited axes uncalibrated sensor is equivalent to TYPE_GYROSCOPE_UNCALIBRATED
but supports cases where one or two axes aren't supported.
The last three sensor event values reported by the sensor represent whether the angular speed and drift values for the x, y, and z axes are supported. A value of 1.0
indicates that the axis is supported, and a value of 0
indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.
Device manufacturers must set the angular speed and drift values for unused axes to 0
.
Composite limited axes IMU
Underlying physical sensors: Any combination of 3-axis accelerometer, 3-axis gyroscope, 3-axis accelerometer uncalibrated, and 3-axis gyroscope uncalibrated sensors.
Reporting-mode: Continuous
A composite limited axes IMU sensor is equivalent to a limited axes IMU sensor but instead of being supported at the HAL, it converts the 3-axis sensor data into the equivalent limited axes variants. These composite sensors are only enabled for automotive devices.
The following table shows an example conversion from a standard 3-axis accelerometer to a composite limited axes accelerometer.
SensorEvent Values for SENSOR_TYPE_ACCELEROMETER | Example SENSOR_TYPE_ACCELEROMETER SensorEvent | Composite SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES SensorEvent |
---|---|---|
values[0] | -0.065 | -0.065 |
values[1] | 0.078 | 0.078 |
values[2] | 9.808 | 9.808 |
values[3] | N/A | 1.0 |
values[4] | N/A | 1.0 |
values[5] | N/A | 1.0 |
Automotive sensors
Sensors to support automotive use cases.
Heading
Underlying physical sensors: Any combination of GPS, magnetometer, accelerometer, and gyroscope.
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_HEADING)
returns a non-wake-up sensor
Available from Android 13, a heading sensor measures the direction in which the device is pointing relative to true north in degrees. The heading sensor includes two SensorEvent
values. One for the measured device heading and one for the accuracy of the provided heading value.
Heading values reported by this sensor must be between 0.0
(inclusive) and 360.0
(exclusive), with 0
indicating north, 90
east, 180
south, and 270
west.
Accuracy for this sensor is defined at 68 percent confidence. In the case where the underlying distribution is Gaussian normal, the accuracy is one standard deviation. For example, if the heading sensor returns a heading value of 60 degrees and an accuracy value of 10 degrees, there's a 68 percent probability of the true heading being between 50 degrees and 70 degrees.