センサーの種類

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

このセクションでは、センサー軸、ベース センサー、および複合センサー (アクティビティ、姿勢、未調整、および相互作用) について説明します。

センサー軸

多くのセンサーからのセンサー イベント値は、デバイスに対して静的な特定のフレームで表現されます。

モバイル機器の軸

センサー API は、画面の自然な向きに対してのみ相対的です (デバイスの画面の向きが変わっても、軸はスワップされません。

モバイル端末向けセンサー API の座標系

図 1. Sensor API で使用される座標系 (モバイル デバイスを基準)

自動車軸

Android Automotive の実装では、軸は車体フレームに対して定義されます。車両基準座標系の原点は、後車軸の中心です。車両基準フレームは、次のように方向付けられます。

  • X 軸は右向きで、車両の対称面に垂直な水平面上にあります。
  • Y 軸は前方を指し、水平面上にあります。
車載用センサー API の座標系

図 2. Sensor API で使用される座標系 (自動車デバイスに関連)

車両基準座標系は右手座標系です。したがって、Z 軸は上を指します。

参照フレームの Z 軸は重力に合わせられます。これは、X 軸と Y 軸が両方とも水平であることを意味します。その結果、Y 軸が常にフロント アクスルを通過するとは限りません。

ベースセンサー

基本センサー タイプは、それらが表す物理センサーにちなんで命名されます。これらのセンサーは、単一の物理センサーからデータを中継します (他のセンサーからデータを生成する複合センサーとは対照的です)。ベース センサー タイプの例は次のとおりです。

  • SENSOR_TYPE_ACCELEROMETER
  • SENSOR_TYPE_GYROSCOPE
  • SENSOR_TYPE_MAGNETOMETER

ただし、ベース センサーは、基礎となる物理センサーと同じではなく、混同しないでください。ベース センサーからのデータは、補正 (バイアス補正や温度補正など) が適用されるため、物理センサーの生の出力ではありません

たとえば、次のユース ケースでは、ベース センサーの特性が、その基礎となる物理センサーの特性と異なる場合があります。

  • 1 度/秒のバイアス範囲を持つと評価されたジャイロスコープ チップ。
    • 工場出荷時のキャリブレーション、温度補償、およびバイアス補償が適用された後、Android センサーの実際のバイアスは減少し、バイアスが 0.01 度/秒未満であることが保証されるポイントになる場合があります。
    • この状況では、基盤となるセンサーのデータシートには 1 度/秒と記載されていても、Android センサーのバイアスは 0.01 度/秒未満であると言えます。
  • 消費電力100uWの気圧計。
    • 生成されたデータはチップから SoC に転送する必要があるため、気圧計 Android センサーからデータを収集するための実際の電力コストは、1000 uW など、はるかに高くなる可能性があります。
    • この状況では、気圧計チップ リードで測定された消費電力が 100uW であっても、Android センサーの消費電力は 1000uW であると言います。
  • 校正時に 100uW を消費する磁力計ですが、校正時にはさらに消費します。
    • そのキャリブレーション ルーチンでは、ジャイロスコープをアクティブにして 5000 uW を消費し、さらに 900 uW のコストで何らかのアルゴリズムを実行する必要があります。
    • この状況では、(磁力計) Android センサーの最大消費電力は 6000 uW です。
    • この場合、平均消費電力がより有用な尺度であり、HAL を介してセンサーの静的特性で報告されるものです。

加速度計

レポートモード:連続

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER)は非ウェイクアップ センサーを返します

加速度計センサーは、3 つのセンサー軸に沿ったデバイスの加速度を報告します。測定された加速度には、物理​​的な加速度 (速度の変化) と重力の両方が含まれます。測定値は、sensors_event_t.acceleration の x、y、および z フィールドで報告されます。

すべての値は SI 単位 (m/s^2) であり、デバイスの加速度から 3 つのセンサー軸に沿って重力を引いた値を測定します。

以下に例を示します。

  • (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を介して、測定値がどの程度正確であるかを報告します。このフィールドで可能な値の詳細については、 SensorManagerSENSOR_STATUS_*定数を参照してください。

周囲温度

レポートモード:変更

getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE)は非ウェイクアップ センサーを返します

このセンサーは、周囲 (室温) を摂氏で提供します。

磁場センサー

レポートモード:連続

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD)は非ウェイクアップ センサーを返します

SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD

磁場センサー (磁力計とも呼ばれます) は、3 つのセンサー軸に沿って測定された周囲の磁場を報告します。

測定値は、 sensors_event_t.magneticの x、y、および z フィールドで報告され、すべての値はマイクロテスラ (uT) 単位です。

