Fixed
Status Update
No update yet.
Comments
dr...@gmail.com
Seems like it happens on API 21-22 too.
ki...@google.com
no...@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
si...@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?
si...@google.com
an...@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.
dr...@gmail.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.
si...@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
dr...@gmail.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.
Description
When using
ResourcesCompat.getFontto resolve a .ttf file in res/font, the returnedTypefaceinstance always has a weight of 400 and a style ofNORMAL.On all APIs < 29, style correctly resolves to
ITALIC. On API 28, weight correctly resolves to 300.The font actually looks correct when displayed on an API 29 device, it just has the wrong values according to the
Typefaceinstance.The issue is reproducible in
typefaceBugtest case that uses an ActivityScenario to demonstrate that the text actually appears correctly on API 29.