自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
报告模式
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
传感器能够以不同的方式(称为报告模式)生成事件;每种传感器类型有且仅有一个与之关联的报告模式。共有 4 种报告模式。
连续
以传递给 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 秒,再站立 1 分钟。
- 在第一分钟,约每 10 秒生成一个事件(包括传感器激活时的
t=0
秒以及 t=60
秒),共有 7 个事件。在第二分钟,不生成任何事件,因为步数的值在 t=60
秒后没有发生变化。
单次模式
传感器一检测到事件便会自行禁用,然后通过 HAL 发送单个事件。顺序非常重要,可避免出现竞态条件。(在通过 HAL 报告事件之前,传感器必须处于禁用状态)。重新激活传感器之前,不会发送其他任何事件。大幅度动作传感器就是这样一种传感器。
单次模式传感器有时称为触发传感器。
传递给 batch
函数的 sampling_period_ns
和 max_report_latency_ns
参数会被忽略。来自单次事件的事件不可存储在硬件 FIFO 中;这些事件在生成后必须立即报告。
特别模式
如需详细了解何时生成事件,请参阅各传感器类型说明。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-26。
[[["易于理解","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"]],["最后更新时间 (UTC):2025-03-26。"],[],[],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."]]