Fixed
Status Update
No update yet.
Comments
er...@google.com
Seems like it happens on API 21-22 too.
er...@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
ch...@google.com
ch...@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.
ch...@google.com
vi...@gmail.com
And shouldn't the behaviour be consistent across all Android versions?
ch...@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.
vi...@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.
ch...@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
vi...@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.
vi...@gmail.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.
vi...@gmail.com
Can you send us an updated sample ?
ch...@google.com
Looks like you have updated the sample, let me take another look.
vi...@gmail.com
Yes, I've updated the sample on github. Thanks for taking another look.
ch...@google.com
I looked at your code. Looks like the constraints are being unmet after the work starts in some cases.
So essentially, your worker starts, and mid-way the constraints are unmet. At this point because your Worker may not recover gracefully, we cancel and reschedule work. This happens for all your workers actually (if you turn on verbose logging you can see that).
This too is expected.
So essentially, your worker starts, and mid-way the constraints are unmet. At this point because your Worker may not recover gracefully, we cancel and reschedule work. This happens for all your workers actually (if you turn on verbose logging you can see that).
This too is expected.
ap...@google.com
We have exactly the same issue in a major app - so that even SDK versions < 23 make up a six figure number of installs. We use WorkManager to synchronize data from an api - this should only happen every couple of minutes and due to this issue, it leads to multiple api calls per seconds on those older Android versions, generating an "expensive" load on our cloud-based infrastructure.
ch...@google.com
Re: #13/14: We're looking at it some more.
#15: File a separate bug, with sample code or a sample app. The issue is vague enough that there could be something completely different happening.
#15: File a separate bug, with sample code or a sample app. The issue is vague enough that there could be something completely different happening.
Description
1.0.0-alpha07
DEVICE NAME: (Nexus 5X, Samsung S6, etc)
name : FUJITSU arrowsM04
Android OS version : 7.1.1
name: FUJITSU F-04J
Android OS version : 6.0.1
name: FUJITSU F-05J
Android OS version : 7.1.1
DESCRIPTION:
We receive following crash report from our app user.
Fatal Exception: java.lang.IllegalArgumentException: Can not get supported output size under supported maximum for the format: 34
at a.c.a.b.k0.a + 98(SupportedSurfaceCombination.java:98)
at a.c.a.b.k0.a + 30(SupportedSurfaceCombination.java:30)
at a.c.a.b.t.a + 22(Camera2DeviceSurfaceManager.java:22)
at androidx.camera.core.k1.a + 98(CameraX.java:98)
at androidx.camera.core.k1.a + 22(CameraX.java:22)
at a.c.b.c.a + 6(ProcessCameraProvider.java:6)
at <out app package name>.CameraFragment.a + 33(CameraFragment.kt:33)
at <out app package name>.CameraFragment.a + 1(CameraFragment.kt:1)
at <out app package name>.CameraFragment$m.run + 1(CameraFragment.kt:1)
at android.os.Handler.handleCallback + 751(Handler.java:751)
at android.os.Handler.dispatchMessage + 95(Handler.java:95)
at android.os.Looper.loop + 154(Looper.java:154)
at android.app.ActivityThread.main + 6262(ActivityThread.java:6262)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run + 890(ZygoteInit.java:890)
at com.android.internal.os.ZygoteInit.main + 780(ZygoteInit.java:780)
REPRODUCIBILITY: (5 of out 5, 1 out of 100, etc)
We receive this crash report from only three devices. And these devices's manufacturer is FUJITSU.
ADDITIONAL INFORMATION:
CODE FRAGMENTS (this will help us troubleshoot your issues):
Our app bind usecases by following code.
private fun bindCameraUseCases(processCameraProvider: ProcessCameraProvider) {
preview = Preview.Builder().apply {
setTargetAspectRatio(AspectRatio.RATIO_4_3)
}.build().apply {
previewSurfaceProvider = binding.previewViewCamera.previewSurfaceProvider
}
imageCapture = ImageCapture.Builder().apply {
setCaptureMode(ImageCapture.CaptureMode.MINIMIZE_LATENCY)
setTargetAspectRatio(AspectRatio.RATIO_4_3)
setFlashMode(FlashMode.OFF)
}.build()
val cameraSelector = CameraSelector.Builder().requireLensFacing(LensFacing.BACK).build()
processCameraProvider.bindToLifecycle(viewLifecycleOwner, cameraSelector, preview, imageCapture)
}