2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
レポートモード
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
センサーは、レポートモードと呼ばれるさまざまな方法でイベントを生成できます。各センサータイプには、レポートモードが 1 つだけ関連付けられています。レポートモードには 4 つの種類があります。
連続
batch
関数に渡される sampling_period_ns
パラメータで定義された一定の頻度でイベントが生成されます。連続レポートモードを使用するセンサーには、加速度計やジャイロスコープなどがあります。
変化時
測定値が変化した場合のみイベントが生成されます。
HAL レベルでセンサーをアクティブにする(HAL レベルで activate(..., enable=1)
を呼び出す)と、イベントもトリガーされます。つまり、変化時センサーがアクティブになったら HAL は直ちにイベントを返す必要があります。変化時レポートモードを使用するセンサーには、歩数計、近接センサー、心拍数センサータイプなどがあります。
batch
関数に渡される sampling_period_ns
パラメータは、連続するイベント間の最小時間を設定するために使用されます。つまり、最後のイベント以降に値が変化しても、最後のイベントからの経過時間が sampling_period_ns
ナノ秒に達していなければ、イベントは生成されません。値が変化した場合、最後のイベントからの経過時間が sampling_period_ns
に達したらすぐにイベントが生成される必要があります。
次のような例を考えてみましょう。
- 歩数計を
sampling_period_ns = 10 * 10^9
(10 秒)で有効にします。
- 55 秒間歩いてから 1 分間立ち止まります。
- 最初の 1 分間(センサー有効化のための
t=0
の時点と t=60
秒を含む)には、10 秒ごとに合計 7 つのイベントが生成されます。t=60
秒以降は歩数計の値が変化しなかったため、次の 1 分間はイベントが生成されません。
ワンショット
イベントが検出されると、センサーは無効になり、HAL を介して単一のイベントを送信します。競合状態を避けるためには順番が重要です(センサーは、HAL を介してイベントを報告する前に無効になる必要があります)。センサーが再度有効になるまで、他のイベントは送信されません。
この種類のセンサーには、大きなモーション センサーなどがあります。
ワンショット センサーは、トリガー センサーと呼ばれることもあります。
batch
関数に渡される sampling_period_ns
および max_report_latency_ns
パラメータは無視されます。ワンショット イベントからのイベントはハードウェア FIFO に格納できません。イベントは生成後すぐにレポートされる必要があります。
特別
イベントが生成されるタイミングの詳細については、個々のセンサータイプの説明をご覧ください。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-26 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-26 UTC。"],[],[],null,["# Reporting modes\n\nSensors can generate events in different ways called reporting modes;\neach sensor type has one and only one reporting mode associated with it.\nFour reporting modes exist.\n\nContinuous\n----------\n\nEvents are generated at a constant rate defined by the\n[sampling_period_ns](/docs/core/interaction/sensors/batching#sampling_period_ns)\nparameter passed to the `batch` function. Example sensors\nusing the continuous reporting mode are\n[accelerometers](/docs/core/interaction/sensors/sensor-types#accelerometer)\nand [gyroscopes](/docs/core/interaction/sensors/sensor-types#gyroscope).\n\nOn-change\n---------\n\nEvents are generated only if the measured values have changed.\nActivating the sensor at the HAL level (calling\n`activate(..., enable=1)` on it) also triggers an event,\nmeaning the HAL must return an event immediately when an on-change sensor\nis activated. Example sensors using the on-change reporting mode are the\nstep counter, proximity, and heart rate sensor types.\n\nThe\n[sampling_period_ns](/docs/core/interaction/sensors/batching#sampling_period_ns)\nparameter passed to the `batch` function is used to set the\nminimum time between consecutive events, meaning an event shouldn't be\ngenerated until `sampling_period_ns` nanoseconds elapsed since\nthe last event, even if the value changed since then. If the value changed,\nan event must be generated as soon as `sampling_period_ns` has\nelapsed since the last event.\n\nFor example, suppose:\n\n- We activate the step counter with `sampling_period_ns = 10 * 10^9` (10 seconds).\n- We walk for 55 seconds, then stand still for one minute.\n- The events are generated about every 10 seconds during the first minute (including at time `t=0` because of the activation of the sensor, and `t=60` seconds), for a total of seven events. No event is generated in the second minute because the value of the step count didn't change after `t=60` seconds.\n\nOne-shot\n--------\n\nUpon detection of an event, the sensor deactivates itself and then sends\na single event through the HAL. Order matters to avoid race conditions.\n(The sensor must be deactivated before the event is reported through the\nHAL). No other event is sent until the sensor is reactivated.\n[Significant\nmotion](/docs/core/interaction/sensors/sensor-types#significant_motion) is an example of this kind of sensor.\n\nOne-shot sensors are sometimes referred to as trigger sensors.\n\nThe `sampling_period_ns` and `max_report_latency_ns`\nparameters passed to the `batch` function are ignored. Events\nfrom one-shot events cannot be stored in hardware FIFOs; the events must\nbe reported as soon as they are generated.\n\nSpecial\n-------\n\nSee the individual [sensor type\ndescriptions](/docs/core/interaction/sensors/sensor-types) for details on when the events are generated."]]