Fixed
Status Update
No update yet.
Comments
jo...@gmail.com
Can you show me the code you are using to build/enqueue your work? This is definitely surprising - I wonder if you have an incredibly deep hierarchy, or if there's some kind of circular dependency (which we should be catching).
je...@gmail.com
Unfortunately, the stack trace isn't telling us *which* work is causing the problem. My best guess is that it's this one, as it's the newly introduced worker on the build that is crashing, and other builds that don't include it aren't reporting the same crash:
fun enqueueWork(objects: List<MyType>) {
val inputData = Data.Builder().putString(MY_EXTRA, objects.serializeToJson())
val request = OneTimeWorkRequest.Builder(WORKER_CLASS)
.setConstraints(Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build())
.setInputData(inputData.build())
.addTag(WORK_TAG)
.build()
val workManager = WorkManager.getInstance()
workManager.beginUniqueWork(WORK_ID, ExistingWorkPolicy.APPEND, request).enqueue()
}
The enqueueWork method is being called at the end of an RxJava chain that's using a buffer that's flushed every 5 minutes, or when an action is called.
fun enqueueWork(objects: List<MyType>) {
val inputData = Data.Builder().putString(MY_EXTRA, objects.serializeToJson())
val request = OneTimeWorkRequest.Builder(WORKER_CLASS)
.setConstraints(Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build())
.setInputData(inputData.build())
.addTag(WORK_TAG)
.build()
val workManager = WorkManager.getInstance()
workManager.beginUniqueWork(WORK_ID, ExistingWorkPolicy.APPEND, request).enqueue()
}
The enqueueWork method is being called at the end of an RxJava chain that's using a buffer that's flushed every 5 minutes, or when an action is called.
ra...@google.com
ap...@google.com
How often are those actions being called? Any idea how big this chain is?
jo...@gmail.com
The manual flushing is called when the user takes a particular UX action or closes a fragment that has attached to the object generator. In typical usage, this might happen a couple times in the first few minutes, but then would be unlikely to be called again.
Here is the chain:
val timer = Observable.interval(5, TimeUnit.MINUTES, scheduler)
eventSubject
.buffer( // Flush buffer on timer, or when signal is called
Observable.merge(
timer.map { Unit }, // We don't care what types are emitted, we just care that a value came out
flushObservable.map { Unit }
).map { // Debug log }
)
.filter {
it.isNotEmpty()
}
.observeOn(scheduler)
.subscribe(
{ events ->
enqueueWork(events)
},
{ // Log error })
Here is the chain:
val timer = Observable.interval(5, TimeUnit.MINUTES, scheduler)
eventSubject
.buffer( // Flush buffer on timer, or when signal is called
Observable.merge(
timer.map { Unit }, // We don't care what types are emitted, we just care that a value came out
flushObservable.map { Unit }
).map { // Debug log }
)
.filter {
it.isNotEmpty()
}
.observeOn(scheduler)
.subscribe(
{ events ->
enqueueWork(events)
},
{ // Log error })
ra...@google.com
Gg
[Deleted User] <[Deleted User]>
Thanks for addressing that so quickly. Do you know approximately how long it will take for it to make it into a release? And is it at all possible that this will be incorporated into the non-Android-x version of WorkManager? It's a little frustrating that two days after 1.0.0 was released, it was announced that there would be no more development on the non-Android-x version.
dr...@gmail.com
This will probably be available next week, and so far the plan is to port it to the 1.x branch as well.
That being said, please be aware that all active Jetpack and Support Library development is happening in the AndroidX branches, so I would highly recommend switching your app when you get a chance. Thanks!
That being said, please be aware that all active Jetpack and Support Library development is happening in the AndroidX branches, so I would highly recommend switching your app when you get a chance. Thanks!
li...@gmail.com
Thanks for the info. We're definitely planning on moving to AndroidX, but until we do, I appreciate that you're porting fixes to the old version.
ra...@google.com
Are you sure that these crash reports are coming from the latest version of your app which has the new version of WorkManager ?
ar...@gmail.com
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.
ra...@google.com
This would still happen in some rare conditions. So we have another fix for it in 2.1.0-alpha03.
[Deleted User] <[Deleted User]>
I'm also getting same crash in Google Play console only for android-sdk 4.4 to 5.2
used work manager version = '2.3.0'
implementation "androidx.work:work-runtime:2.3.0"
This is Top most crash in my App Account.
used work manager version = '2.3.0'
implementation "androidx.work:work-runtime:2.3.0"
This is Top most crash in my App Account.
mi...@charter.com
We have noticed a huge surge in this issue after migrating to Android Studio 3.6 in our latest release (updated classpath in root build.gradle to "com.android.tools.build:gradle:3.6.x" -- we were previously on 3.4.2).
Doing so, forced our work manager to version up to 2.0.0, even though we are still declaring 1.x in our dependencies (Gradle automatically chooses the latest version to resolve dependency version conflicts).
This introduced the same crash and logs mentioned in earlier comments on this issue tracker ticket.
This crash bug was likely not fixed until 2.2.0-rc1:
https://developer.android.com/jetpack/androidx/releases/work#2.2.0-rc01
So our attempted solution was to adopt the latest stable version of work manager (2.3.4 according to the documentation). However, with this new gradle build tools version, the dependency appears to be locked to 2.0.0 no matter what we try. Using "strictly" or "force" as described in the gradle documentation seems to have to no effect. And using exclude does not make much sense.
https://docs.gradle.org/current/userguide/dependency_downgrade_and_exclude.html
When using Gradle's dependency insight, we can see that for some reason after the migration, the dependency now has a new selection reason.
"Selected by rule : ENABLE_JETIFIER is enabled".
So at this point, it seems our options appear to be:
- Waiting for fix from Google or Gradle,
- Disabling jetifier and refactoring everything in order to avoid using AndroidX components.
- Revert our migration to Android Studio 3.6
- Remove work manager dependency altogether for the OS versions / device models affected
Hopefully this information helps, and hopefully it gets resolved soon!
Doing so, forced our work manager to version up to 2.0.0, even though we are still declaring 1.x in our dependencies (Gradle automatically chooses the latest version to resolve dependency version conflicts).
This introduced the same crash and logs mentioned in earlier comments on this issue tracker ticket.
This crash bug was likely not fixed until 2.2.0-rc1:
So our attempted solution was to adopt the latest stable version of work manager (2.3.4 according to the documentation). However, with this new gradle build tools version, the dependency appears to be locked to 2.0.0 no matter what we try. Using "strictly" or "force" as described in the gradle documentation seems to have to no effect. And using exclude does not make much sense.
When using Gradle's dependency insight, we can see that for some reason after the migration, the dependency now has a new selection reason.
"Selected by rule : ENABLE_JETIFIER is enabled".
So at this point, it seems our options appear to be:
- Waiting for fix from Google or Gradle,
- Disabling jetifier and refactoring everything in order to avoid using AndroidX components.
- Revert our migration to Android Studio 3.6
- Remove work manager dependency altogether for the OS versions / device models affected
Hopefully this information helps, and hopefully it gets resolved soon!
il...@google.com
Re #15 - make sure you're using androidx.work and not the android.arch.work group ID in your dependency (using android.arch.work will cause the behavior you're seeing) as per the
mi...@charter.com
My goodness, thank you so much for responding so quickly! I must have looked over those code snippets a dozen times and did not realize this change.
Yes, it works when migrating to the androidX group id. Perhaps the AndroidX migration guide needs to add this dependency as well:
https://developer.android.com/jetpack/androidx/migrate/artifact-mappings
Yes, it works when migrating to the androidX group id. Perhaps the AndroidX migration guide needs to add this dependency as well:
Description
Version used: 2.0.0
Devices/Android versions reproduced on: reported on Android 5.0/5.1 (Play Console) / Android 4.4.2/4.4.4/5.0-5.1.1 (Firebase Crashlytics). Multiple devices from various manufacturers, including Samsung, Lenovo, LG, Motorola, HTC, Sony and Asus.
After updating our app from android.arch.work:work-runtime:1.0.0-rc02 to androidx.work:work-runtime:2.0.0, we're seeing crashes when WorkManager starts a job for a significant amount of our users, which doesn't make much sense because the code should be similar to the previous version but it is still a problem.
Unfortunately, we haven't been able to replicate the issue on our 4.4.2 test device. Because the issue is limited to Android versions where JobService isn't used (and the stack trace, see below), it seems like the issue is caused by WorkManager's scheduling and not the job itself.
The worker is set up by a periodic request:
Constraints workerConstraints = new Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build();
PeriodicWorkRequest userUpdateWorker = new PeriodicWorkRequest.Builder(UserUpdateWorker.class, 8, TimeUnit.HOURS)
.addTag(UserUpdateWorker.class.getName())
.setConstraints(workerConstraints)
.build();
WorkManager.getInstance().enqueue(userUpdateWorker);
Stack trace from the Crashlytics/Play Console crash reports:
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@42849958
at android.app.LoadedApk$ReceiverDispatcher$Args.run (LoadedApk.java:941)
at android.os.Handler.handleCallback (Handler.java:739)
at android.os.Handler.dispatchMessage (Handler.java:95)
at android.os.Looper.loop (Looper.java:145)
at android.app.ActivityThread.main (ActivityThread.java:6117)
at java.lang.reflect.Method.invoke (Method.java)
at java.lang.reflect.Method.invoke (Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:1399)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1194)
Caused by java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@2ac263d0 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@320e0fc9[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:931)
at android.os.Handler.handleCallback (Handler.java:739)
at android.os.Handler.dispatchMessage (Handler.java:95)
at android.os.Looper.loop (Looper.java:145)
at android.app.ActivityThread.main (ActivityThread.java:6117)
at java.lang.reflect.Method.invoke (Method.java)
at java.lang.reflect.Method.invoke (Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:1399)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1194)