傳感器類型

本節介紹傳感器軸、基礎傳感器和復合傳感器（活動、姿態、未校準和交互）。

傳感器軸

來自許多傳感器的傳感器事件值在相對於設備是靜態的特定幀中表示。

移動設備軸

傳感器 API 僅與屏幕的自然方向相關（當設備的屏幕方向發生變化時，軸不會交換。

圖 1. Sensor API 使用的坐標系（相對於移動設備）

汽車軸

在 Android Automotive 實現中，軸是相對於車身框架定義的。車輛參考系的原點是後軸的中心。車輛參考系的方向是這樣的：

• X 軸指向右側，位於與車輛對稱平面垂直的水平面上。
• Y 軸指向前方並且在水平面上。

圖 2. Sensor API 使用的坐標系（相對於汽車設備）

車輛參考係是右手坐標系。因此，Z 軸指向上方。

參考系的 Z 軸與重力對齊，這意味著 X 軸和 Y 軸都是水平的。因此，Y 軸可能並不總是通過前軸。

基礎傳感器

基本傳感器類型以其代表的物理傳感器命名。這些傳感器中繼來自單個物理傳感器的數據（與從其他傳感器生成數據的複合傳感器相反）。基本傳感器類型的示例包括：

• SENSOR_TYPE_ACCELEROMETER
• SENSOR_TYPE_GYROSCOPE
• SENSOR_TYPE_MAGNETOMETER

但是，基本傳感器不等於也不應與其底層物理傳感器混淆。來自基礎傳感器的數據不是物理傳感器的原始輸出，因為應用了校正（例如偏置補償和溫度補償）。

例如，在以下用例中，基本傳感器的特性可能與其底層物理傳感器的特性不同：

• 陀螺儀芯片額定偏置範圍為 1 度/秒。
  • 經過工廠校準、溫度補償和偏置補償後，Android 傳感器的實際偏置會降低，可能會達到偏置保證低於 0.01 度/秒的程度。
  • 在這種情況下，我們說 Android 傳感器的偏差低於 0.01 度/秒，儘管底層傳感器的數據表說 1 度/秒。
• 功耗為 100 uW 的氣壓計。
  • 由於生成的數據需要從芯片傳輸到 SoC，因此從氣壓計 Android 傳感器收集數據的實際功耗可能要高得多，例如 1000 uW。
  • 在這種情況下，我們說 Android 傳感器的功耗為 1000 uW，即使在氣壓計芯片引線處測量的功耗為 100 uW。
• 校準時消耗100uW的磁力計，但校準時消耗更多。
  • 它的校準程序可能需要激活陀螺儀，消耗 5000 uW，並運行一些算法，再消耗 900 uW。
  • 在這種情況下，我們說（磁力計）Android 傳感器的最大功耗為 6000 uW。
  • 在這種情況下，平均功耗是更有用的度量，它是通過 HAL 在傳感器靜態特性中報告的。

加速度計

報告模式：連續

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER)返回非喚醒傳感器

加速度計傳感器報告設備沿三個傳感器軸的加速度。測得的加速度包括物理加速度（速度變化）和重力。測量值在sensors_event_t.acceleration 的x、y 和z 字段中報告。

所有值均以 SI 單位 (m/s^2) 為單位，測量設備的加速度減去沿三個傳感器軸的重力。

以下是示例：

• 自由落體時 (x, y, z) 的範數應接近 0。
• 當設備平放在桌子上並將其左側推向右側時，x 加速度值為正。
• 當設備平放在桌子上時，沿 z 方向的加速度值為 +9.81 alo，這對應於設備的加速度 (0 m/s^2) 減去重力 (-9.81 m/s^2)。
• 當設備平放在桌子上並被推向天空時，加速度值大於+9.81，對應於設備的加速度（+A m/s^2）減去重力（-9.81 m /s^2)。

使用以下方法校準讀數：

• 溫度補償
• 在線偏置校準
• 在線秤校準

偏置和比例校準只能在傳感器停用時更新，以避免在流式傳輸期間導致值的跳躍。

