Background
----------

In the past, I used a foreground [**IntentService**](https://developer.android.com/reference/android/app/IntentService) to handle various events that come one after another. Then it was deprecated when Android 11 came (Android R, API 30) and it was said to prefer to use Worker that uses [**setForegroundAsync**](https://developer.android.com/reference/androidx/work/ListenableWorker#setForegroundAsync(androidx.work.ForegroundInfo)) instead, and so I did it.

```
val builder = NotificationCompat.Builder(context,...)...
setForegroundAsync(ForegroundInfo(notificationId, builder.build()))

```

The problem
-----------

As Android 12 came (Android S, API 31), just one version after , now `setForegroundAsync` is marked as deprecated, and I am told to use [**setExpedited**](https://developer.android.com/reference/androidx/work/WorkRequest.Builder#setExpedited(androidx.work.OutOfQuotaPolicy)) instead:

```
* @deprecated Use {@link WorkRequest.Builder#setExpedited(OutOfQuotaPolicy)} and
* {@link ListenableWorker#getForegroundInfoAsync()} instead.

```

Thing is, I'm not sure how it works exactly. Before, we had a notification that should be shown to the user as it's using a foreground service (at least for "old" Android versions). Now it seems that [**getForegroundInfoAsync**](https://developer.android.com/reference/androidx/work/ListenableWorker#getForegroundInfoAsync()) is used for it, but I don't think it will use it for Android 12 :

> 
> Prior to Android S, WorkManager manages and runs a foreground service
> on your behalf to execute the WorkRequest, showing the notification
> provided in the ForegroundInfo. To update this notification
> subsequently, the application can use NotificationManager.
> 
> 
> Starting in Android S and above, WorkManager manages this WorkRequest
> using an immediate job.
> 
> 
> 

Another clue about it is ([**here**](https://developer.android.com/about/versions/12/foreground-services#recommended-alternative)) :

> 
> Starting in WorkManager 2.7.0, your app can call setExpedited() to
> declare that a Worker should use an expedited job. This new API uses
> expedited jobs when running on Android 12, and the API uses foreground
> services on prior versions of Android to provide backward
> compatibility.
> 
> 
> 

And the only snippet they have is of the scheduling itself :

```
OneTimeWorkRequestBuilder<T>().apply {
    setInputData(inputData)
    setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)
}.build()

```

Even the docs of [OutOfQuotaPolicy.RUN\_AS\_NON\_EXPEDITED\_WORK\_REQUEST](https://developer.android.com/reference/androidx/work/OutOfQuotaPolicy#RUN_AS_NON_EXPEDITED_WORK_REQUEST) seems weird:

> 
> When the app does not have any expedited job quota, the expedited work
> request will fallback to a regular work request.
> 
> 
> 

All I wanted is just to do something right away, reliably, without interruption (or at least lowest chance possible), and use whatever the OS offers to do it.

I don't get why `setExpedited` was created.

The questions
-------------

1. How does `setExpedited` work exactly ?
2. What is this "expedited job quota" ? What happens on Android 12 when it reaches this situation? The worker won't do its job right away?
3. Is `setExpedited` as reliable as a foreground service? Would it always be able to launch right away?
4. What are the advantages, disadvantages and restrictions that `setExpedited` has ? Why should I prefer it over a foreground service?
5. Does it mean that users won't see anything when the app is using this API on Android 12 ?