Workers executed when constraint is met crashing on Android 4.4-5.1 (WorkManager scheduling instead of JobService) [129226383]

Fixed

Bug

Status Update

No update yet.

Description

jo...@gmail.com

created issue #1

Mar 25, 2019 09:29AM

Component used: androidx.work:work-runtime
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)

Comments

jo...@gmail.com <jo...@gmail.com> #2Mar 25, 2019 09:48AM

To use Lifecycle 2.8.0-alpha03, ensure you are using at least Compose UI 1.7.0-alpha05.

The issue is happening because, starting from Lifecycle 2.8.0-alpha03 and Compose UI 1.7.0-alpha05, LocalLifecycleOwner has been moved from androidx.compose.ui to lifecycle-runtime-compose, as outlined in their respective release notes. For compatibility reasons, you must update both dependencies.

For context, note these changes were made to enable the utilization of its Compose-based helper APIs beyond Compose UI (such as in Molecule). Further information can be found at b/328263448.

If the issue persists even after updating your Compose UI, please let us know.

Edit: please see https://issuetracker.google.com/336842920#comment8 for a workaround.

je...@gmail.com <je...@gmail.com> #3Mar 25, 2019 03:26PM

Thanks for your answer.
If this change has made both libraries version dependent, it seems that guide them to the release note so that users will not experience difficulties :)

ra...@google.com <ra...@google.com> Mar 25, 2019 09:05PM

Assigned to ra...@google.com.

ap...@google.com <ap...@google.com> #4Mar 26, 2019 12:05AM

Marked as fixed.

lifecycle 2.8.0 is now stable but compose UI 1.7.0 is still in beta.

jo...@gmail.com <jo...@gmail.com> #5Mar 26, 2019 05:53AM

Same problem here. Lifecycle 2.8.0 is now stable but Compose UI 1.7.0 is still beta. Of course our Dependabot didn't know about this relationship between dependencies 😬

ra...@google.com <ra...@google.com> #6Mar 26, 2019 05:25PM

Something like that really shouldn't happen... 🤦🏻‍♂️

di...@gmail.com <di...@gmail.com> #7Apr 1, 2019 07:20PM

Thats really really bad. I would always expect the latest stable versions to be compatible. Please add this requirement to the changelog or better add a warning at compile time if used with incompatible combinations.

[Deleted User] <[Deleted User]> #8Apr 1, 2019 07:32PM

We acknowledge that the behavior dependency between Lifecycle 2.8 Stable and Compose 1.7 Beta is not ideal. This should not have occurred, and we are working in a fix and looking into how we can prevent it in the future. We have updated our release notes to clarify this issue.

In the meantime, while Compose 1.7 Stable has not been released, we have outlined some potential workarounds below. Please note that these solutions are not perfect but they could be helpful to some of you while the fix is not ready:

Use Compose 1.7 Beta if that is an option for you.
Map androidx.compose.ui.platform.LocalLifecycleOwner (Compose 1.6) to androidx.lifecycle.compose.LocalLifecycleOwner (Lifecycle 2.8). Here's an example:
```
CompositionLocalProvider(
    androidx.lifecycle.compose.LocalLifecycleOwner provides androidx.compose.ui.platform.LocalLifecycleOwner.current,
) {
  // ...
}
```
- Please note that when using Navigation Compose, this may be required on each navigation page (for more details, refer to comment #11).

Manually pass androidx.compose.ui.platform.LocalLifecycleOwner (Compose 1.6) to Lifecycle 2.8 methods. For instance:

val state by stateFlow.collectAsStateWithLifecycle(
  owner = androidx.compose.ui.platform.LocalLifecycleOwner.current
)

Thank you.

dr...@gmail.com <dr...@gmail.com> #9Apr 6, 2019 09:13AM

Thanks for the workaround!

li...@gmail.com <li...@gmail.com> #10May 17, 2019 02:14AM

the option 2) will not work with compose navigation component, right ? As the lib also provides a LocalLifecycleOwner and 3) will not work for any library that uses LocalLifecycleOwner internally.

ra...@google.com <ra...@google.com> #11May 17, 2019 06:03PM

comment#10:

the option 2) will not work with compose navigation component, right ? As the lib also provides a LocalLifecycleOwner

Yes, you would need to also include it on each navigation page (composable() route).

will not work for any library that uses LocalLifecycleOwner internally.

Yes.

ar...@gmail.com <ar...@gmail.com> #12Jun 10, 2019 01:18PM

For the record, the new dropUnlessResumed and dropUnlessStarted APIs won't work with Navigation 2.7 out of the box. Similar to the fix above, the new LocalLifecycleOwner needs to be explicitly assigned to the NavBackStackEntry in every composable() route.

composable(...) { navBackStackEntry ->
  CompositionLocalProvider(
    androidx.lifecycle.compose.LocalLifecycleOwner provides navBackStackEntry
  ) {
    MyScreen(
      onBackClick = dropUnlessResumed { navController.popBackStack() }
    )
  }
}

ra...@google.com <ra...@google.com> #13Jun 10, 2019 04:05PM

Project: platform/frameworks/support
Branch: androidx-main

commit 5d638420d6b6f3df21e4c1cb7c9e48566c1dcafe
Author: Marcello Galhardo <mgalhardo@google.com>
Date: Tue May 21 19:23:41 2024

Add version constraint to Compose UI 1.7.0-beta01 in Lifecycle

RelNote: "`lifecycle-runtime-compose` now has a version constraints with Compose UI 1.7.0-beta01"
Fixes:

b/336842920

Test: Manual
Change-Id: I25dfd4100a4d3bd2f0f32f21711b95e987e2ff2a

M lifecycle/lifecycle-runtime-compose/build.gradle

https://android-review.googlesource.com/3094405

[Deleted User] <[Deleted User]> #14Feb 25, 2020 12:36PM

Workaround works! Thanks
val orderLines by viewModel.orderLines.collectAsStateWithLifecycle(
lifecycleOwner = androidx.compose.ui.platform.LocalLifecycleOwner.current
)

Message last modified on Feb 25, 2020 12:39PM

mi...@charter.com <mi...@charter.com> #15Apr 1, 2020 11:28PM

deleted

Message last modified on Apr 2, 2020 03:11PM

il...@google.com <il...@google.com> #16Apr 1, 2020 11:37PM

Comment #14 seems to work when collecting a stateflow from a viewmodel :)

mi...@charter.com <mi...@charter.com> #17Apr 2, 2020 03:18PM

The release notes of Lifecycle stated that "lifecycle-*:2.8.0 requires a minimum Compose version of 1.7.0-alpha05". However when I run ./gradlew app:dependencies --configuration releaseRuntimeClasspath I couldn't find any Compose library resolved to alpha versions, the highest version was 1.6.5.

Is the statement correct? Or do I misinterpret it?