Status Update
Comments
ad...@google.com <ad...@google.com>
ad...@google.com <ad...@google.com> #2
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
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
.
ad...@google.com <ad...@google.com> #3
I also have tried adding a SettableFuture
but it is annotated with @RestrictTo(RestrictTo.Scope.LIBRARY_GROUP)
ev...@willowtreeapps.com <ev...@willowtreeapps.com> #4
Nvm, I just annotated my implementation of getForegroundInfoAsync
with @SuppressLint("RestrictedApi")
and created a SettableFuture
. It seems to work well.
ev...@willowtreeapps.com <ev...@willowtreeapps.com> #5
You're right, we should add Rx support for this method.
In meanwhile, you can use SettableFuture
and allows you avoid dependency on restricted APIs.
Description
Version used: 1.0.0-alpha02
Devices/Android versions reproduced on: 26, 27, 28
After an error is triggered from too many incorrect fingerprint attempts, attempting to launch the BiometricsPrompt again results in different behaviors before and after api 28.
Before api 28:
The prompt is shown with the error message "Too many attempts try again later", the dialog then closes itself and then the onAuthenticationError() callback is called.
After api 28:
No prompt is shown, after a short delay with no indication to the user that anything is happening, the onAuthenticationError() callback is called.
This inconsistency is an issue because we don't know if we should show the error to the user ourselves. If we do, then the user will see the error presented twice < api 28, and if we don't there will be no indication on why it didn't work on api 28+.
Sample project that reproduces the issue: