[Android] Force-stop Handlingの適用（ExposureNotification SDKアップデート）

[keiji]

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

#123 の検討過程で提案をもらったもの。

#123 (comment)

一部端末でバックグラウンドタスクが実行されない。実行されてもキャンセルされる場合がある現象が確認されている。

通常アプリはユーザーやシステムから強制停止されると、次回起動するまでバックグラウンドタスクの実行が制限される（スケジュールされない）。一部の端末ではバッテリー消費を低減する目的で、自動的にアプリを強制停止している可能性がある。

解決策についてお書きください / Describe the solution you'd like

「Force-stop Handling」はExposure Notification APIのバージョン1.5から追加された機能。

Google Play ServicesがEN APIを使っているアプリのプロセスを再起動することで、強制停止の状態から復帰させる。

Force-stop handlingについて、具体的な適用方法についてGoogleから回答を得ている。

• SDK v1.5 以降へのアップデートが必要
• SDKのアップデートで利用可能になる

とのことで、まずXamarin.GooglePlayServices.Nearby.ExposureNotificationをアップデートすることになる（現在は18.0.2-eap.6）。

---

バージョンアップについては以前Pull Request（ #22 ）をもらっています。現時点で一気に更新してしまうのは避けて、ライブラリをそれぞれアップデートしていきたいので、こちらで巻き取らせてくださいと調整済です。

---

Internal Tracking ID: NFR 2262

[keiji]

Xamarin.GooglePlayServices.Nearby.ExposureNotificationについては現在、手に入る最新のバージョンは19.7.1-eap.1となっている。

https://www.nuget.org/packages/Xamarin.GooglePlayServices.Nearby.ExposureNotification/

19.7.1-eap.1が使っているSDKはplay-services-nearby-exposurenotification-1.7.1-eap.aarなので、これでForce-stop Handlingは有効になる。

https://github.com/xamarin/XamarinComponents/blob/f39add7ad854c3a8d8ad6a9284220a3d1073e055/Android/ExposureNotification/build.cake#L3-L4

---

個人的には、最新のplay-services-nearby-exposurenotification-1.8.3-eap.aarを参照したバージョンを作ってあるので、こちらが使えないかなとも思います。

xamarin/XamarinComponents#1133

こちらはPreAuthorizeにも対応しています（COCOAでは利用していませんが）。

PRは提出済みです（Support PreAuthorization）。Microsoftの人、マージしてくれないかなぁ…

[tmurakami]

ご無沙汰しております。

#123 (comment) でおっしゃっていた

COCOAの場合はApplicationのonCreateでWorkerを登録する

対応は不要という回答を Google から頂いたということでしょうか？
私も @keiji さんと同じようにApplication#onCreateで WorkRequest を enqueue する必要があると考えていたので、ちょっと意外です。

EDIT

私が理解(推測)している内容を追記しておきます。

play-services-nearby-exposurenotificationの aar には以下のような WakeUpService (com.google.android.gms.nearby.exposurenotification.WakeUpService) が含まれています。
https://github.com/google/exposure-notifications-internals/blob/aa75f5c834aacdcad2aa29d899ba882295b31d16/exposurenotification/src/main/java/com/google/samples/exposurenotification/nearby/WakeUpService.java

この Service は 6時間毎に Play Service から bind されます。
EN アプリのプロセスが無い場合はそのタイミングでApplication#onCreateが呼ばれるので、そこで Worker のスケジュールを行って下さい、ということなのだと思っています。

[keiji]

Application.onCreateでのWorker登録については質問に含めていますが、ライブラリのアップデートのみとのことでした（後述するテストで動作確認が取れたので、本当に要らないのかと再質問はしていません）。

ぼくの手元でも、つぎのPull RequestでビルドしたAPKをインストールしてテストをしてみました。
#141

1. COCOAをインストールして利用を開始する
2. adb shell dumpsys jobscheduler でJobSchedulerの登録状態を確認する
3. adb shell am force-stop [APP_PACKAGE_NAME] でアプリを強制停止する
4. adb shell dumpsys jobscheduler でJobSchedulerの登録状態を確認して、アプリのJobがない（消えている）ことを確認する
5. 6時間程度待つ（Force-stop handlingでアプリの再有効化）
6. adb shell dumpsys jobscheduler でJobSchedulerの登録状態を確認して、アプリのJobがある（復帰している）ことを確認する

この手順で、アプリのJobが復帰していることを確認しています。なお、アプリの設定画面から「強制停止」を選択するとJobは復帰しなかったので、adb shell am force-stop とは意味合いが異なる様子です。

バックグラウンドでの動作安定化については取り組みを続けていく予定です。ApplicationでのWorker登録に切り替える選択肢も持っておきたいと考えています。

[tmurakami]

@keiji お返事ありがとうございます。

この手順で、アプリのJobが復帰していることを確認しています。

#141 に書いていましたね。失礼致しました。

[keiji]

それにしてもドキドキしますよね。
ExistingPeriodicWorkPolicy もKEEPになっているのでWorker登録自体をApplication側に移動してもいいかもしれません。

[tmurakami]

FYI です。

force-stop された場合は WorkManager 初期化時に Job を復元するようです。
https://github.com/androidx/androidx/blob/9b770633fafed35c5185f1cc2b52612a451ccdb9/work/workmanager/src/main/java/androidx/work/impl/utils/ForceStopRunnable.java

PendingIntent が force-stop でクリアされることを利用して force-stop かどうか判別しているようです。
https://github.com/androidx/androidx/blob/9b770633fafed35c5185f1cc2b52612a451ccdb9/work/workmanager/src/main/java/androidx/work/impl/utils/ForceStopRunnable.java#L146-L167

そこのコメントに書いてありますが、いくつかの OEM (コミットメッセージによるとsome popular devices) では AlarmManager のバグにより SecurityException が発生するらしいので

• WorkManager のバージョンアップ ( update Xamarin.AndroidX.Work.Runtime from 2.3.4.1 to 2.5.0.1 #181 )
• Application#onCreateで再スケジュール

のどちらか (もしくは両方) の対応を合わせて実施したほうが安全かもしれません。

[keiji]

WorkManagerのバージョンアップについてはしない理由がないので、あとは施策として追加でApplication#onCreateで再スケジュールするように変更するかどうかですね。

AlarmManagerでSecurityExceptionについては、現在COCOAがターゲットにしているバージョンで動作するWorkManagerは、バックエンドにAlarmManagerを使わない（JobSchedulerを使う）と理解しているのですが、ぼくもWorkManagerのすべての実装を見たわけではありませんし、リスクを低減する意味でもApplication#onCreate移動は検討したいです（その場合にiOS側のスケジューラーに影響があるかも念のため確認します）。