加速度計還通過sensors_event_t.acceleration.status報告其預期讀數的準確度。有關此字段可能值的更多信息，請參閱SensorManager的SENSOR_STATUS_*常量。

環境溫度

報告模式：變化

getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE)返回非喚醒傳感器

該傳感器以攝氏度為單位提供環境（室溫）溫度。

磁場傳感器

報告模式：連續

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD)返回非喚醒傳感器

SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD

磁場傳感器（也稱為磁力計）報告沿三個傳感器軸測量的環境磁場。

測量結果在sensors_event_t.magnetic的 x、y 和 z 字段中報告，所有值都以微特斯拉 (uT) 為單位。

磁力計還通過sensors_event_t.magnetic.status報告其預期讀數的準確度。有關此字段可能值的更多信息，請參閱SensorManager的SENSOR_STATUS_*常量。

使用以下方法校準讀數：

• 溫度補償
• 工廠（或在線）軟鐵校準
• 在線硬鐵校準

陀螺儀

報告模式：連續

getDefaultSensor(SENSOR_TYPE_GYROSCOPE)返回非喚醒傳感器

陀螺儀傳感器報告設備圍繞三個傳感器軸的旋轉速率。

逆時針方向旋轉為正（右手定則）。也就是說，如果設備看起來是逆時針旋轉，則從 x、y 或 z 軸上的某個正位置看位於原點上的設備的觀察者將報告正旋轉。請注意，這是正旋轉的標準數學定義，與航空航天的橫滾定義不一致。

測量值報告在sensors_event_t.gyro的 x、y 和 z 字段中，所有值都以弧度每秒 (rad/s) 為單位。

使用以下方法校準讀數：

• 溫度補償
• 工廠（或在線）規模補償
• 在線偏置校準（消除漂移）

陀螺儀還通過sensors_event_t.gyro.status報告其預期讀數的準確度。有關此字段可能值的更多信息，請參閱SensorManager的SENSOR_STATUS_*常量。

陀螺儀不能基於磁力計和加速度計來模擬，因為這會導致它的局部一致性和響應性降低。它必須基於通常的陀螺儀芯片。

心率

報告模式：變化

getDefaultSensor(SENSOR_TYPE_HEART_RATE)返回非喚醒傳感器

心率傳感器報告觸摸設備的人的當前心率。

當前心率（BPM）報告在sensors_event_t.heart_rate.bpm中，傳感器的狀態報告在sensors_event_t.heart_rate.status中。有關此字段可能值的更多信息，請參閱SensorManager的SENSOR_STATUS_*常量。特別是，在第一次激活時，除非已知設備不在身體上，否則第一個事件的狀態字段必須設置為SENSOR_STATUS_UNRELIABLE 。因為這個傳感器是不斷變化的，所以當且僅當heart_rate.bpm或heart_rate.status自上次事件發生變化時才會生成事件。事件的生成速度不會比每個sampling_period快。

sensor_t.requiredPermission始終是SENSOR_PERMISSION_BODY_SENSORS 。

光

報告模式：變化

getDefaultSensor(SENSOR_TYPE_LIGHT)返回非喚醒傳感器

光傳感器以 SI 勒克斯為單位報告當前照度。

測量值在sensors_event_t.light中報告。

接近

報告模式：變化

通常定義為喚醒傳感器

getDefaultSensor(SENSOR_TYPE_PROXIMITY)返回喚醒傳感器

接近傳感器報告從傳感器到最近的可見表面的距離。

在 Android 4.4 之前，接近傳感器始終是喚醒傳感器，在檢測到接近變化時喚醒 SoC。在Android 4.4之後，我們建議先實現這個傳感器的喚醒版本，因為它是用來在打電話時打開和關閉屏幕的傳感器。

在sensors_event_t.distance中以厘米為單位報告測量值。請注意，某些接近傳感器僅支持二進制“近”或“遠”測量。在這種情況下，傳感器在“遠”狀態下報告其sensor_t.maxRange值，在“近”狀態下報告小於sensor_t.maxRange的值。

