I have read that WorkManager 2.7.0 is needed if an app targets API 31/Android 12, and in order to do that, I have added setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) to my OneTimeWorkRequestBuilder and added the necessary changes in the AndroidManifest as well. Now running my app I've encountered the following error:

java.util.concurrent.ExecutionException: java.util.concurrent.ExecutionException: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Expedited WorkRequests require a ListenableWorker to provide an implementation for `getForegroundInfoAsync()`

So I tried looking up info on how to do implement this, and found no examples available from official Google sources (Github, developers.android.com, changelog, etc), but found this

answer over in Stackoverflow, but it is for Coroutines.

My question is how do you implement the said getForegroundInfoAsync for RxWorker when getForegroundInfoAsync has to return ListenableFuture<ForegroundInfo>--reading the docs it seems I have to add Guava to my app to do this? Since the docs for ListenableFuture says to Avoid implementing ListenableFuture from scratch. If you can't get by with the standard implementations, prefer to derive a new Future instance with the methods in Futures or, if necessary, to extend AbstractFuture.

I also have tried adding a SettableFuture but it is annotated with @RestrictTo(RestrictTo.Scope.LIBRARY_GROUP)

Nvm, I just annotated my implementation of getForegroundInfoAsync with @SuppressLint("RestrictedApi") and created a SettableFuture. It seems to work well.

You're right, we should add Rx support for this method.

In meanwhile, you can use CallbackToFutureAdapter instead of restricted API. It is safer that SettableFuture and allows you avoid dependency on restricted APIs.

Thanks for showing that callback. Honestly this whole getForegroundInfoAsync is still unclear to me--since I'm using RxWorker, I usually create a notification inside createWork and when the work is ongoing, I display a notification with progress bar via doOnSubscribe, something like this:

    api.doSomeWork()
       .doOnSubscribe { 
           // display notification with progress bar
           setForegroundAsync(ForegroundInfo(notificationId, notificationBuilder.build()))
       }

So how getForegroundInfoAsync fits into this, I don't understand. The effect of implementing getForegroundInfoAsync is that I actually get two notifications, the one that displays a progress bar that's already full, and another one that's actually updated.

Edit: actually never mind, getForegroundInfoAsync has nothing to do with having two notifs. Just figured it out and getForegroundInfoAsync is called before createWork.

https://issuetracker.google.com/issues/157590191

Yep. That's what got this issue filed after all ;-)

Heh, of course.

Is there a way the internal code can keep a ref to that new callback once its set, and reference it instead of installing or unwrap?

This goes beyond my familiarity with (and available time to invest in understanding) the existing codebase -- I'd have to defer to Chris.

I don't think there's a perfect solution here to be honest. I'm thinking that reverting to the previous solution is the only 'correct' way forward for the 80% case.

If apps want to change the window callback, they can override setSupportActionBar() and do it in there, after calling super.

That won't work for libraries. The callback delegation allows libraries to play nice together. We shouldn't one library (appcompat) break all othee libraries.

Looking into this a bit more, it seems that what we really need to do is:

1. Install the callback only once and keep a ref to it.
2. Decouple the callback from ToolbarActionBar, so that we can swap the ToolbarActionBar instance receiving things (or set it to null)

Maybe 1) and 2) means actually killing the callback and adding a nullable ToolbarActionBar to the default callback already install? That'd simplify things a lot it seems.

Thoughts? I can maybe take a stab in between 2 diaper changes.

Yeah, that should be do-able. Looking now.

https://android-review.googlesource.com/c/platform/frameworks/support/+/1696341