java.lang.RuntimeException: Error receiving broadcast Intent { act=android.net.conn.CONNECTIVITY_CHANGE flg=0x4000010 (has extras) } in zl$a@5eda151 [133313734]

Fixed

Bug

Status Update

No update yet.

Description

ni...@gmail.com

created issue #1

May 23, 2019 07:24AM

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.

Proguard mappings
------------------
androidx.work.impl.constraints.trackers.NetworkStateTracker -> zl
androidx.work.impl.constraints.trackers.ConstraintTracker -> yl
androidx.work.impl.constraints.controllers.ConstraintController -> pl
androidx.work.impl.constraints.WorkConstraintsTracker -> ml
androidx.work.impl.background.systemalarm.WorkTimer -> gl

Crash report from user
-----------------
APP_VERSION_NAME=228 armeabi-v7a
ANDROID_VERSION=5.0
BRAND=samsung
PHONE_MODEL=SM-N9005
PRODUCT=hltexx
USER_APP_START_DATE=2019-05-22T09:58:13.756+01:00
USER_CRASH_DATE=2019-05-22T19:21:59.888+01:00
STACK_TRACE=java.lang.RuntimeException: Error receiving broadcast Intent { act=android.net.conn.CONNECTIVITY_CHANGE flg=0x4000010 (has extras) } in zl$a@5eda151
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:933)
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:5938)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1400)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1195)
Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@220005dc rejected from java.util.concurrent.ScheduledThreadPoolExecutor@ffebca8[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 gl.a(SourceFile:7)
at dl.b(SourceFile:5)
at ml.a(SourceFile:21)
at pl.b(SourceFile:3)
at pl.a(SourceFile:18)
at yl.a(SourceFile:17)
at zl$a.onReceive(SourceFile:4)
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:923)
... 8 more

LOGCAT=--------- beginning of main
05-22 19:21:59.727 D/AndroidRuntime(11913): Shutting down VM
05-22 19:21:59.757 E/ACRA (11913): ACRA caught a RuntimeException for com.nll.asr
05-22 19:21:59.757 E/ACRA (11913): java.lang.RuntimeException: Error receiving broadcast Intent { act=android.net.conn.CONNECTIVITY_CHANGE flg=0x4000010 (has extras) } in zl$a@5eda151
05-22 19:21:59.757 E/ACRA (11913): at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:933)
05-22 19:21:59.757 E/ACRA (11913): at android.os.Handler.handleCallback(Handler.java:739)
05-22 19:21:59.757 E/ACRA (11913): at android.os.Handler.dispatchMessage(Handler.java:95)
05-22 19:21:59.757 E/ACRA (11913): at android.os.Looper.loop(Looper.java:145)
05-22 19:21:59.757 E/ACRA (11913): at android.app.ActivityThread.main(ActivityThread.java:5938)
05-22 19:21:59.757 E/ACRA (11913): at java.lang.reflect.Method.invoke(Native Method)
05-22 19:21:59.757 E/ACRA (11913): at java.lang.reflect.Method.invoke(Method.java:372)
05-22 19:21:59.757 E/ACRA (11913): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1400)
05-22 19:21:59.757 E/ACRA (11913): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1195)
05-22 19:21:59.757 E/ACRA (11913): Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@220005dc rejected from java.util.concurrent.ScheduledThreadPoolExecutor@ffebca8[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
05-22 19:21:59.757 E/ACRA (11913): at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2011)
05-22 19:21:59.757 E/ACRA (11913): at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:793)
05-22 19:21:59.757 E/ACRA (11913): at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:298)
05-22 19:21:59.757 E/ACRA (11913): at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:503)
05-22 19:21:59.757 E/ACRA (11913): at java.util.concurrent.Executors$DelegatedScheduledExecutorService.schedule(Executors.java:644)
05-22 19:21:59.757 E/ACRA (11913): at gl.a(SourceFile:7)
05-22 19:21:59.757 E/ACRA (11913): at dl.b(SourceFile:5)
05-22 19:21:59.757 E/ACRA (11913): at ml.a(SourceFile:21)
05-22 19:21:59.757 E/ACRA (11913): at pl.b(SourceFile:3)
05-22 19:21:59.757 E/ACRA (11913): at pl.a(SourceFile:18)
05-22 19:21:59.757 E/ACRA (11913): at yl.a(SourceFile:17)
05-22 19:21:59.757 E/ACRA (11913): at zl$a.onReceive(SourceFile:4)
05-22 19:21:59.757 E/ACRA (11913): at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:923)
05-22 19:21:59.757 E/ACRA (11913): ... 8 more