磁力計は、 sensors_event_t.magnetic.statusを介して、測定値がどの程度正確であるかを報告します。このフィールドで可能な値の詳細については、 SensorManagerSENSOR_STATUS_*定数を参照してください。

読み取り値は、以下を使用して校正されます。

  • 温度補償
  • 工場(またはオンライン)軟鉄校正
  • オンライン硬鉄キャリブレーション

ジャイロスコープ

レポートモード:連続

getDefaultSensor(SENSOR_TYPE_GYROSCOPE)は非ウェイクアップ センサーを返します

ジャイロスコープ センサーは、3 つのセンサー軸を中心としたデバイスの回転速度を報告します。

回転は反時計回りが正です (右手の法則)。つまり、原点に配置されたデバイスを x、y、または z 軸上の正の位置から見ている観察者は、デバイスが反時計回りに回転しているように見える場合、正の回転を報告します。これは、正の回転の標準的な数学的定義であり、ロールの航空宇宙の定義とは一致しないことに注意してください。

測定値は、 sensors_event_t.gyroの x、y、および z フィールドで報告され、すべての値はラジアン/秒 (rad/s) です。

読み取り値は、以下を使用して校正されます。

  • 温度補償
  • 工場(またはオンライン)スケール補正
  • オンライン バイアス キャリブレーション (ドリフトを除去するため)

ジャイロスコープは、 sensors_event_t.gyro.statusを介して、測定値がどの程度正確であるかを報告します。このフィールドで可能な値の詳細については、 SensorManagerSENSOR_STATUS_*定数を参照してください。

ジャイロスコープは、磁力計と加速度計に基づいてエミュレートすることはできません。これにより、ローカルの一貫性と応答性が低下する可能性があります。通常のジャイロスコープチップに基づいている必要があります。

心拍数

レポートモード:変更

getDefaultSensor(SENSOR_TYPE_HEART_RATE)は非ウェイクアップ センサーを返します

心拍数センサーは、デバイスに触れている人の現在の心拍数を報告します。

現在の心拍数 (BPM) はsensors_event_t.heart_rate.bpmで報告され、センサーのステータスはsensors_event_t.heart_rate.statusで報告されます。このフィールドで可能な値の詳細については、 SensorManagerSENSOR_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)は非ウェイクアップ センサーを返します

相対湿度センサーは、周囲の相対湿度を測定し、パーセントで値を返します。

複合センサーの種類

複合センサーは、1 つまたは複数の物理センサーからのデータを処理および/または融合することによってデータを生成します。 (ベース センサー以外のセンサーは複合センサーと呼ばれます。) 複合センサーの例は次のとおりです。

  • 通常は加速度計に基づいていますが、消費電力と精度が許容できる場合は、他のセンサーにも基づいている可能性があります。
  • 加速度計とジャイロスコープに基づく、ゲームの回転ベクトル
  • キャリブレーションされていないジャイロスコープ。ジャイロスコープのベース センサーに似ていますが、測定で補正されるのではなく、バイアス キャリブレーションが個別に報告されます。

基本センサーと同様に、複合センサーの特性は最終データの特性から得られます。たとえば、ゲームの回転ベクトルの消費電力は、おそらく加速度計チップ、ジャイロスコープ チップ、データを処理するチップ、およびデータを転送するバスの消費電力の合計に等しくなります。別の例として、ゲームの回転ベクトルのドリフトは、物理センサーの特性と同じくらいキャリブレーション アルゴリズムの品質に依存します。

次の表に、使用可能な複合センサー タイプを示します。各複合センサーは、1 つまたは複数の物理センサーからのデータに依存します。ユーザーエクスペリエンスが低下するため、結果を近似するために他の基礎となる物理センサーを選択しないでください。

センサータイプカテゴリー基礎となる物理センサーレポート モード

ゲームの回転ベクトル

態度

加速度計、ジャイロスコープ、磁力計は使用しないでください

連続

地磁気回転ベクトル低電力センサー

態度

加速度計、磁力計、ジャイロスコープは使用しないでください

連続

視線ジェスチャー低電力センサー

交流

未定義

ワンショット

重力

態度

加速度計、ジャイロスコープ

連続

ジャイロスコープ未校正

未校正

ジャイロスコープ

連続

線形加速度

アクティビティ

加速度計、ジャイロスコープ (存在する場合)、または磁力計 (ジャイロが存在しない場合)

連続

磁場未校正

未校正

磁力計

連続

方向(非推奨)

態度

加速度計、磁力計、ジャイロスコープ (存在する場合)

