アプリの休止(App hibernation)を手動で発動(API≧30)

投稿日:  更新日:

「アプリの休止(App hibernation)」は発動までの期間が長いので、端末上で実際にその動作を確認しようとすると、待機時間が長くなってしまい、効率が悪いです。

ですので、テストでは「アプリの休止」を手動で発動させます。

今回は、この手動で発動させる方法を説明します。

スポンサーリンク

発動までの期間

「アプリの休止」についての詳細は「パーミッションの仕様変更(API≧30)~(3)アプリの休止~」を参照してください。

発動までの期間はcheck_frequencyとunused_thresholdで決まります。

アプリの休止の条件

「check_frequency間隔で判定を行ったとき、休止の条件を満たしてからunused_threshold以上経過した」状態が、発動までの期間です。

スポンサーリンク

期間の調整

check_frequencyとunused_thresholdを変更すれば、発動までの期間を調整できます。

パラメータの優先度

期間を調整する方法は3つあり、採用されるパラメータは優先順位を持ちます。

優先方法パラメータ※単位:[ms]
1Settings.GlobalunusedThresholdMs
checkFrequencyMs
※初期値:未設定
unused_threshold
check_frequency
2DeviceConfigauto_revoke_unused_threshold_millis2
auto_revoke_check_frequency_millis
※初期値:未設定
3ソース埋め込み7776000000(90[day])
1296000000(15[day])
※Settings:システムレベルの構成パラメータ
※DeviceConfig:デバイスレベルの構成パラメータ
※「未設定」の場合は採用から除外

優先順位とは例えば、ソース埋め込み⇒A、DeviceConfig⇒B、Settings.Glocal⇒Cならば、Cが採用されます。また、ソース埋め込み⇒A、DeviceConfig⇒未設定、Settings.Glocal⇒未設定ならば、Aが採用されます。

パラメータの変更

パラメータはプログラム中から変更できないため、adb shellのコマンドから行います。

Setting.GlobalDeviceConfig
【期間の調整】
> adb shell settings put global auto_revoke_parameters unusedThresholdMs=60000,checkFrequencyMs=900000

【期間の確認】
> adb shell settings get global auto_revoke_parameters
checkFrequencyMs=60000,unusedThresholdMs=900000  ... 1[m],15[m]

----------
> adb shell settings help
Settings provider (settings) commands:
  help
      Print this help text.
  get [--user <USER_ID> | current] NAMESPACE KEY
      Retrieve the current value of KEY.
  put [--user <USER_ID> | current] NAMESPACE KEY VALUE [TAG] [default]
      Change the contents of KEY to VALUE.
      TAG to associate with the setting.
      {default} to set as the default, case-insensitive only for global/secure namespace
  delete [--user <USER_ID> | current] NAMESPACE KEY
      Delete the entry for KEY.
  reset [--user <USER_ID> | current] NAMESPACE {PACKAGE_NAME | RESET_MODE}
      Reset the global/secure table for a package with mode.
      RESET_MODE is one of {untrusted_defaults, untrusted_clear, trusted_defaults}, case-insensitive
  list [--user <USER_ID> | current] NAMESPACE
      Print all defined keys.
      NAMESPACE is one of {system, secure, global}, case-insensitive
【期間の調整】
> adb shell device_config put permissions auto_revoke_unused_threshold_millis2 60000
> adb shell device_config put permissions auto_revoke_check_frequency_millis 900000

【期間の確認】
> adb shell device_config list permissions
auto_revoke_check_frequency_millis=60000     ... 1[m]
auto_revoke_unused_threshold_millis2=900000  ... 15[m]

----------
> adb shell device_config help
Device Config (device_config) commands:
  help
      Print this help text.
  get NAMESPACE KEY
      Retrieve the current value of KEY from the given NAMESPACE.
  put NAMESPACE KEY VALUE [default]
      Change the contents of KEY to VALUE for the given NAMESPACE.
      {default} to set as the default value.
  delete NAMESPACE KEY
      Delete the entry for KEY for the given NAMESPACE.
  list [NAMESPACE]
      Print all keys and values defined, optionally for the given NAMESPACE.
  reset RESET_MODE [NAMESPACE]
      Reset all flag values, optionally for a NAMESPACE, according to RESET_MODE.
      RESET_MODE is one of {untrusted_defaults, untrusted_clear, trusted_defaults}
      NAMESPACE limits which flags are reset if provided, otherwise all flags are reset