壓力

報告模式：連續

getDefaultSensor(SENSOR_TYPE_PRESSURE)返回非喚醒傳感器

壓力傳感器（也稱為氣壓計）以百帕 (hPa) 為單位報告大氣壓力。

讀數使用校準

• 溫度補償
• 工廠偏差校準
• 工廠規模校準

氣壓計通常用於估計海拔變化。要估計絕對海拔，必須使用海平面壓力（根據天氣而變化）作為參考。

相對濕度

報告模式：變化

getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY)返回非喚醒傳感器

相對濕度傳感器測量相對環境空氣濕度並返回百分比值。

複合傳感器類型

複合傳感器通過處理和/或融合來自一個或多個物理傳感器的數據來生成數據。 （任何不是基本傳感器的傳感器都稱為複合傳感器。）複合傳感器的示例包括：

• 步數檢測器和顯著運動，通常基於加速度計，但如果功耗和精度可以接受，也可以基於其他傳感器。
• 遊戲旋轉矢量，基於加速度計和陀螺儀。
• 未校準的陀螺儀，類似於陀螺儀基座傳感器，但偏差校准單獨報告，而不是在測量中進行校正。

與基礎傳感器一樣，複合傳感器的特性來自其最終數據的特性。例如，遊戲旋轉矢量的功耗可能等於加速度計芯片、陀螺儀芯片、處理數據的芯片和傳輸數據的總線的功耗之和。作為另一個例子，遊戲旋轉矢量的漂移取決於校準算法的質量和物理傳感器特性一樣多。

下表列出了可用的複合傳感器類型。每個複合傳感器都依賴於來自一個或多個物理傳感器的數據。避免選擇其他底層物理傳感器來近似結果，因為它們提供了糟糕的用戶體驗。

傳感器類型	類別	底層物理傳感器	報告模式
遊戲旋轉矢量	態度	加速度計、陀螺儀、不得使用磁力計	連續的
地磁旋轉矢量	態度	加速度計，磁力計，不得使用陀螺儀	連續的
掃視手勢	相互作用	不明確的	一發
重力	態度	加速度計、陀螺儀	連續的
陀螺儀未校準	未校準	陀螺儀	連續的
直線加速度	活動	加速度計、陀螺儀（如果有）或磁力計（如果沒有陀螺儀）	連續的
未校準的磁場	未校準	磁力計	連續的
方向（已棄用）	態度	加速度計、磁力計、陀螺儀（如果有）	連續的
拿起手勢	相互作用	不明確的	一發
旋轉矢量	態度	加速度計、磁力計、陀螺儀	連續的
重大運動	活動	加速度計（或其他只要非常低的功率）	一發
計步器	活動	加速度計	變化中
步進檢測器	活動	加速度計	特別的
傾斜探測器	活動	加速度計	特別的
起床手勢	相互作用	不明確的	一發

= 低功耗傳感器

活動複合傳感器

直線加速度

底層物理傳感器：加速度計和（如果有）陀螺儀（或磁力計，如果沒有陀螺儀）

報告模式：連續

getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION)返回非喚醒傳感器

線性加速度傳感器報告傳感器框架中設備的線性加速度，不包括重力。

輸出在概念上是：加速度計的輸出減去重力傳感器的輸出。在sensors_event_t.acceleration的 x、y 和 z 字段中以 m/s^2 報告。

當設備靜止時，所有軸上的讀數應接近 0。

如果設備具有陀螺儀，則線性加速度傳感器必須使用陀螺儀和加速度計作為輸入。

如果設備沒有陀螺儀，線性加速度傳感器必須使用加速度計和磁力計作為輸入。

重大運動

底層物理傳感器：加速度計（或其他只要低功耗）

報告模式：一次性

低電量

僅實現此傳感器的喚醒版本。

getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION)返回喚醒傳感器

當檢測到顯著運動時觸發顯著運動檢測器：可能導致用戶位置變化的運動。

此類重大動議的示例包括：

• 步行或騎自行車
• 坐在移動的汽車、長途汽車或火車上

