Status Update
No update yet.
Comments
da...@google.com
We have same issue.
Version used: WorkManager 2.1.0-alpha01
Devices/Android versions reproduced on: mostly Android 5 & 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@c5142c8
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:876)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5254)
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:902)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:697)
Caused by java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@64a6d62 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@16d09ef3[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:866)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5254)
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:902)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:697)
Version used: WorkManager 2.1.0-alpha01
Devices/Android versions reproduced on: mostly Android 5 & 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@c5142c8
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:876)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5254)
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:902)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:697)
Caused by java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@64a6d62 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@16d09ef3[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:866)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5254)
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:902)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:697)
ku...@gmail.com
liujian16@: Are you sure this is happening on Android 6? Because the stack trace points to DelayMetCommandHandler (which is something that the AlarmManager based implementation uses) which is only used on API <= 22.
nihansin@: Sorry its not clear what you meant by
"WorkManager 2.1.0-alpha01
I know 2.1.0-alpha02 is out but I cannot test it as I CANNOT reproduce this issue on both alpha01 and 02."
Did you mean that you cannot reproduce this on your own but you see this happen in production ?
My guess is something like this might be happening:
If you have a Worker in RUNNING state, and you have been asked to stop (either because constraints are no longer met / or if you called cancel()) your Worker still needs to cooperatively cancel.
If your Worker never stops running, then WorkTimer will try and shutdown your Worker again (in 10 minutes). This time that will fail, because the Executor has already been shutdown.
This typically stems from a bug in your code (because your Worker never stopped).
Can you please turn on WorkManager's logging so it will better help us diagnose the problem ?
For this you need to use custom initialization. Something like:
Configuration configuration = new Configuration.Builder()
.setMinimumLoggingLevel(Log.VERBOSE)
.build();
WorkManager.initialize(context, configuration);
Make sure you disable the default initializer.
nihansin@: Sorry its not clear what you meant by
"WorkManager 2.1.0-alpha01
I know 2.1.0-alpha02 is out but I cannot test it as I CANNOT reproduce this issue on both alpha01 and 02."
Did you mean that you cannot reproduce this on your own but you see this happen in production ?
My guess is something like this might be happening:
If you have a Worker in RUNNING state, and you have been asked to stop (either because constraints are no longer met / or if you called cancel()) your Worker still needs to cooperatively cancel.
If your Worker never stops running, then WorkTimer will try and shutdown your Worker again (in 10 minutes). This time that will fail, because the Executor has already been shutdown.
This typically stems from a bug in your code (because your Worker never stopped).
Can you please turn on WorkManager's logging so it will better help us diagnose the problem ?
For this you need to use custom initialization. Something like:
Configuration configuration = new Configuration.Builder()
.setMinimumLoggingLevel(Log.VERBOSE)
.build();
WorkManager.initialize(context, configuration);
Make sure you disable the default initializer.
da...@google.com
da...@google.com
I will investigate this further on my end as well.
an...@gmail.com
Yes, I meant that I cannot reproduce it in my tests.
Here are some points.
- I skip the job if there is an already active job when doWork is called.
- I am never call cancell and I exit with success if job takes longer than
9 minutes. However, I do do batch processing and it may be that one of the
runs in the batch might have taken more than 10 minutes.
On Thu, 23 May 2019, 18:06 , <buganizer-system@google.com> wrote:
Here are some points.
- I skip the job if there is an already active job when doWork is called.
- I am never call cancell and I exit with success if job takes longer than
9 minutes. However, I do do batch processing and it may be that one of the
runs in the batch might have taken more than 10 minutes.
On Thu, 23 May 2019, 18:06 , <buganizer-system@google.com> wrote:
Description
Version used: 2.7.0-alpha03
Devices/Android versions reproduced on:
Android Studio Sync Failing
On using room 2.7.0 alpha versions in a compose multiplatform project generated from official jetbrains wizard
Cannot change attributes of configuration ':composeApp:debugFrameworkIosX64' after it has been locked for mutation
On debugging I found that these lines of code in build.gradle.kts kotlin block meant for compilation on ios are causing this issue:
kotlin{
listOf(
iosX64(),
iosArm64(),
iosSimulatorArm64()
).forEach { iosTarget ->
iosTarget.binaries.framework {
baseName = "ComposeApp"
isStatic = true
}
}
}
On commenting the above lines, android builds successfully and room works fine while ios is unable to build due to the same error.
Here is an extract from my libs.versions.toml file
[versions]
agp = "8.3.0"
android-compileSdk = "34"
android-minSdk = "24"
android-targetSdk = "34"
androidx-activityCompose = "1.9.0"
compose-plugin = "1.6.10"
kotlin = "2.0.0"
room = "2.7.0-alpha03"
ksp = "2.0.0-1.0.21"
sqlite = "2.5.0-SNAPSHOT"
[libraries]
androidx-activity-compose = { module = "androidx.activity:activity-compose", version.ref = "androidx-activityCompose" }
room-runtime = { module = "androidx.room:room-runtime", version.ref = "room" }
room-compiler = { module = "androidx.room:room-compiler", version.ref = "room" }
sqlite-bundled = { module = "androidx.sqlite:sqlite-bundled", version.ref = "sqlite" }
[plugins]
androidApplication = { id = "com.android.application", version.ref = "agp" }
androidLibrary = { id = "com.android.library", version.ref = "agp" }
jetbrainsCompose = { id = "org.jetbrains.compose", version.ref = "compose-plugin" }
compose-compiler = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }
kotlinMultiplatform = { id = "org.jetbrains.kotlin.multiplatform", version.ref = "kotlin" }
ksp = { id = "com.google.devtools.ksp", version.ref = "ksp" }
room = { id = "androidx.room", version.ref = "room" }
Android Studio version details:
Android Studio Jellyfish | 2023.3.1 Patch 1
Build #AI-233.14808.21.2331.11842104, built on May 15, 2024
Runtime version: 17.0.10+0--11572160 amd64
1) I have tried removing and readding all dependencies but only after adding room is this issue reproduced.
2) On downgrading to kotlin 1.9.23 and compose plugin to 1.6.2, the sync issue goes away but the build fails due to an unknown error which is not provided in the logs by android studio so there is some sort of incompatibility still at place here.
3) Alpha03 released today does not fix this issue.