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