不觸發顯著運動的情況示例：

• 手機在口袋裡，人不動
• 電話在桌子上，由於附近的交通或洗衣機，桌子有點晃動

在高層，重要運動檢測器用於降低位置確定的功耗。當定位算法檢測到設備處於靜止狀態時，它們可以切換到低功耗模式，當用戶改變位置時，它們依靠顯著的運動來喚醒設備。

該傳感器必須是低功率的。它對可能導致少量誤報的功耗進行了權衡。這樣做有幾個原因：

• 該傳感器的目標是節省電力。
• 當用戶沒有移動（誤報）時觸發事件在功率方面是昂貴的，因此應該避免。
• 用戶移動時不觸發事件（假陰性）是可以接受的，只要不重複執行即可。如果用戶已經步行了 10 秒，那麼在這 10 秒內不觸發事件是不可接受的。

每個傳感器事件在sensors_event_t.data[0]中報告1 。

步進檢測器

底層物理傳感器：加速度計（可能還有其他傳感器，只要低功耗）

報告模式：特殊（每一步一個事件）

低電量

getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR)返回非喚醒傳感器

每次用戶邁出一步時，步數檢測器都會生成一個事件。

事件sensors_event_t.timestamp的時間戳對應於腳接觸地面的時間，從而產生較大的加速度變化。

與計步器相比，計步器應具有較低的延遲（小於兩秒）。步數檢測器和計步器都檢測用戶何時步行、跑步和上樓梯。當用戶騎自行車、開車或在其他車輛中時，它們不應觸發。

該傳感器必須是低功率的。也就是說，如果無法在硬件中進行步進檢測，則不應定義此傳感器。特別是，當步數檢測器被激活而加速度計沒有被激活時，只有步數應該觸發中斷（不是每個加速度計讀數）。

sampling_period_ns對步進檢測器沒有影響。

每個傳感器事件在sensors_event_t.data[0]中報告1 。

計步器

底層物理傳感器：加速度計（可能還有其他傳感器，只要低功耗）

報告模式：變化

低電量

getDefaultSensor(SENSOR_TYPE_STEP_COUNTER)返回非喚醒傳感器

計步器報告自上次激活後用戶所採取的步數。

測量值在sensors_event_t.step_counter中報告為uint64_t ，並且僅在系統重新啟動時重置為零。

事件的時間戳設置為執行該事件的最後一步的時間。

有關步長時間的含義，請參見步長檢測器傳感器類型。

與計步器相比，計步器可以有更高的延遲（最多 10 秒）。由於這種延遲，該傳感器具有很高的準確性；一整天的措施後的步數應在實際步數的10%以內。步數檢測器和計步器都檢測用戶何時步行、跑步和上樓梯。當用戶騎自行車、開車或在其他車輛中時，它們不應觸發。

硬件必須確保內部步數永遠不會溢出。硬件內部計數器的最小尺寸應為 16 位。在即將溢出的情況下（最多每 ~2^16 步），可以喚醒 SoC，以便驅動程序可以進行計數器維護。

如交互中所述，當此傳感器運行時，它不會干擾任何其他傳感器，尤其是加速度計，它很可能正在使用中。

如果特定設備不支持這些操作模式，則 HAL 不得報告此傳感器類型。也就是說，在 HAL 中“模擬”這個傳感器是不可接受的。

該傳感器必須是低功率的。也就是說，如果無法在硬件中完成步進檢測，則不應定義此傳感器。特別是，當計步器被激活而加速度計沒有被激活時，只有步數應該觸發中斷（不是加速度計數據）。

傾斜探測器

底層物理傳感器：加速度計（可能還有其他傳感器，只要低功耗）

報告模式：特殊

低電量

僅實現此傳感器的喚醒版本。

getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR)返回喚醒傳感器

每次檢測到傾斜事件時，傾斜檢測器都會生成一個事件。

傾斜事件由 2 秒窗口平均重力的方向定義，自激活或傳感器生成的最後一個事件以來至少改變 35 度。這是算法：

