パーミッションの仕様変更(API≧30)~(3)アプリの休止~

投稿日:  更新日:

パーミッションシステムの仕様変更がAPI≧30で行われています。

 (1)1回だけアクセス許可
 (2)“今後表示しない”の非表示
 (3)アプリの休止

ここでは、「(3)アプリの休止」について説明します。

スポンサーリンク

休止とは

数ヶ月にわたってアプリが操作されなかった時に、アプリが持つ必要最小限のリソースを残して、その他をクリアすることです。

休止対象のアプリへ、次の処理を行います。

・Runtime Permissionの取得をリセット(削除)
・一時データ(キャッシュ)を消去 ※API≧31のみ

休止が行われると、ユーザに通知が届きます。

Api30Api31
アプリの休止の通知(Api30,Android11)
アプリの休止の通知(Api31,Android12)

上記の処理に加えて、アプリのアンインストールへユーザを導くようになっていますが、アンインストールするかどうかはユーザ次第です。

アプリの休止についての詳細は「App hibernation」を参照してください。

スポンサーリンク

休止の条件

「アプリが操作されていない」と判断する具体的な条件は、次のようなものです。

・Activityがフォアグラウンドにない(表示されていない)
・Activity以外のコンポーネントが呼び出されていない ※API≧31のみ

 【コンポーネントの例】
  他アプリによりバインドされたサービス
  他アプリにより呼び出された明示的なブロードキャストレシーバー
  他アプリにより照会されたコンテンツプロバイダー

・ウィジェットを操作していない ※API≧31のみ
・Notificationを操作していない(閉じることを除く)※API≧31のみ

これらの条件を数ヶ月にわたって満たしていれば、アプリは休止になります。

アプリの休止の条件

「数ヶ月にわたって」がどういう状態かと言えば...

システムの内部では、「check_frequency間隔で判定を行ったとき、休止の条件を満たしてからunused_threshold以上経過した」状態です。

逆に条件から外れた動きがあると、システムはそのイベントをユーザの操作と見なして、休止を解除します。

実際は図中で示したように、APIのプログラムへデフォルト値が埋め込まれているので、約90~105日経過したら休止です。

デフォルト値はAndroidのブート時のログ出力(例はエミュレータのログ出力)で確認できます。

API30API31
※パッケージ名:com.android.permissioncontroller
          :
... I/AutoRevokePermissions: Parsed teamfood setting value: null
... I/AutoRevokePermissions: Parsed teamfood setting value: null
... I/AutoRevokePermissions: scheduleAutoRevokePermissions with frequency 1296000000ms and threshold 7776000000ms
... I/AutoRevokePermissions: user 0 is a profile owner. Running Auto Revoke.
... I/AutoRevokePermissions: Parsed teamfood setting value: null
... I/AutoRevokePermissions: onStartJob
... I/AutoRevokePermissions: Skipping auto revoke first run when scheduled by system
          :
※パッケージ名:com.google.android.permissioncontroller
          :
... I/HibernationPolicy: scheduleHibernationJob with frequency 1296000000ms and threshold 7776000000ms
... I/HibernationPolicy: user 0 is a profileowner. Running hibernation job.
... I/HibernationPolicy: No existing job, scheduling a new one
... I/HibernationPolicy: onStartJob
... I/HibernationPolicy: Skipping auto revoke first run when scheduled by system
          :
スポンサーリンク

休止の影響範囲

「アプリの休止」は、端末で稼働しているAndroidのバージョンと、アプリがビルドされた時のtargetSDKの関係により、その動作に違いがあります。

端末のOStargetSDK休止の影響管理ページ 
≧Android12
(API31)
≧31Permissionの取得をリセット
一時データ(キャッシュ)のクリア
「アプリ情報」
Android11
(API30)
 30Permissionの取得をリセット
Android6~10
(API23~29)
「Playプロテクト」
※休止の仕様をAPI<30へバックポート(移植)、Google Play Service+Play Storeで実現
API23~29における「アプリの休止」
「アプリの休止」はAPI≧30で追加された機能です。しかし、API23~29に対してもバックポート(移植)が行われています。

この場合、APIに実装されているのではなく、Google Play ServiceとPlay Storeアプリの連携により実現されている点に注意してください。

対応は2021.12以降に順次行われているので、「アプリの休止」を端末に反映させたければ、この両者を最新版へアップデートする必要があります。

スポンサーリンク

休止の判定解除

「アプリの休止」はデフォルトでOn(有効)になっています。

しかし、管理ページからユーザの手によってOff(無効)に切り替えが可能です。

API23~29(参考)API30API31
アプリの休止の判定解除
アプリの休止の判定解除
アプリの休止の判定解除
スポンサーリンク

Permissionの状態変化

休止の発動後に、granted=trueからfalseに変化します。

> adb shell dumpsys package パッケージ名

【バックグラウンドへ遷移(直後)】
runtime permissions:
android.permission.ACCESS_FINE_LOCATION: granted=true, 
  flags=[ USER_SET|USER_SENSITIVE_WHEN_GRANTED|..._DENIED]
android.permission.ACCESS_COARSE_LOCATION: granted=true, 
  flags=[ USER_SET|USER_SENSITIVE_WHEN_GRANTED|..._DENIED]

【アプリの休止後】
runtime permissions:
android.permission.ACCESS_FINE_LOCATION: granted=false, 
  flags=[ REVOKED_COMPAT|USER_SENSITIVE_WHEN_GRANTED|..._DENIED|AUTO_REVOKED]
android.permission.ACCESS_COARSE_LOCATION: granted=false, 
  flags=[ REVOKED_COMPAT|USER_SENSITIVE_WHEN_GRANTED|..._DENIED|AUTO_REVOKED]

※...:左のフラグと同じ接頭辞ため省略
スポンサーリンク

休止からの復帰動作

アプリの休止後、

復帰はonStartからスタートします。また、onSave/onRestoreInstanceStateが有効になっています。

ケース
他のアプリ起動(Bgへ)
履歴から復帰(Fgへ、通常)
履歴から復帰(Fgへ、休止後)
※Fg:フォアグラウンド、Bg:バックグラウンド
※API≧28の場合、onStop ⇒ onSaveInstanceStateの順番
スポンサーリンク

関連記事:

Androidは携帯端末のOSで、スマートフォンに適しています。 スマート(Smart)とは「賢い・洗練された」といった意味を持つ形容詞です。 Androidはこの「スマート」をユーザ自身の手で育てることが出来ます。 どのように育てるのか! それは世界中の開発者からリリースされているアプリをインストールして育てます。 より高機能なアプリ、より使い勝手の良いアプリを探してインストールすれば、あなたのスマートフォンはもっと「スマート」になるでしょう! しかし、アプリは良心的なものばかりではありません。中には悪意を持ったアプリも存在します。 悪意を持ったアプリから、ユーザを守る仕組みの1つがPermissionです。 ここまではユーザ目線でした。 逆にアプリの開発者目線で言えば、Permissionはアプリの安全性をユーザにアピールする手段でもありあます。 今回は、このPermissionについてまとめます。 ...
続きを読む
Install-time(Normal)Permissionの取得方法についてまとめます。 Permissionの詳細は「Permissionとその一覧」を参照してください。 ...
続きを読む
Runtime(Dangerous)Permissionの取得方法についてまとめます。 現在、Runtime Permissoinの取得方法は2つあります。 ここで紹介するのはRuntime Permission(API≧23)が登場した当初から存在している方法です。 この方法は、リクエスト(Permissionの申請)の結果を共用のコールバックAppCompatActivity#onRequestPermissionsResult( )で受け取ります。複数のリクエスト行うと、複数の結果を一つのコールバックで受けることになり、コールバック内でRequestCodeによる分岐が必要になります。 つまり、「開発者がリクエストを管理」しなければなりません。 Permissionの詳細は「Permissionとその一覧」を参照してください。 ...
続きを読む
Runtime(Dangerous)Permissionの取得方法についてまとめます。 現在、Runtime Permissoinの取得方法は2つあります。 ここで紹介するのは、ActivityResultContracts(※)を使う方法です。 この方法は、リクエスト(Permissionの申請)と結果を受け取る専用のコールバックが1対1に対応しています。ですので、複数のリクエストを行っても、RequestCodeによる分岐処理は必要ありません。システムが結果を各コールバックへ割り振ってくれます。 つまり、「システムがリクエストを管理」してくれます。 ドキュメントで推奨されている方法です。 Permissionの詳細は「Permissionとその一覧」を参照してください。 ※ライブラリandroidx.activity:activity≧1.20が必要 ...
続きを読む
パーミッションシステムの仕様変更がAPI≧30で行われています。  (1)1回だけアクセス許可  (2)“今後表示しない”の非表示  (3)アプリの休止 ここでは、「(1)1回だけアクセス許可」について説明します。 ...
続きを読む
パーミッションシステムの仕様変更がAPI≧30で行われています。  (1)1回だけアクセス許可  (2)“今後表示しない”の非表示  (3)アプリの休止 ここでは、「(2)“今後表示しない”の非表示」について説明します。 ...
続きを読む
「アプリの休止(App hibernation)」は発動までの期間が長いので、端末上で実際にその動作を確認しようとすると、待機時間が長くなってしまい、効率が悪いです。 ですので、テストでは「アプリの休止」を手動で発動させます。 今回は、この手動で発動させる方法を説明します。 ...
続きを読む
数ヶ月にわたってアプリが操作されなかった時に、アプリは休止状態(アプリの休止)になり、自動的にRuntime Permissionがリセット(削除)されます。 この機能はデフォルトで有効(On)です。 しかし、このPermissionのリセットを、良しとしないアプリが存在するかも知れません。 そのようなアプリのために、管理ページからユーザによって機能を無効(Off)にできます。 また、プログラム中から管理ページへユーザを誘導できます。 この「管理ページへユーザを誘導する方法」を紹介します。デベロッパーブログにも紹介されています。 ...
続きを読む
スポンサーリンク