自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
挂起模式
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
SoC 电源状态
系统芯片 (SoC) 的电源状态包括:开启、空闲和挂起。“开启”表示 SoC 正在运行。“空闲”表示一种中等耗电模式,在该模式下,SoC 已接通电源但不执行任何任务。“挂起”表示 SoC 未通电的低功耗模式。该模式下的设备功耗通常是“开启”模式的 1/100。
非唤醒传感器
非唤醒传感器是不阻止 SoC 进入挂起模式也不会将 SoC 唤醒以报告数据的传感器。具体来讲,就是不允许驱动程序持有唤醒锁定。如果应用要在屏幕关闭时从非唤醒传感器处接收事件,则必须自行保留部分唤醒锁定。当 SoC 处于挂起模式时,传感器必须继续工作并生成事件,这些事件会放入硬件 FIFO 中(如需了解详情,请参阅批处理)。当 SoC 唤醒时,FIFO 中的事件将传送到应用。如果 FIFO 太小而无法存储所有事件,则较旧的事件将丢失;最旧的数据将被删除以容纳最新的数据。在不存在 FIFO 的极端情况下,在 SoC 处于挂起模式时生成的所有事件都将丢失。一种例外情况是来自每个采用变化时触发模式的传感器最新事件:最后一个事件必须保存在 FIFO 之外,以使其不会丢失。
一旦 SoC 退出挂起模式,就会报告来自 FIFO 的所有事件,并且操作将恢复正常。
使用非唤醒传感器的应用要么应持有唤醒锁定以确保系统不会挂起,在不需要传感器时取消注册传感器,要么接受 SoC 处于挂起模式期间的事件会丢失这一事实。
唤醒传感器
与非唤醒传感器相反,唤醒传感器会确保其数据传输不依赖于 SoC 状态。当 SoC 唤醒时,唤醒传感器的行为与非唤醒传感器相同。当 SoC 休眠时,唤醒传感器必须唤醒 SoC 以发送事件。它们必须仍可让 SoC 进入挂起模式,但是当需要报告事件时,还必须唤醒 SoC。也就是说,在达到最大报告延迟时间或硬件 FIFO 已满之前,传感器必须唤醒 SoC 并传送事件。如需了解详情,请参阅批处理。
为确保应用有时间在 SoC 返回休眠状态之前接收事件,每次报告事件时,驱动程序必须持有“超时唤醒锁定”200 毫秒。也就是说,在唤醒中断后的 200 毫秒内,不允许 SoC 返回休眠状态。此要求将在未来的 Android 版本中消失,在此之前,我们需要该超时唤醒锁定。
如何定义唤醒和非唤醒传感器?
在 KitKat 及更早版本中,某个传感器是唤醒传感器还是非唤醒传感器取决于传感器类型:除近程传感器和大幅度动作检测器之外,大多数传感器都是非唤醒传感器。
从 L 版本开始,传感器是否为唤醒传感器由传感器定义中的标记指定。大多数传感器均可由同一传感器的唤醒和非唤醒变体对来定义,在这种情况下,它们必须作为两个独立的传感器运行,且彼此不进行交互。有关详情,请参阅交互性。
除非在传感器类型定义中另行指定,否则建议为传感器类型中列出的每种传感器类型各实现一个唤醒传感器和一个非唤醒传感器。在每个传感器类型定义中,查看 SensorManager.getDefaultSensor(sensorType)
将返回什么样的传感器(唤醒传感器还是非唤醒传感器)。它是大多数应用将使用的传感器。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[[["易于理解","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-07-27。"],[],[],null,["# Suspend mode\n\nSoC power states\n----------------\n\nThe power states of the system on a chip (SoC) are: on, idle, and suspend. \"On\" is when the\nSoC is running. \"Idle\" is a medium power mode where the SoC is powered but\ndoesn't perform any tasks. \"Suspend\" is a low-power mode where the SoC is not\npowered. The power consumption of the device in this mode is usually 100 times\nless than in the \"On\" mode.\n\nNon-wake-up sensors\n-------------------\n\nNon-wake-up sensors are sensors that do not prevent the SoC\nfrom going into suspend mode and do not wake the SoC up to report data. In\nparticular, the drivers are not allowed to hold wake-locks. It is the\nresponsibility of applications to keep a partial wake lock should they wish to\nreceive events from non-wake-up sensors while the screen is off. While the SoC\nis in suspend mode, the sensors must continue to function and generate events,\nwhich are put in a hardware FIFO. (See [Batching](/docs/core/interaction/sensors/batching) for more details.) The events in the\nFIFO are delivered to the applications when the SoC wakes up. If the FIFO is\ntoo small to store all events, the older events are lost; the oldest data is dropped to accommodate\nthe latest data. In the extreme case where the FIFO is nonexistent, all events\ngenerated while the SoC is in suspend mode are lost. One exception is the\nlatest event from each on-change sensor: the last event [must be saved](/docs/core/interaction/sensors/batching#precautions_to_take_when_batching_non-wake-up_on-change_sensors)outside of the FIFO so it cannot be lost.\n\nAs soon as the SoC gets out of suspend mode, all events from the FIFO are\nreported and operations resume as normal.\n\nApplications using non-wake-up sensors should either hold a wake lock to ensure\nthe system doesn't go to suspend, unregister from the sensors when they do\nnot need them, or expect to lose events while the SoC is in suspend mode.\n\nWake-up sensors\n---------------\n\nIn opposition to non-wake-up sensors, wake-up sensors ensure that their data is\ndelivered independently of the state of the SoC. While the SoC is awake, the\nwake-up sensors behave like non-wake-up-sensors. When the SoC is asleep,\nwake-up sensors must wake up the SoC to deliver events. They must still let the\nSoC go into suspend mode, but must also wake it up when an event needs to be\nreported. That is, the sensor must wake the SoC up and deliver the events\nbefore the maximum reporting latency has elapsed or the hardware FIFO gets full.\nSee [Batching](/docs/core/interaction/sensors/batching) for more details.\n\nTo ensure the applications have the time to receive the event before the SoC\ngoes back to sleep, the driver must hold a \"timeout wake lock\" for 200\nmilliseconds each time an event is being reported. *That is, the SoC should not\nbe allowed to go back to sleep in the 200 milliseconds following a wake-up\ninterrupt.* This requirement will disappear in a future Android release, and we\nneed this timeout wake lock until then.\n\nHow to define wake-up and non-wake-up sensors?\n----------------------------------------------\n\nUp to KitKat, whether a sensor was a wake-up or a non-wake-up sensor was\ndictated by the sensor type: most were non-wake-up sensors, with the exception\nof the [proximity](/docs/core/interaction/sensors/sensor-types#proximity) sensor and the [significant motion detector](/docs/core/interaction/sensors/sensor-types#significant_motion).\n\nStarting in L, whether a given sensor is a wake-up sensor or not is specified\nby a flag in the sensor definition. Most sensors can be defined by pairs of\nwake-up and non-wake-up variants of the same sensor, in which case they must\nbehave as two independent sensors, not interacting with one another. See\n[Interaction](/docs/core/interaction/sensors/interaction) for more details.\n\nUnless specified otherwise in the sensor type definition, it is recommended to\nimplement one wake-up sensor and one non-wake-up sensor for each sensor type\nlisted in [Sensor types](/docs/core/interaction/sensors/sensor-types). In each sensor type\ndefinition, see what sensor (wake-up or non-wake-up) will be returned by\n`SensorManager.getDefaultSensor(sensorType)`. It is the sensor\nthat most applications will use."]]