• reference_estimated_gravity = 激活後第一秒內加速度計測量值的平均值或生成最後一個傾斜事件時的估計重力。
• current_estimated_gravity = 過去 2 秒內加速度計測量值的平均值。
• 當angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees時觸發

沒有改變手機方向的大加速度不應觸發傾斜事件。例如，駕駛汽車時的急轉彎或強烈加速不應觸發傾斜事件，即使平均加速度的角度可能變化超過 35 度。通常，該傳感器僅在加速度計的幫助下實現。如果其他傳感器不會顯著增加功耗，也可以使用它們。這是一個低功耗傳感器，應該允許 SoC 進入掛起模式。不要在 HAL 中模擬此傳感器。每個傳感器事件在sensors_event_t.data[0]中報告1 。

姿態復合傳感器

旋轉矢量

底層物理傳感器：加速度計、磁力計和陀螺儀

報告模式：連續

getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR)返回非喚醒傳感器

旋轉矢量傳感器報告設備相對於東-北-上坐標系的方向。它通常通過加速度計、陀螺儀和磁力計讀數的集成獲得。東-北-上坐標系定義為直接正交基，其中：

• X 指向東方，與地面相切。
• Y 指向北方，與地面相切。
• Z指向天空並垂直於地面。

手機的方向由將東-北-上坐標與手機坐標對齊所需的旋轉來表示。也就是說，將旋轉應用於世界框架 (X,Y,Z) 將使它們與手機坐標 (x,y,z) 對齊。

旋轉可以看作是圍繞軸rot_axis將手機旋轉角度 theta 以從參考（東-北-上對齊）設備方向到當前設備方向。旋轉被編碼為單位四元數的四個無單位 x、y、z、w 分量：

• 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)

在哪裡：

• rot_axis的 x、y 和 z 字段是表示旋轉軸的單位長度向量的東-北-上坐標
• theta是旋轉角度

四元數是單位四元數：它必須是范數1 。未能確保這一點將導致​​不穩定的客戶端行為。

此外，該傳感器報告估計的航向精度：

sensors_event_t.data[4] = estimated_accuracy （以弧度為單位）

航向誤差必須在 95% 的時間內小於estimated_accuracy 。該傳感器必須使用陀螺儀作為主要方向變化輸入。

該傳感器還使用加速度計和磁力計輸入來彌補陀螺儀漂移，僅使用加速度計和磁力計無法實現。

遊戲旋轉矢量

底層物理傳感器：加速度計和陀螺儀（無磁力計）

報告模式：連續

getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR)返回非喚醒傳感器

遊戲旋轉矢量傳感器類似於旋轉矢量傳感器，但不使用地磁場。因此 Y 軸不指向北方，而是指向其他參考。允許該參考漂移與陀螺儀繞 Z 軸漂移相同的數量級。

有關如何設置sensors_event_t.data[0-3]的詳細信息，請參閱旋轉矢量傳感器。此傳感器不報告估計的航向精度： sensors_event_t.data[4]已保留，應設置為0 。

在理想情況下，手機旋轉並返回到相同的真實世界方向應該報告相同的遊戲旋轉向量。

該傳感器必須基於陀螺儀和加速度計。它不能使用磁力計作為輸入，此外，通過估計陀螺儀偏置間接。

重力

底層物理傳感器：加速度計和（如果有）陀螺儀（或磁力計，如果沒有陀螺儀）

報告模式：連續

getDefaultSensor(SENSOR_TYPE_GRAVITY)返回非喚醒傳感器

重力傳感器報告設備坐標中重力的方向和大小。

在sensors_event_t.acceleration的 x、y 和 z 字段中以 m/s^2 報告重力矢量分量。

當設備處於靜止狀態時，重力傳感器的輸出應與加速度計的輸出相同。在地球上，震級約為 9.8 m/s^2。

如果設備有陀螺儀，重力傳感器必須使用陀螺儀和加速度計作為輸入。

如果設備沒有陀螺儀，重力傳感器必須使用加速度計和磁力計作為輸入。

地磁旋轉矢量

