Fixed
Status Update
Comments
ra...@google.com <ra...@google.com>
ra...@google.com <ra...@google.com> #2
Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:
Please provide sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.
Expected output
What do you expect to occur?
Current output
What do you see instead?
Android bug report
After reproducing the issue, press the volume up, volume down, and power button simultaneously. This will capture a bug report on your device in the “bug reports” directory. Attach the bug report file to this issue.
Alternate method:
After reproducing the issue, navigate to developer settings, ensure ‘USB debugging’ is enabled, then enable ‘Bug report shortcut’. To take bug report, hold the power button and select the ‘Take bug report’ option.
NOTE: Please upload the files to Google Drive and share the folder to android-bugreport@google.com, then share the link here.
Please provide sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.
Expected output
What do you expect to occur?
Current output
What do you see instead?
Android bug report
After reproducing the issue, press the volume up, volume down, and power button simultaneously. This will capture a bug report on your device in the “bug reports” directory. Attach the bug report file to this issue.
Alternate method:
After reproducing the issue, navigate to developer settings, ensure ‘USB debugging’ is enabled, then enable ‘Bug report shortcut’. To take bug report, hold the power button and select the ‘Take bug report’ option.
NOTE: Please upload the files to Google Drive and share the folder to android-bugreport@google.com, then share the link here.
lb...@gmail.com <lb...@gmail.com> #3
ok, I did some more research, turns out that callback notification goes to the if we press "cancel" button but goes wrong when authentication succeeds
as you can see in the attached project
if you open the bio-prompt in the 1st Fragment and authenticate
and after that you go to the 2nd Fragment and authenticate in the bio-prompt
callback notifies the Fragment1 instead of the Fragment2 as you can see in the logs
expected result is that Fragment2 is notified instead of Fragment1
also if you first go to Fragment2 and after that you go to Fragment1 always opening the prompt and doing the authentication
Fragment2 is notified instead of Fragment1
funny thing is that doing cancel instead of authentication notification works ok
https://drive.google.com/open?id=1ZVhp9sFBJ6pa1bKzHg1AM5tF5XnmyFMM
as you can see in the attached project
if you open the bio-prompt in the 1st Fragment and authenticate
and after that you go to the 2nd Fragment and authenticate in the bio-prompt
callback notifies the Fragment1 instead of the Fragment2 as you can see in the logs
expected result is that Fragment2 is notified instead of Fragment1
also if you first go to Fragment2 and after that you go to Fragment1 always opening the prompt and doing the authentication
Fragment2 is notified instead of Fragment1
funny thing is that doing cancel instead of authentication notification works ok
su...@google.com <su...@google.com> #4
manually closing the FingerprintHelperFragment works as a workaround
```
override fun onPause() {
// WORKAROUND forhttps://issuetracker.google.com/issues/123857949
activity?.let { activity ->
activity.supportFragmentManager.findFragmentByTag("FingerprintHelperFragment")?.let {
activity.supportFragmentManager.beginTransaction().remove(it).commitAllowingStateLoss()
}
super.onPause()
}
}
```
```
override fun onPause() {
// WORKAROUND for
activity?.let { activity ->
activity.supportFragmentManager.findFragmentByTag("FingerprintHelperFragment")?.let {
activity.supportFragmentManager.beginTransaction().remove(it).commitAllowingStateLoss()
}
super.onPause()
}
}
```
Description
Version used:
implementation "android.arch.work:work-runtime-ktx:1.0.0-alpha04"
implementation "android.arch.work:work-firebase:1.0.0-alpha04"
But also the Java one
Devices/Android versions reproduced on:
Nexus 4 with Android 4.4.4
If this is a bug in the library, we would appreciate if you could attach:
- Sample project to trigger the issue.
Attached
- A screenrecord or screenshots showing the issue (if UI related).
Attached.
The bug is that on newer Android versions, the schedule works fine, yet here on this Android version, the work never gets called.
In the sample, I've scheduled it to run in 30 seconds:
workManager.enqueue(OneTimeWorkRequest.Builder(SampleJob::class.java).addTag(schedultedTag).setInitialDelay(30, TimeUnit.SECONDS).build())
Steps for reproducing the bug:
1. Just press on "schedule job in 30 sec" button.
2. You can wait 30 seconds or even a lot more time, and it won't be launched. I've set that a toast and log will b shown. Nothing occurs.
If I remove the delay, it works fine :
workManager.enqueue(OneTimeWorkRequest.Builder(SampleJob::class.java).addTag(normalJobTag).build())
Same goes if I remove the Firebase usage:
implementation "android.arch.work:work-firebase:1.0.0-alpha04"