上記の場合、およそ15~16分後にアプリは休止状態へ遷移します。

判定を行うJob

休止の判定を行っているのは、jobschedulerによって周期的に起動されるService(jobschedulerではJobと表現される)です。API30の場合、AutoRevokeServiceがそれに当たります。

そして、check_frequencyがServiceの起動の条件として定義される周期です。

jobschedulerとは
jobschedulerはAPI21で追加されたAndroidのサービスです。
起動の条件とJob(Service ← アプリケーションコンポーネント)を登録すると、条件に一致したタイミングでJobを実行する機能を提供します。

adb shellコマンドを使えばjobschedulerの様子が確認できます。

※API30の端末で実行した結果

> adb shell dumpsys jobscheduler
          :
  JOB #u0a118/2: 8fe2d57 com.android.permissioncontroller/.permission.service.AutoRevokeService
    u0a118 tag=*job*/com.android.permissioncontroller/.permission.service.AutoRevokeService
    Source: uid=u0a118 user=0 pkg=com.android.permissioncontroller
    JobInfo:
      Service: com.android.permissioncontroller/.permission.service.AutoRevokeService
      PERIODIC: interval=+15m0s0ms flex=+15m0s0ms
      Requires: charging=false batteryNotLow=false deviceIdle=false
      Backoff: policy=1 initial=+30s0ms
      Has early constraint
      Has late constraint
	          :

注意:判定の周期は「最小:15分」間隔

jobschedulerによる起動の間隔は最小:15分(900000[ms])となっています。従って、<900000の値を設定しても900000として扱われます。
※[ms]:ミリセカンド、1/1000秒

注意:判定の周期は端末のBootで反映

休止の判定を行っているServiceは端末のBoot時にjobschedulerへ登録されます。従って、判定の周期を決めるcheck_frequencyはBootを行わなければ反映されません。

スポンサーリンク

直ちに発動

jobschedulerの定期的な実行を待たずに、直ちに「アプリの休止」を発動させることが可能です。

jobschedulerに起動の条件を無視して、Jobの強制的な実行を行わせます。

ただし、unused_thresholdは満たしている必要があります。

次のようなコマンドを用います。

【API=30】
> adb shell cmd jobscheduler run -u 0 -f com.android.permissioncontroller 2

【API>30】
> adb shell cmd jobscheduler run -u 0 -f com.google.android.permissioncontroller 2

----------
> adb shell cmd jobscheduler help
Job scheduler (jobscheduler) commands:
  help
    Print this help text.
  run [-f | --force] [-s | --satisfied] [-u | --user USER_ID] PACKAGE JOB_ID
    Trigger immediate execution of a specific scheduled job. For historical
    reasons, some constraints, such as battery, are ignored when this
    command is called. If you don't want any constraints to be ignored,
    include the -s flag.
    Options:
      -f or --force: run the job even if technical constraints such as
         connectivity are not currently met. This is incompatible with -f
         and so an error will be reported if both are given.
      -s or --satisfied: run the job only if all constraints are met.
         This is incompatible with -f and so an error will be reported
         if both are given.
      -u or --user: specify which user's job is to be run; the default is
         the primary or system user
  ...
スポンサーリンク

関連記事:

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)“今後表示しない”の非表示」について説明します。 ...
パーミッションシステムの仕様変更がAPI≧30で行われています。  (1)1回だけアクセス許可  (2)“今後表示しない”の非表示  (3)アプリの休止 ここでは、「(3)アプリの休止」について説明します。 ...
数ヶ月にわたってアプリが操作されなかった時に、アプリは休止状態(アプリの休止)になり、自動的にRuntime Permissionがリセット(削除)されます。 この機能はデフォルトで有効(On)です。 しかし、このPermissionのリセットを、良しとしないアプリが存在するかも知れません。 そのようなアプリのために、管理ページからユーザによって機能を無効(Off)にできます。 また、プログラム中から管理ページへユーザを誘導できます。 この「管理ページへユーザを誘導する方法」を紹介します。デベロッパーブログにも紹介されています。 ...
スポンサーリンク