底層物理傳感器：加速度計和磁力計（無陀螺儀）

報告模式：連續

低電量

getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR)返回非喚醒傳感器

地磁旋轉矢量類似於旋轉矢量傳感器，但使用磁力計且沒有陀螺儀。

該傳感器必須基於磁力計。它不能使用陀螺儀來實現，並且該傳感器不能使用陀螺儀輸入。

有關如何設置sensors_event_t.data[0-4]的詳細信息，請參閱旋轉矢量傳感器。

就像旋轉矢量傳感器一樣，95% 的時間航向誤差必須小於估計精度 ( sensors_event_t.data[4] )。

這個傳感器必須是低功耗的，所以它必須在硬件中實現。

方向（已棄用）

底層物理傳感器：加速度計、磁力計和（如果有）陀螺儀

報告模式：連續

getDefaultSensor(SENSOR_TYPE_ORIENTATION)返回非喚醒傳感器

注意：這是一種較舊的傳感器類型，已在 Android SDK 中棄用。它已經被旋轉矢量傳感器所取代，它的定義更加清晰。盡可能在方向傳感器上使用旋轉矢量傳感器。

方向傳感器報告設備的姿態。測量值在sensors_event_t.orientation的 x、y 和 z 字段中以度數報告：

• sensors_event_t.orientation.x : 方位角，磁北方向和 Y 軸之間的角度，圍繞 Z 軸 ( 0<=azimuth<360 )。 0=北，90=東，180=南，270=西。
• sensors_event_t.orientation.y ：俯仰，繞 X 軸旋轉 ( -180<=pitch<=180 )，當 Z 軸向 Y 軸移動時為正值。
• sensors_event_t.orientation.z ：滾動，繞 Y 軸旋轉 ( -90<=roll<=90 )，當 X 軸向 Z 軸移動時為正值。

請注意，由於歷史原因，滾動角在順時針方向上為正。 （從數學上講，逆時針方向應該是正數）：

圖 3.相對於設備的方向

這個定義不同於航空中使用的偏航、俯仰和滾動，其中 X 軸沿著飛機的長邊（機尾到機頭）。

方向傳感器還通過sensors_event_t.orientation.status報告它期望其讀數的準確度。有關此字段可能值的更多信息，請參閱SensorManager的SENSOR_STATUS_*常量。

未校準的傳感器

未校準的傳感器提供更多的原始結果，並且可能包含一些偏差，但也包含更少的來自通過校準應用的校正的“跳躍”。一些應用程序可能更喜歡這些未經校準的結果，因為它們更流暢、更可靠。例如，如果一個應用程序試圖進行自己的傳感器融合，那麼引入校準實際上會扭曲結果。

加速度計未校準

底層物理傳感器：加速度計

報告模式：連續

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED)返回非喚醒傳感器

未經校準的加速度計傳感器報告設備沿三個傳感器軸的加速度，沒有任何偏差校正（工廠偏差和溫度補償應用於未經校準的測量）以及偏差估計。所有值均以 SI 單位 (m/s^2) 為單位，並在sensors_event_t.uncalibrated_accelerometer字段中報告：

• x_uncalib ：沿 X 軸的加速度（無偏置補償）
• y_uncalib ：沿 Y 軸的加速度（無偏置補償）
• z_uncalib ：沿 Z 軸的加速度（無偏置補償）
• x_bias ：沿 X 軸的估計偏差
• y_bias ：沿 Y 軸的估計偏差
• z_bias ：沿 Z 軸的估計偏差

陀螺儀未校準

底層物理傳感器：陀螺儀

報告模式：連續

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED)返回非喚醒傳感器

未校準的陀螺儀報告圍繞傳感器軸的旋轉速率，而不對其應用偏差補償，以及偏差估計。所有值都以弧度/秒為單位，並在sensors_event_t.uncalibrated_gyro的字段中報告：

• x_uncalib : 繞 X 軸的角速度（無漂移補償）
• y_uncalib : 繞 Y 軸的角速度（無漂移補償）
• z_uncalib : 繞 Z 軸的角速度（無漂移補償）
• x_bias : 估計繞 X 軸的漂移
• y_bias : 估計繞 Y 軸的漂移
• z_bias : 估計繞 Z 軸的漂移

從概念上講，未校準測量是校準測量和偏差估計的總和： _uncalibrated = _calibrated + _bias 。

x_bias 、 y_bias和z_bias值預計會在偏差估計值發生變化時立即跳躍，並且它們應該在其餘時間保持穩定。

有關使用的坐標系的詳細信息，請參見陀螺儀傳感器的定義。

必須對測量應用工廠校準和溫度補償。此外，必須實施陀螺儀漂移估計，以便可以在x_bias 、 y_bias和z_bias中報告合理的估計。如果實施無法估計漂移，則不得實施此傳感器。

如果存在此傳感器，則相應的陀螺儀傳感器也必須存在，並且兩個傳感器必須共享相同的sensor_t.name和sensor_t.vendor值。

未校準的磁場

底層物理傳感器：磁力計

報告模式：連續

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED)返回非喚醒傳感器

未校準的磁場傳感器報告環境磁場以及硬鐵校準估計。所有值均以微特斯拉 (uT) 為單位，並在sensors_event_t.uncalibrated_magnetic字段中報告：

• x_uncalib ：沿 X 軸的磁場（無硬鐵補償）
• y_uncalib : 沿 Y 軸的磁場（無硬鐵補償）
• z_uncalib ：沿 Z 軸的磁場（無硬鐵補償）
• x_bias ：沿 X 軸估計的硬鐵偏差
• y_bias ：沿 Y 軸估計的硬鐵偏差
• z_bias ：沿 Z 軸估計的硬鐵偏差

從概念上講，未校準測量是校準測量和偏差估計的總和： _uncalibrated = _calibrated + _bias 。

未經校準的磁力計允許更高級別的算法來處理壞的硬鐵估計。 x_bias 、 y_bias和z_bias值預計會在硬鐵估計值發生變化時立即跳躍，並且它們應該在其餘時間保持穩定。

測量時必須應用軟鐵校準和溫度補償。此外，必須實施硬鐵估計，以便可以在x_bias 、 y_bias和z_bias中報告合理的估計。如果實施無法估計偏差，則不得實施此傳感器。

如果存在此傳感器，則必須存在相應的磁場傳感器，並且兩個傳感器必須共享相同的sensor_t.name和sensor_t.vendor值。

鉸鏈角度

報告模式：變化

getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)返回喚醒傳感器

鉸鏈角度傳感器測量設備兩個組成部分之間的角度（以度為單位）。通過這種傳感器類型測量的鉸鏈的移動預計會改變用戶與設備交互的方式，例如，通過展開或顯示顯示器。

交互複合傳感器

一些傳感器主要用於檢測與用戶的交互。 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.

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
Game rotation vector	Attitude	Accelerometer, gyroscope, MUST NOT USE magnetometer	Continuous
Geomagnetic rotation vector	Attitude	Accelerometer, magnetometer, MUST NOT USE gyroscope	Continuous
Glance gesture	Interaction	Undefined	One-shot
Gravity	Attitude	Accelerometer, gyroscope	Continuous
Gyroscope uncalibrated	Uncalibrated	Gyroscope	Continuous
Linear acceleration	Activity	Accelerometer, gyroscope (if present), or magnetometer (if gyro not present)	Continuous
Magnetic field uncalibrated	Uncalibrated	Magnetometer	Continuous
Orientation (deprecated)	Attitude	Accelerometer, magnetometer, gyroscope (if present)	Continuous
Pick up gesture	Interaction	Undefined	One-shot
Rotation vector	Attitude	Accelerometer, magnetometer, gyroscope	Continuous
Significant motion	Activity	Accelerometer (or another as long as very low power)	One-shot
Step counter	Activity	Accelerometer	On-change
Step detector	Activity	Accelerometer	Special
Tilt detector	Activity	Accelerometer	Special
Wake up gesture	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.

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.