連続

ピックアップジェスチャー低電力センサー

交流

未定義

ワンショット

回転ベクトル

態度

加速度計、磁力計、ジャイロスコープ

連続

大きな動き低電力センサー

アクティビティ

加速度計(または非常に低電力である限り別のもの)

ワンショット

ステップカウンター低電力センサー

アクティビティ

加速度計

変更時

ステップ検出器低電力センサー

アクティビティ

加速度計

特別な

傾き検出器低電力センサー

アクティビティ

加速度計

特別な

ウェイクアップ ジェスチャー低電力センサー

交流

未定義

ワンショット

低電力センサー = 低電力センサー

活動複合センサー

線形加速度

基盤となる物理センサー: 加速度計と (存在する場合) ジャイロスコープ (ジャイロスコープが存在しない場合は磁力計)

レポートモード:連続

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を報告します。

ステップ検出器

基礎となる物理センサー: 加速度計 (+ 低電力である限り他のセンサー)

レポートモード:特別(実行されるステップごとに 1 つのイベント)

低電力

getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR)は非ウェイクアップ センサーを返します

歩数検出器は、ユーザーが一歩を踏み出すたびにイベントを生成します。

イベントsensors_event_t.timestampのタイムスタンプは、足が地面に当たったときに対応し、加速度の大きな変動を生成します。

歩数カウンターと比較して、歩数検出器は待ち時間が短い (2 秒未満) 必要があります。歩数検出器と歩数カウンターの両方が、ユーザーが歩いているか、走っているか、階段を上っているかを検出します。ユーザーが自転車に乗っているとき、運転中、または他の乗り物に乗っているときは、トリガーしないでください。

このセンサーは低電力でなければなりません。つまり、ステップ検出がハードウェアで実行できない場合、このセンサーは定義されるべきではありません。特に、歩数検出器が有効になっていて加速度計が有効になっていない場合は、歩数だけが割り込みをトリガーする必要があります (すべての加速度計の読み取りではありません)。

sampling_period_nsは、ステップ検出器には影響しません。

各センサー イベントは、 sensors_event_t.data[0]1を報告します。

ステップカウンター

基礎となる物理センサー: 加速度計 (+ 低電力である限り他のセンサー)

レポートモード:変更

低電力

getDefaultSensor(SENSOR_TYPE_STEP_COUNTER)は非ウェイクアップ センサーを返します

ステップ カウンターは、アクティブ化された最後の再起動以降にユーザーが実行したステップ数を報告します。

測定値は、 uint64_tsensors_event_t.step_counterとして報告され、システムの再起動時にのみゼロにリセットされます。

イベントのタイムスタンプは、そのイベントの最後のステップが実行された時刻に設定されます。

ステップの時間の意味については、ステップ検出センサーのタイプを参照してください。

歩数検出器と比較して、歩数カウンターは待ち時間が長くなる可能性があります (最大 10 秒)。この遅延のおかげで、このセンサーは高い精度を備えています。 1 日測定した後の歩数は、実際の歩数の 10% 以内である必要があります。歩数検出器と歩数カウンターの両方が、ユーザーが歩いているか、走っているか、階段を上っているかを検出します。ユーザーが自転車に乗っているとき、運転中、または他の乗り物に乗っているときは、トリガーしないでください。

ハードウェアは、内部ステップ カウントがオーバーフローしないようにする必要があります。ハードウェアの内部カウンタの最小サイズは 16 ビットです。差し迫ったオーバーフローの場合 (多くても ~2^16 ステップごと)、SoC を起動して、ドライバーがカウンターのメンテナンスを実行できるようにすることができます。

相互作用で述べたように、このセンサーが動作している間は、他のセンサー、特に使用中の可能性が非常に高い加速度計を妨害してはなりません。

特定のデバイスがこれらの動作モードをサポートできない場合、このセンサーの種類は HAL によって報告されてはなりません。つまり、HAL でこのセンサーを「エミュレート」することはできません。

このセンサーは低電力でなければなりません。つまり、ステップ検出がハードウェアで実行できない場合、このセンサーは定義されるべきではありません。特に、ステップ カウンターがアクティブで、加速度計がアクティブでない場合は、ステップのみが割り込みをトリガーする必要があります (加速度センサー データではありません)。

傾き検出器

基礎となる物理センサー: 加速度計 (+ 低電力である限り他のセンサー)

レポートモード:特別

低電力

このセンサーのウェイクアップ バージョンのみを実装します。

getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR)はウェイクアップ センサーを返します

傾斜検出器は、傾斜イベントが検出されるたびにイベントを生成します。

