Fixed
Status Update
Comments
mo...@google.com <mo...@google.com>
mo...@google.com <mo...@google.com> #2
After creating the issue I've noticed that I mixed up a few terms, sorry about that. JobService should be JobScheduler. When referring to jobs in the description, those are classes extending Worker.
va...@google.com <va...@google.com> #3
We have a large set of users seeing this same issue... I can confirm that it seems to only effect users using Android OS 4.4 - 5.1. We are also using WorkManager 2.0.0
va...@google.com <va...@google.com> #4
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 098c163581a360c32baa6e4c215227f0efd10889
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Mon Mar 25 14:05:34 2019
Reset WorkConstraintsTracker when cleaning up in DelayMetCommandHandler.
* DelayMetCommandHandler would previously not cleanup correctly and WorkConstraintsTracker
would trigger callbacks without going through the SystemAlarmDispatcher lifecycle
of processing a command.
Fixes: b/129226383
Test: Added a unit test.
Change-Id: Id2aaf0cce7c4a1a4526a25a211f3fe0551dbe557
M work/workmanager/src/androidTest/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcherTest.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/DelayMetCommandHandler.java
https://android-review.googlesource.com/933140
https://goto.google.com/android-sha1/098c163581a360c32baa6e4c215227f0efd10889
Branch: androidx-master-dev
commit 098c163581a360c32baa6e4c215227f0efd10889
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Mon Mar 25 14:05:34 2019
Reset WorkConstraintsTracker when cleaning up in DelayMetCommandHandler.
* DelayMetCommandHandler would previously not cleanup correctly and WorkConstraintsTracker
would trigger callbacks without going through the SystemAlarmDispatcher lifecycle
of processing a command.
Fixes:
Test: Added a unit test.
Change-Id: Id2aaf0cce7c4a1a4526a25a211f3fe0551dbe557
M work/workmanager/src/androidTest/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcherTest.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/DelayMetCommandHandler.java
jb...@google.com <jb...@google.com> #5
Great to see such a quick fix. Do you have any estimate when a new version that includes this change will be released?
jb...@google.com <jb...@google.com> #6
It should be available in the next 2.x.x version.
ap...@google.com <ap...@google.com> #7
ETA?
jb...@google.com <jb...@google.com> #8
Hi, we have implemented a new big feature using WorkManager and got the same issue. We have been considering third party alternatives because we need to deliver this ASAP. But if you confirm that we will have that version within next few days we can wait for it.
mo...@google.com <mo...@google.com>
mo...@google.com <mo...@google.com> #9
Thanks for reporting this, OP, and thanks for the quick fix, Android team... my users were seeing this too...
mo...@google.com <mo...@google.com> #10
We are using workmanager 2.1.0-alpha01 which include code change of https://android-review.googlesource.com/933140 , but a lot crashes caused by same problems still showing in firebase console.
Affected Android Version
62% Android 5
37% Android 4
1% Android 6
Fatal Exception: java.lang.RuntimeException: Error receiving broadcast Intent { act=android.net.conn.CONNECTIVITY_CHANGE flg=0x4000010 (has extras) } in androidx.work.impl.constraints.trackers.NetworkStateTracker$NetworkStateBroadcastReceiver@42203f30
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:769)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5433)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1268)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1084)
at dalvik.system.NativeStart.main(NativeStart.java)
Caused by java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@421dec00 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@4222d1a8[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2011)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:793)
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:298)
at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:503)
at java.util.concurrent.Executors$DelegatedScheduledExecutorService.schedule(Executors.java:644)
at androidx.work.impl.background.systemalarm.WorkTimer.startTimer(WorkTimer.java:82)
at androidx.work.impl.background.systemalarm.DelayMetCommandHandler.onAllConstraintsMet(DelayMetCommandHandler.java:100)
at androidx.work.impl.constraints.WorkConstraintsTracker.onConstraintMet(WorkConstraintsTracker.java:150)
at androidx.work.impl.constraints.controllers.ConstraintController.updateCallback(ConstraintController.java:134)
at androidx.work.impl.constraints.controllers.ConstraintController.onConstraintChanged(ConstraintController.java:141)
at androidx.work.impl.constraints.trackers.ConstraintTracker.setState(ConstraintTracker.java:103)
at androidx.work.impl.constraints.trackers.NetworkStateTracker$NetworkStateBroadcastReceiver.onReceive(NetworkStateTracker.java:170)
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:759)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5433)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1268)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1084)
at dalvik.system.NativeStart.main(NativeStart.java)
Affected Android Version
62% Android 5
37% Android 4
1% Android 6
Fatal Exception: java.lang.RuntimeException: Error receiving broadcast Intent { act=android.net.conn.CONNECTIVITY_CHANGE flg=0x4000010 (has extras) } in androidx.work.impl.constraints.trackers.NetworkStateTracker$NetworkStateBroadcastReceiver@42203f30
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:769)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5433)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1268)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1084)
at dalvik.system.NativeStart.main(NativeStart.java)
Caused by java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@421dec00 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@4222d1a8[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2011)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:793)
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:298)
at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:503)
at java.util.concurrent.Executors$DelegatedScheduledExecutorService.schedule(Executors.java:644)
at androidx.work.impl.background.systemalarm.WorkTimer.startTimer(WorkTimer.java:82)
at androidx.work.impl.background.systemalarm.DelayMetCommandHandler.onAllConstraintsMet(DelayMetCommandHandler.java:100)
at androidx.work.impl.constraints.WorkConstraintsTracker.onConstraintMet(WorkConstraintsTracker.java:150)
at androidx.work.impl.constraints.controllers.ConstraintController.updateCallback(ConstraintController.java:134)
at androidx.work.impl.constraints.controllers.ConstraintController.onConstraintChanged(ConstraintController.java:141)
at androidx.work.impl.constraints.trackers.ConstraintTracker.setState(ConstraintTracker.java:103)
at androidx.work.impl.constraints.trackers.NetworkStateTracker$NetworkStateBroadcastReceiver.onReceive(NetworkStateTracker.java:170)
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:759)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5433)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1268)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1084)
at dalvik.system.NativeStart.main(NativeStart.java)
ap...@google.com <ap...@google.com> #11
Are you sure that these crash reports are coming from the latest version of your app which has the new version of WorkManager ?
pr...@google.com <pr...@google.com> #12
According to release notes this crash have been fixed in 2.0.1, but we recently update work manager from 1.0.0 to 2.0.1 and now it is our top crash.
Description
Component used: Transition Version used: 1.5.0-alpha02 Devices/Android versions reproduced on: API 34
If you do a gesture back in Fragments using transitions and cancel the gesture multiple times, after the first cancel, starting the gesture will result in the transition on the exiting view failing to run.
I believe the cause of this is that the this
beginDelayedTransition()
called by with a 0 duration called by Fragment never triggersonAnimatedEnd()
callback inVisibility
. That results in the visibility failing to be added removed from the overlay and so the subsequent transitions on the view do not run.Here are logs synced with the calls from Fragment and Visibility. I would expect there to be an
onAnimationEnd reversed=false
log before theonTransitionEnd
in Visibility.The can be reproduced by patching in aosp/2748867 and doing the following in the navigation-integration app :