Fixed
Status Update
Comments
vi...@google.com <vi...@google.com>
vi...@google.com <vi...@google.com> #2
This is definitely on our radar and there are plans to support it coming soon. We'll keep you updated on this bug.
ma...@gmail.com <ma...@gmail.com> #3
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 65e1ddf3b22249241c496890510071648bdff904
Author: Sumir Kataria <sumir@google.com>
Date: Mon Apr 01 16:33:01 2019
On-demand initialization for WorkManager.
This CL introduces WorkManager#getInstance(Context) as the preferred
method and deprecates the argument-less version. This method performs
on-demand initialization of WorkManager if it hasn't been initialized
previously by looking to see if the application Context implements
Configuration.Provider and querying it for the Configuration.
The exact order of initialization checks are now as follows:
1. Through WorkManagerInitializer if it's enabled.
2. Otherwise, through a WorkManager#initialize in Application#onCreate
or ContentProvider#onCreate if specified by the developer.
3. Otherwise, through WorkManager#getInstance(Context) if the
application Context implements Configuration.Provider. Using
WorkManager#getInstance() at this point results in an exception as
it does not contain the necessary information to initialize.
4. Otherwise, throws an IllegalStateException.
This change allows WorkManager to be setup in a manner where you can
only allow it to be initialized when it is needed. This is good for
apps that care about the critical path initialization needed by
WorkManager; in addition, all of WorkManager's own BroadcastReceivers
and Services are set up to try to auto-initialize if needed. Note
that this initialization can still happen on the main thread.
Bug: 127497100
Test: Ran integration tests with integration app doing on-demand init.
Change-Id: I30930d6445c0e9c5f08eaaab554963aaac99b3c9
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/MainActivity.java
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/RecursiveWorker.java
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/RetryActivity.java
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/TestApplication.java
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/imageprocessing/ImageProcessingActivity.java
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/sherlockholmes/AnalyzeSherlockHolmesActivity.java
M work/workmanager-gcm/src/main/java/androidx/work/impl/background/gcm/WorkManagerGcmService.java
M work/workmanager-testing/api/2.1.0-alpha01.txt
M work/workmanager-testing/api/current.txt
M work/workmanager-testing/src/androidTest/java/androidx/work/testing/TestSchedulerTest.java
M work/workmanager-testing/src/androidTest/java/androidx/work/testing/WorkManagerInitHelperTest.java
M work/workmanager-testing/src/main/java/androidx/work/testing/TestScheduler.java
M work/workmanager-testing/src/main/java/androidx/work/testing/TestWorkManagerImpl.java
M work/workmanager-testing/src/main/java/androidx/work/testing/WorkManagerTestInitHelper.java
M work/workmanager-testing/src/main/java/androidx/work/testing/package-info.java
M work/workmanager-testing/src/test/java/androidx/work/testing/RobolectricSmokeTest.java
M work/workmanager/api/2.1.0-alpha01.txt
M work/workmanager/api/current.txt
M work/workmanager/src/androidTest/java/androidx/work/impl/background/systemjob/SystemJobServiceTest.java
M work/workmanager/src/main/java/androidx/work/Configuration.java
M work/workmanager/src/main/java/androidx/work/WorkManager.java
M work/workmanager/src/main/java/androidx/work/impl/WorkManagerImpl.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/RescheduleReceiver.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcher.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemjob/SystemJobService.java
M work/workmanager/src/main/java/androidx/work/impl/workers/ConstraintTrackingWorker.java
https://android-review.googlesource.com/937085
https://goto.google.com/android-sha1/65e1ddf3b22249241c496890510071648bdff904
Branch: androidx-master-dev
commit 65e1ddf3b22249241c496890510071648bdff904
Author: Sumir Kataria <sumir@google.com>
Date: Mon Apr 01 16:33:01 2019
On-demand initialization for WorkManager.
This CL introduces WorkManager#getInstance(Context) as the preferred
method and deprecates the argument-less version. This method performs
on-demand initialization of WorkManager if it hasn't been initialized
previously by looking to see if the application Context implements
Configuration.Provider and querying it for the Configuration.
The exact order of initialization checks are now as follows:
1. Through WorkManagerInitializer if it's enabled.
2. Otherwise, through a WorkManager#initialize in Application#onCreate
or ContentProvider#onCreate if specified by the developer.
3. Otherwise, through WorkManager#getInstance(Context) if the
application Context implements Configuration.Provider. Using
WorkManager#getInstance() at this point results in an exception as
it does not contain the necessary information to initialize.
4. Otherwise, throws an IllegalStateException.
This change allows WorkManager to be setup in a manner where you can
only allow it to be initialized when it is needed. This is good for
apps that care about the critical path initialization needed by
WorkManager; in addition, all of WorkManager's own BroadcastReceivers
and Services are set up to try to auto-initialize if needed. Note
that this initialization can still happen on the main thread.
Bug: 127497100
Test: Ran integration tests with integration app doing on-demand init.
Change-Id: I30930d6445c0e9c5f08eaaab554963aaac99b3c9
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/MainActivity.java
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/RecursiveWorker.java
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/RetryActivity.java
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/TestApplication.java
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/imageprocessing/ImageProcessingActivity.java
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/sherlockholmes/AnalyzeSherlockHolmesActivity.java
M work/workmanager-gcm/src/main/java/androidx/work/impl/background/gcm/WorkManagerGcmService.java
M work/workmanager-testing/api/2.1.0-alpha01.txt
M work/workmanager-testing/api/current.txt
M work/workmanager-testing/src/androidTest/java/androidx/work/testing/TestSchedulerTest.java
M work/workmanager-testing/src/androidTest/java/androidx/work/testing/WorkManagerInitHelperTest.java
M work/workmanager-testing/src/main/java/androidx/work/testing/TestScheduler.java
M work/workmanager-testing/src/main/java/androidx/work/testing/TestWorkManagerImpl.java
M work/workmanager-testing/src/main/java/androidx/work/testing/WorkManagerTestInitHelper.java
M work/workmanager-testing/src/main/java/androidx/work/testing/package-info.java
M work/workmanager-testing/src/test/java/androidx/work/testing/RobolectricSmokeTest.java
M work/workmanager/api/2.1.0-alpha01.txt
M work/workmanager/api/current.txt
M work/workmanager/src/androidTest/java/androidx/work/impl/background/systemjob/SystemJobServiceTest.java
M work/workmanager/src/main/java/androidx/work/Configuration.java
M work/workmanager/src/main/java/androidx/work/WorkManager.java
M work/workmanager/src/main/java/androidx/work/impl/WorkManagerImpl.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/RescheduleReceiver.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcher.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemjob/SystemJobService.java
M work/workmanager/src/main/java/androidx/work/impl/workers/ConstraintTrackingWorker.java
ma...@gmail.com <ma...@gmail.com> #4
Thanks for the fix! Is there any information about when this can be released to production?
vi...@google.com <vi...@google.com> #5
As this is a new API, this will first be released in 2.1.0-alpha01 and go through the normal alpha/beta/rc/stable release process. You can expect the first alpha in the next 2 weeks.
kc...@google.com <kc...@google.com> #6
Great! Thanks for the fast response.
cu...@google.com <cu...@google.com>
ap...@google.com <ap...@google.com> #8
Project: platform/frameworks/support
Branch: androidx-master-dev
commit a9cbd7e42fd38c18395c23fd17622c731c60c724
Author: Curtis Belmonte <curtislb@google.com>
Date: Mon Oct 28 11:00:33 2019
Fix leak of biometric credential handler activity
Due to a race condition, which can be triggered by launching
BiometricPrompt immediately after it's dismissed (e.g., by calling
authenticate() in onResume() or onCreate()), it's currently possible for
the transparent DeviceCredentialHandlerActivity to get stuck onscreen.
This results in no visible change but consumes all touch events until
the user presses back or pauses the activity.
This commit fixes the issue of the activity getting stuck onscreen by
ensuring that DeviceCredentialHandlerActivity is finished (without an
explicit authentication result) in this case.
Test: Have sample app call BiometricPrompt#authenticate() in onResume()
Before: After first auth, transparent activity is stuck onscreen
After: After first auth, the prompt launches again successfully
Fixes: 143091227
Change-Id: Id11918662be4634c017094806816a990e84ffd62
M biometric/src/main/java/androidx/biometric/DeviceCredentialHandlerActivity.java
https://android-review.googlesource.com/1151594
https://goto.google.com/android-sha1/a9cbd7e42fd38c18395c23fd17622c731c60c724
Branch: androidx-master-dev
commit a9cbd7e42fd38c18395c23fd17622c731c60c724
Author: Curtis Belmonte <curtislb@google.com>
Date: Mon Oct 28 11:00:33 2019
Fix leak of biometric credential handler activity
Due to a race condition, which can be triggered by launching
BiometricPrompt immediately after it's dismissed (e.g., by calling
authenticate() in onResume() or onCreate()), it's currently possible for
the transparent DeviceCredentialHandlerActivity to get stuck onscreen.
This results in no visible change but consumes all touch events until
the user presses back or pauses the activity.
This commit fixes the issue of the activity getting stuck onscreen by
ensuring that DeviceCredentialHandlerActivity is finished (without an
explicit authentication result) in this case.
Test: Have sample app call BiometricPrompt#authenticate() in onResume()
Before: After first auth, transparent activity is stuck onscreen
After: After first auth, the prompt launches again successfully
Fixes: 143091227
Change-Id: Id11918662be4634c017094806816a990e84ffd62
M biometric/src/main/java/androidx/biometric/DeviceCredentialHandlerActivity.java
Description
Android Studio 3.5.1
compileSdkVersion 29
minSdkVersion 21
targetSdkVersion 29
def biometric_version = "1.0.0-rc01"
implementation "androidx.biometric:biometric:$biometric_version"
Scenario 1:
- No biometric or device credentials (PIN, pattern, password) configured
- Biometric prompt not showing
- Activity is not responding (can't tap on button or textfields)
Scenario 2:
- Device credential configured (Pattern)
- Biometric prompt showing pattern authentication
- Tap on Cancel
- Activity is not responding (can't tap on button or textfields)
I can see in the logs "Authentication canceled by user" for both scenario
When fingerprint is configured ans prompt ask for fingerprint if I cancel the activity is responding
It occurs only for device credentials when setDeviceCredentialAllowed(true)