自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
暫停模式
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
SoC 電源狀態
晶片系統 (SoC) 的電源狀態包括開啟、閒置和暫停。「開啟」是指 SoC 正在執行時。「閒置」是一種中等電源模式,其中 SoC 已開啟電源,但不會執行任何工作。「Suspend」是 SoC 未通電的低耗電模式。裝置在這個模式下的耗電量通常比「開啟」模式少 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 開始,感應器定義中的標記會指定特定感應器是否為喚醒感應器。大多數感應器可透過同一個感應器的喚醒和非喚醒變化版本定義,在這種情況下,它們必須以兩個獨立的感應器運作,且不相互互動。詳情請參閱「互動」一文。
除非在感應器類型定義中另有指定,否則建議為 Sensor types 中列出的每個感應器類型實作一個喚醒感應器和一個非喚醒感應器。在每個感應器類型定義中,查看 SensorManager.getDefaultSensor(sensorType)
會傳回哪些感應器 (喚醒或非喚醒)。這是大多數應用程式都會使用的感應器。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間: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"]],["上次更新時間: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."]]