自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
回報模式
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
感應器可透過不同方式產生事件,這些方式稱為回報模式;每種感應器類型都會與一個且只有一個回報模式相關聯。報表有四種模式。
連續
事件會以傳遞至 batch
函式的 sampling_period_ns
參數定義的固定頻率產生。使用持續回報模式的例子感應器包括加速計和陀螺儀。
變更時
只有在測量值有變動時,系統才會產生事件。在 HAL 層級啟用感應器 (對其呼叫 activate(..., enable=1)
) 也會觸發事件,也就是說,在啟用變更感應器時,HAL 必須立即傳回事件。使用變更時回報模式的例子感應器類型包括步數計、接近感應器和心率感應器。
傳遞至 batch
函式的 sampling_period_ns
參數用於設定連續事件之間的最短時間,也就是說,在最後一個事件發生後,必須經過 sampling_period_ns
奈秒,系統才會產生事件,即使該值在此期間有所變更也不例外。如果值有所變更,則必須在上次事件後的 sampling_period_ns
經過時間內產生事件。
舉例來說:
- 我們會使用
sampling_period_ns = 10 * 10^9
(10 秒) 啟用步數計數器。
- 我們會先走路 55 秒,然後站立一分鐘。
- 事件會在第一分鐘內每隔約 10 秒產生一次 (包括在
t=0
時間點,因為感應器已啟用,以及 t=60
秒),總共產生七個事件。由於步數在 t=60
秒後並未改變,因此第二分鐘不會產生事件。
單次
偵測到事件後,感應器會自動停用,然後透過 HAL 傳送單一事件。順序很重要,可避免競爭狀況。(必須先停用感應器,才能透過 HAL 回報事件)。除非感應器重新啟用,否則不會傳送其他事件。重大動作就是這類感應器的例子。
一次性感應器有時也稱為觸發器感應器。
系統會忽略傳遞至 batch
函式的 sampling_period_ns
和 max_report_latency_ns
參數。一次性事件的事件無法儲存在硬體 FIFO 中,必須在產生後立即回報。
特別節目
如要進一步瞭解事件產生時機,請參閱個別感應器類型說明。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[null,null,["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],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."]]