Fixed
Status Update
No update yet.
Comments
al...@gmail.com
Seems like it happens on API 21-22 too.
am...@google.com
am...@google.com
This is expected. You are calling: enqueueUniquePeriodicWork() with an ExistingPeriodicWorkPolicy.REPLACE. This will cancel running work, and kick off new instances of all Workers.
https://github.com/rubensousa/WorkManagerKitkatBug/blob/master/app/src/main/java/com/github/rubensousa/workkitkatbug/MainActivity.kt#L24
il...@google.com
il...@google.com
ap...@google.com
I just ran the sample again and now the behaviour is different for some weird reason. I forgot to mention that I only used REPLACE to test this properly. Because it also happens with KEEP.
ap...@google.com
And shouldn't the behaviour be consistent across all Android versions?
jb...@google.com
We don't see any issues with KEEP. If you have a way for us to reproduce any problems, please send us the appropriate instructions.
an...@google.com
Ok, I found something odd. Seems like setRequiredNetworkType(NetworkType.UNMETERED) causes this for some reason. I'm going to update the sample so you can review this again. Please, reopen this since it's not intended behavior.
il...@google.com
This happens on a fresh install with KEEP instead of REPLACE if the constraints have setRequiredNetworkType(NetworkType.UNMETERED). I've updated the sample
jb...@google.com
"And shouldn't the behaviour be consistent across all Android versions?"
The behavior is actually consistent. Once your worker starts running, if we get a call to enqueueUniquePeriodicWork a new work request and with ExistingPeriodicWorkPolicy.REPLACE we will stop existing work.
If your Worker was not running, then there is nothing to cancel. This is just a matter of timing.
The behavior is actually consistent. Once your worker starts running, if we get a call to enqueueUniquePeriodicWork a new work request and with ExistingPeriodicWorkPolicy.REPLACE we will stop existing work.
If your Worker was not running, then there is nothing to cancel. This is just a matter of timing.
ap...@google.com
I'm not arguing against the expected behavior of ExistingPeriodicWorkPolicy.REPLACE, since that's working as intended. But this is happening only when setRequiredNetworkType(NetworkType.UNMETERED) is used while having ExistingPeriodicWorkPolicy.KEEP.
an...@google.com
Can you send us an updated sample ?
jb...@google.com
Looks like you have updated the sample, let me take another look.
an...@google.com
Yes, I've updated the sample on github. Thanks for taking another look.
Description
Version used: 27.0.2
Theme used: Theme.AppCompat.Light.DarkActionBar
Devices/Android versions reproduced on: Nexus 5X 8.1
If I set `setReorderingAllowed(true)` when doing fragment `hide()` and if there is a Visibility changing transition (`Fade` in my case) used as an exit on a fragment it internally sets all the views to `INVISIBLE` after the transition is over in `FragmentTransition.replaceHide`. But if you then press hardware back button, it attemts to build a list of views to fade back in, but that list is always empty because `FragmentTransitionImpl.captureTransitioningViews` always checks if they are `VISIBLE`. And I return back to a fragment with a bunch of INVISIBLE views.
- Relevant code to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).
- Steps to reproduce
Install demo app
click switch app
press back button to return to the first fragment
behold second fragment fade out instead of sliding down while underlying fragment becomes visible, but it's contents are INVISIBLE