平均的なAndroidユーザーは、デバイスに50以上のアプリをインストールします(デバイスのRAM層が増えると、その数は増えます)。ただし、これらのアプリのかなりの数は、ユーザーが長期間使用していません。
アプリの休止状態は、権限の自動取り消しと同様に、ユーザーが数か月間使用しないアプリを休止状態にします。これにより、アプリが強制的に停止され、パフォーマンスではなくストレージを最適化する状態になります。権限の自動取り消しもこの状態にバンドルされており、 [設定]の同じ免除設定を共有します。強制停止されたアプリは、バックグラウンドでジョブやアラートを実行せず、プッシュ通知を送信できません。ユーザーがアプリを再度使用すると、アプリは休止状態を終了し、ジョブ/アラート/通知が通常どおり実行されます。アプリが休止状態になる前にスケジュールされたジョブ/アラート/通知は、再スケジュールする必要があります。
プラットフォームを変更するOEMは、アプリの休止状態の実装と競合する可能性があります。例えば
- アプリの使用法の定義を変更したり、AOSPにないアプリをウェイクアップする方法を導入したりすると、アプリの休止状態の精度が低下する可能性があります
- アプリの休止状態と同様のOEM独自の制限メカニズムは、同様の目的を実行する場合があります。両方が存在する可能性がありますが、いくつかの重複がある可能性があります。
CDDは、既存の3.5.1要件と同様に、アプリの使用に基づく変更の新しい一連の要件の概要を示しています。アプリの休止状態はこれらの要件に従います。
フレームワークコードは次の場所にあります。
- リポジトリ:プラットフォーム/フレームワーク/ベース
- ディレクトリ: services / core / java / com / android / server / apphibernation
ポリシーロジックは次の場所にあります。
- リポジトリ:プラットフォーム/パッケージ/モジュール/権限
- ディレクトリ:PermissionController / src / com / android / permitcontroller / hibernation
高レベルのアーキテクチャ
App Hibernationシステムサービスは、ユーザーの使用頻度の低いアプリをストレージ用に最適化し、それらのアプリがバックグラウンドで実行されないようにします。これらの結果を達成するために、アプリを休止状態にするときは、具体的に次のことを行います。
- 権限を自動取り消す
- 強制-アプリを停止します
- ODEXファイルとVDEXファイルを削除します
- アプリのキャッシュを削除する
私たちの目標は、休止状態をリバーシブルアクションとして実装し、アプリデータをそのままにしてランチャーやその他のサーフェスを介してユーザーがアプリを引き続き利用できるようにすることです。アプリを起動すると、強制停止状態から復元し、通常どおりODEXおよびVDEXファイルの作成を続行します。
計画されている設計は、次の2つの主要部分を中心にしています。
- パッケージが休止状態になるタイミングを決定する
- 休止状態パッケージの最適化
PermissionController
の新しいシステムサービスAppHibernationService
とジョブサービスAppHibernationJobService,
は、全体的な意思決定とロジックを制御する接着剤です。
パッケージを休止状態にするタイミングの決定は、主にUsageStatsServiceによってAppHibernationJobService
され、 PermissionController
のUsageStatsService
によって管理されます。このポリシーロジックはPermissionController
に存在し、Mainlineを介して動的に更新できるようにします。さらに、 UsageStatsService
の新しいメトリックとして、パッケージのコンポーネント(サービス、コンテンツプロバイダーなど)の使用状況をキャプチャするために、新しいシグナルであるコンポーネントの使用状況を追加する予定です。
パッケージの最適化は、すべての実際の節約/最適化が行われる場所です。 AppHibernationService
は、システムのさまざまな部分と通信して、パッケージの停止、キャッシュデータの削除、ARTアーティファクトの削除などを行います。権限の取り消しはAppHibernationJobService
から直接開始され、Android11以下のデバイスで自動取り消し機能を保持します。
ユーザー体験
ユーザーには、休止状態にすることができるアプリに関する情報とコントロールの両方が提供されます。
自動取り消しと同様に、ユーザーは休止状態になっているアプリに関する通知を受け取り、通知から直接[設定]に移動して、アプリを開いて休止状態から解除するか、必要に応じて未使用のアプリを削除するかを選択できます。
既存の権限の自動取り消し免除インテントを介して、ユーザーに休止状態の免除を要求するという開発者のインテントを引き続きサポートします。
下位互換性
Android 12以降、休止状態固有の機能を利用できます。これらの機能は、プラットフォームコンポーネント(新しいシステムサービスなど)が存在しないため、以前のバージョンでは機能しませんでした。自動取り消しは、以前のOSバージョンで現在実装されているとおりに機能し続けます。
Android 12以降、下位互換性を確保するために、[設定]の[アプリと通知]の下のアプリのページに休止状態の切り替えが追加され、[権限]サブメニュー内の元の自動取り消しの切り替えが維持されます。このトグルは、アプリの全体的なアプリ休止状態システムの免除を制御します。
カスタマイズ
一部の実装はモジュラーシステムコンポーネントの一部であるため、パートナーは機能を変更することをお勧めしません。パートナーは、CDD要件に準拠している限り、代わりに同様の機能を実装できます。
Android 11以降を対象とするすべてのアプリでは、アプリの休止状態はデフォルトでオンになっている必要があります。これは、権限の自動取り消しと同じです。設定自体はオンになっている場合がありますが、アプリの休止状態の実装は、Android11を対象とするアプリとAndroid12を対象とするアプリで異なる場合があります。具体的には、アプリの休止状態はAndroid 11を対象とするアプリでのみ機能しますが、基本的にはAndroid12を対象とするアプリでは自動取り消しされます。
さらに、OEMは同様の機能を実装している可能性があります。ただし、これらの機能は、OEM固有のバッテリー最適化のために、はるかに短いタイムスケールを対象としています。 OEMによって開発された同様のアプリ制限機能は、 CDDで定義された既存の基準を満たしている限り、アプリハイバネーションシステムと共存できます。
テスト
アプリの休止状態には、正しく機能していることを確認するためのCTSと単体テストがあります。
- AutoRevokeTest
- AppHibernationIntegrationTest