傾斜イベントは、アクティブ化またはセンサーによって生成された最後のイベント以降、少なくとも 35 度変化する 2 秒間のウィンドウ平均重力の方向によって定義されます。アルゴリズムは次のとおりです。

  • reference_estimated_gravity = アクティベーション後の最初の 1 秒間の加速度計測定値の平均、または最後の傾斜イベントが生成されたときの推定重力。
  • 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)は非ウェイクアップ センサーを返します

回転ベクトル センサーは、East-North-Up 座標フレームに対するデバイスの向きを報告します。通常、加速度計、ジャイロスコープ、磁力計の読み取り値を統合することによって得られます。 East-North-Up 座標系は、次の正規直交基底として定義されます。

  • X は東を指し、地面に接しています。
  • Y は北を指し、地面に接しています。
  • Z は空を指し、地面に対して垂直です。

電話の向きは、East-North-Up 座標を電話の座標に合わせるために必要な回転によって表されます。つまり、回転をワールド フレーム (X、Y、Z) に適用すると、電話座標 (x、y、z) に合わせられます。

回転は、参照 (East-North-Up に揃えられた) デバイスの向きから現在のデバイスの向きに移動するために、軸rot_axisを中心に角度 theta だけ電話を回転させると見なすことができます。回転は、単位四元数の 4 つの単位のない 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を介して、その読み取り値がどれほど正確であるかを報告します。このフィールドで可能な値の詳細については、 SensorManagerSENSOR_STATUS_*定数を参照してください。

校正されていないセンサー

キャリブレーションされていないセンサーは、より生の結果を提供し、多少のバイアスが含まれる可能性がありますが、キャリブレーションによって適用された補正による「ジャンプ」も少なくなります。一部のアプリは、これらの調整されていない結果を、よりスムーズで信頼性の高いものとして好む場合があります。たとえば、アプリが独自のセンサー フュージョンを実行しようとしている場合、キャリブレーションを導入すると実際に結果が歪む可能性があります。

加速度計が校正されていません

基盤となる物理センサー: 加速度計

レポートモード:連続

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED)は非ウェイクアップ センサーを返します

キャリブレーションされていない加速度計センサーは、3 つのセンサー軸に沿ったデバイスの加速度をバイアス補正なしで報告します (キャリブレーションされていない測定値には工場バイアスと温度補償が適用されます)。すべての値は 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_biasy_bias 、およびz_biasの値は、バイアスの推定値が変化するとすぐにジャンプすると予想され、残りの時間は安定しているはずです。

使用される座標系の詳細については、ジャイロセンサーの定義を参照してください。

工場での校正と温度補正を測定に適用する必要があります。また、 x_biasy_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_biasy_bias 、およびz_biasの値は、ハードアイアンの推定値が変化するとすぐにジャンプすると予想され、残りの時間は安定しているはずです。

軟鉄校正と温度補正を測定に適用する必要があります。また、 x_biasy_bias 、およびz_biasで妥当な推定を報告できるように、厳格な推定を実装する必要があります。実装でバイアスを推定できない場合は、このセンサーを実装してはなりません。

このセンサーが存在する場合、対応する磁場センサーが存在する必要があり、両方のセンサーが同じsensor_t.nameおよびsensor_t.vendor値を共有する必要があります。

ヒンジ角度

レポートモード:変更

getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)はウェイクアップ センサーを返します

ヒンジ角度センサーは、デバイスの 2 つの一体部分の間の角度を度単位で測定します。このタイプのセンサーによって測定されるヒンジの動きは、ユーザーがディスプレイを展開したり表示したりするなど、デバイスと対話する方法を変更すると予想されます。

相互作用複合センサー

一部のセンサーは、主にユーザーとのやり取りを検出するために使用されます。 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.

Coordinate
system of sensor API for mobile devices

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.
Coordinate system of sensor API for
automotive devices

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 Low
     power sensor

Attitude

Accelerometer, magnetometer, MUST NOT USE gyroscope

Continuous

Glance gesture Low power sensor

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 Low power sensor

Interaction

Undefined

One-shot

Rotation vector

Attitude

Accelerometer, magnetometer, gyroscope

Continuous

Significant motion Low power sensor

Activity

Accelerometer (or another as long as very low power)

One-shot

Step counter Low power sensor

Activity

Accelerometer

On-change

Step detector Low power sensor

Activity

Accelerometer

Special

Tilt detector Low power sensor

Activity

Accelerometer

Special

Wake up gesture Low power sensor

Interaction

Undefined

One-shot

Low power sensor = 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):

Depiction of orientation
   relative to a device

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.