REPORT_ID=a476ba1d-9c82-4b7a-90cd-5d91e77df69d
IS_SILENT=false

Comments

li...@gmail.com <li...@gmail.com> #2May 23, 2019 10:50AM

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).

ra...@google.com <ra...@google.com> #3May 23, 2019 05:06PM

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.

ra...@google.com <ra...@google.com> #4May 23, 2019 05:17PM

How often are those actions being called? Any idea how big this chain is?

ni...@gmail.com <ni...@gmail.com> #5May 23, 2019 05:17PM

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 })

ra...@google.com <ra...@google.com> #6May 23, 2019 05:20PM

ni...@gmail.com <ni...@gmail.com> #7May 23, 2019 05:31PM

Fixed in

https://android-review.googlesource.com/c/platform/frameworks/support/+/932127

su...@google.com <su...@google.com> #8May 23, 2019 05:51PM

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.

ni...@gmail.com <ni...@gmail.com> #9May 23, 2019 05:57PM

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!

su...@google.com <su...@google.com> #10May 23, 2019 07:17PM

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.

ni...@gmail.com <ni...@gmail.com> #11May 23, 2019 08:03PM

Here it is

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)

ra...@google.com <ra...@google.com> #12May 23, 2019 08:21PM

Can you also turn on verbose logging in WorkManager while I am investigating this, so we can better understand what might be going on?

For that you need to custom initialize WorkManager.

Configuration configuration = new Configuration.Builder()
.setMinimumLoggingLevel(Log.DEBUG)
.build();

WorkManager.initialize(context, configuration);

Make sure you disable the default WorkManager initializer.

ni...@gmail.com <ni...@gmail.com> #13May 23, 2019 08:33PM

I can but it won't make any difference. Crash log submission is voluntary in my app. User has to tap the notification, select send, open their email client and send the attachment. Since I cannot reproduce it in my test devices, I would need to push an update to the app logging enabled and hope that it crashes on someone that willing to send crash logs.

ni...@gmail.com <ni...@gmail.com> #14May 23, 2019 08:33PM

Perhaps someone who are able to reproduce it can send them?

ra...@google.com <ra...@google.com> #15May 23, 2019 08:36PM

Yes, that's what I meant. If you push it out with logging enabled, you might see more information associated with the crash report.

ra...@google.com <ra...@google.com> #16May 23, 2019 10:40PM

One other question is: Are you absolutely sure that these crash reports are coming are actually coming from an app which was built with WorkManager 2.1.0-alpha0x ?

li...@gmail.com <li...@gmail.com> #17May 24, 2019 06:13AM

#3： My fault. The issue is happening on Android 5&4.

ra...@google.com <ra...@google.com> #18May 24, 2019 03:32PM

Can you also answer #16? My suspicion is those crashes could be coming from an older version of the app that does not have the bugfix.

li...@gmail.com <li...@gmail.com> #19May 25, 2019 12:20AM

#16: Yes, we are using WorkManager 2.1.0-alpha01

ra...@google.com <ra...@google.com> #20May 29, 2019 04:49AM

Marked as fixed, reassigned to ra...@google.com.

Fixed by

https://android-review.googlesource.com/c/platform/frameworks/support/+/971650