バックグラウンド
以前は、フォアグラウンドのIntentServiceを使用して、次々と発生するさまざまなイベントを処理していました。その後、Android 11 (Android R、API 30) で非推奨になり、代わりにsetForegroundAsyncを使用する Worker を使用することを好むと言われたので、それを実行しました。
val builder = NotificationCompat.Builder(context,...)...
setForegroundAsync(ForegroundInfo(notificationId, builder.build()))
問題
Android 12 が登場したため (Android S、API 31)、 の 1 つ後のバージョンsetForegroundAsyncが非推奨としてマークされ、代わりにsetExpeditedを使用するように指示されました。
* @deprecated Use {@link WorkRequest.Builder#setExpedited(OutOfQuotaPolicy)} and
* {@link ListenableWorker#getForegroundInfoAsync()} instead.
問題は、それが正確にどのように機能するかわかりません。以前は、フォアグラウンド サービスを使用しているため、ユーザーに表示する必要がある通知がありました (少なくとも「古い」Android バージョンの場合)。getForegroundInfoAsyncが使用されているようですが、Android 12 では使用されないと思います。
Android S より前では、WorkManager はユーザーに代わってフォアグラウンド サービスを管理および実行して WorkRequest を実行し、ForegroundInfo で提供される通知を表示します。この通知を後で更新するために、アプリケーションは NotificationManager を使用できます。
Android S 以降では、WorkManager は即時ジョブを使用してこの WorkRequest を管理します。
それについての別の手がかりは（こちら）です：
WorkManager 2.7.0 から、アプリは setExpedited() を呼び出して、Worker が優先ジョブを使用する必要があることを宣言できます。この新しい API は、Android 12 での実行時に優先ジョブを使用し、API は以前のバージョンの Android でフォアグラウンド サービスを使用して下位互換性を提供します。
そして、彼らが持っている唯一のスニペットは、スケジューリング自体のものです:
OneTimeWorkRequestBuilder<T>().apply {
setInputData(inputData)
setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)
}.build()
OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUESTのドキュメントでさえ奇妙に思えます:
アプリに優先ジョブ クォータがない場合、優先作業リクエストは通常の作業リクエストにフォールバックします。
私が望んでいたのは、中断することなく (または少なくとも可能な限り低い可能性で) すぐに確実に何かを実行し、OS が提供するものは何でも使用することだけでした。
なぜsetExpedited作成されたのかわかりません。
質問
- 正確にはどのように機能し
setExpeditedますか? - この「急募定員」とは何ですか？この状況になると Android 12 ではどうなりますか? 労働者はすぐに仕事をしませんか？
setExpeditedフォアグラウンド サービスと同じくらい信頼できますか? いつでもすぐに起動できますか?- の利点、欠点、および制限
setExpeditedは何ですか? フォアグラウンド サービスより優先する必要があるのはなぜですか? - アプリが Android 12 でこの API を使用している場合、ユーザーには何も表示されないということですか?