掛起模式

SoC 電源狀態

片上系統 (SoC) 的電源狀態為:開啟、空閒和掛起。 “開”是 SoC 運行時。 “空閒”是一種中等功率模式,其中 SoC 已通電但不執行任何任務。 “掛起”是一種低功耗模式,其中 SoC 未通電。該模式下設備的功耗通常比“開啟”模式下的功耗低 100 倍。

非喚醒傳感器

非喚醒傳感器是不阻止 SoC 進入掛起模式並且不喚醒 SoC 以報告數據的傳感器。特別是,不允許驅動程序持有喚醒鎖。如果應用程序希望在屏幕關閉時接收來自非喚醒傳感器的事件,則保持部分喚醒鎖定是應用程序的責任。當 SoC 處於掛起模式時,傳感器必須繼續運行並生成事件,這些事件被放入硬件 FIFO。 (有關更多詳細信息,請參閱批處理。) FIFO 中的事件在 SoC 喚醒時被傳遞給應用程序。如果 FIFO 太小而無法存儲所有事件,則較舊的事件會丟失;最舊的數據被丟棄以容納最新的數據。在 FIFO 不存在的極端情況下,SoC 處於掛起模式時生成的所有事件都將丟失。一個例外是來自每個 on-change 傳感器的最新事件:最後一個事件必須保存在 FIFO 之外,這樣它就不會丟失。

一旦 SoC 退出掛起模式,就會報告 FIFO 中的所有事件,並且操作會恢復正常。

使用非喚醒傳感器的應用程序應該保持喚醒鎖定以確保系統不會掛起,在不需要傳感器時從傳感器取消註冊,或者在 SoC 處於掛起模式時預期丟失事件。

喚醒傳感器

與非喚醒傳感器相反,喚醒傳感器確保它們的數據獨立於 SoC 的狀態傳遞。當 SoC 處於喚醒狀態時,喚醒傳感器的行為類似於非喚醒傳感器。當 SoC 處於睡眠狀態時,喚醒傳感器必須喚醒 SoC 以傳遞事件。他們仍然必須讓 SoC 進入掛起模式,但還必須在需要報告事件時喚醒它。也就是說,傳感器必須在最大報告延遲過去或硬件 FIFO 變滿之前喚醒 SoC 並傳遞事件。有關詳細信息,請參閱批處理

為確保應用程序有時間在 SoC 重新進入睡眠狀態之前接收事件,驅動程序必須在每次報告事件時將“超時喚醒鎖定”保持 200 毫秒。也就是說,不應允許 SoC 在喚醒中斷後的 200 毫秒內重新進入睡眠狀態。此要求將在未來的 Android 版本中消失,在此之前我們需要此超時喚醒鎖。

如何定義喚醒和非喚醒傳感器?

在 KitKat 之前,傳感器是喚醒傳感器還是非喚醒傳感器取決於傳感器類型:大多數是非喚醒傳感器,但接近傳感器和重要運動檢測器除外。

從 L 開始,給定傳感器是否為喚醒傳感器由傳感器定義中的標誌指定。大多數傳感器可以由同一傳感器的一對喚醒和非喚醒變體定義,在這種情況下,它們必須表現為兩個獨立的傳感器,而不是相互交互。有關詳細信息,請參閱交互

除非在傳感器類型定義中另有規定,否則建議為傳感器類型中列出的每種傳感器類型實現一個喚醒傳感器和一個非喚醒傳感器。在每個傳感器類型定義中,查看SensorManager.getDefaultSensor(sensorType) 。它是大多數應用程序將使用的傳感器。