應用程序休眠

一個普通的 Android 用戶在他們的設備上安裝了 50 多個應用程序(隨著設備 RAM 層的增加,這個數字會增加)。但是,用戶在很長一段時間內都未使用大量這些應用程序。

應用休眠使用戶幾個月不使用的應用休眠,類似於權限自動撤銷。這會強制停止應用程序並將其置於我們針對存儲而不是性能進行優化的狀態。權限自動撤銷還捆綁了這種狀態,他們分享設置同樣的豁免設置。強制停止的應用程序不會在後台運行作業或警報,並且無法發送推送通知。當用戶再次使用該應用程序時,該應用程序會退出休眠狀態,並且作業/警報/通知會像往常一樣再次運行。在應用程序進入休眠狀態之前安排的任何作業/警報/通知都需要重新安排。

修改平台的 OEM 可能會與應用程序休眠實現發生衝突。例如

  • 修改應用使用定義或引入不在 AOSP 中的應用喚醒方式可能會中斷應用休眠的準確性
  • 類似於應用程序休眠的 OEM 專有限制機制可能會執行類似的目的。雖然兩者都可以存在,但可能會有一些重疊。

CDD概述了基於應用程序的使用,類似於現有的改變了一套新的要求3.5.1的要求。應用程序休眠遵循這些要求。

框架代碼位於:

策略邏輯存在於:

  • 回購:平台/包/模塊/權限
  • 目錄:PermissionController/src/com/android/permissioncontroller/hibernation

高層架構

應用休眠系統服務優化用戶不常用應用的存儲,並防止這些應用在後台運行。為了實現這些結果,當我們使應用程序休眠時,我們特別:

  • 自動撤銷權限
  • 強制停止應用程序
  • 刪除 ODEX 和 VDEX 文件
  • 刪除應用緩存

我們的目標是將休眠實現為可逆操作,以便用戶仍然可以通過啟動器和其他應用程序數據完整的界面使用該應用程序。啟動應用程序後,我們會將其從強制停止狀態恢復,並像往常一樣繼續創建 ODEX 和 VDEX 文件。

規劃的設計圍繞兩個主要部分:

  • 確定包何時應該休眠
  • 優化休眠包

一個新的系統服務, AppHibernationService和就業服務, AppHibernationJobService,PermissionController是膠水控制整個決策和邏輯。

當一個包應該冬眠主要由動力確定UsageStatsService和通過管理AppHibernationJobServicePermissionController 。這一政策的邏輯生命PermissionController ,使我們能夠通過動態更新的主線。此外,我們計劃增加一個新的信號,組件使用,到封裝的組件捕獲使用(例如,服務,內容提供商)作為新指標UsageStatsService

優化包是所有實際節省/優化發生的地方。 AppHibernationService與系統的各個部分停止包,刪除緩存數據,刪除ART文物等進行通信。撤銷許可直接從發起AppHibernationJobService在Android上11和較低的設備保留自動撤銷功能。

用戶體驗

向用戶提供有關哪些應用程序可以休眠的信息和控制權。

與自動撤銷類似,用戶會收到有關哪些應用程序處於休眠狀態的通知,並且可以選擇直接從通知中轉到“設置”以打開應用程序並使其退出休眠狀態,或者在需要時刪除未使用的應用程序。

我們繼續支持開發人員通過現有權限自動撤銷豁免意圖要求用戶豁免休眠的意圖。

向後兼容

從 Android 12 開始提供休眠特定功能。這些功能無法在早期版本上運行,因為平台組件(例如新系統服務)不存在。自動撤銷繼續按照當前為早期操作系統版本實施的方式運行。

正在啟動Android 12,以確保向後兼容性,休眠切換的應用程序和通知下的應用程序的頁面上的設置,同時保持權限子菜單中的原始自動撤銷切換添加。此切換控制應用程序的整體應用程序休眠系統豁免。

定制

由於某些實現是模塊化系統組件的一部分,因此不鼓勵合作夥伴修改該功能。合作夥伴可以改為實施類似的特性/功能,只要他們遵循 CDD 要求即可。

對於所有面向 Android 11 或更高版本的應用程序,應用程序休眠應默認為開啟。這與權限自動撤銷相同。雖然設置本身可能為 ON,但針對 Android 11 和 Android 11 的應用程序之間的應用程序休眠實現可能有所不同(即,應用程序休眠僅適用於針對 Android 11 的應用程序,而它本質上只是針對針對 Android 11 的應用程序自動撤銷。

此外,OEM 可能正在實施類似的功能。但是,這些功能針對電池優化的時間要短得多,這可能是 OEM 特定的。任何類似的應用限制功能由OEM開發可以共存與App休眠系統,只要它們滿足所定義的現有標準CDD

測試

應用程序休眠具有 CTS 和單元測試,以確保其正常工作。