Fixed
Status Update
No update yet.
Comments
ap...@google.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).
ru...@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.
su...@google.com
ru...@gmail.com
How often are those actions being called? Any idea how big this chain is?
su...@google.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 })
Description
Version used: 1.0.0-beta03
Devices/Android versions reproduced on: couldn't reproduce
Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'boolean android.os.PowerManager$WakeLock.isHeld()' on a null object reference
at androidx.work.impl.utils.WakeLocks.checkWakeLocks(WakeLocks.java:89)
at androidx.work.impl.background.systemalarm.SystemAlarmService.onAllCommandsCompleted(SystemAlarmService.java:69)
at androidx.work.impl.background.systemalarm.SystemAlarmDispatcher.dequeueAndCheckForCompletion(SystemAlarmDispatcher.java:217)
at androidx.work.impl.background.systemalarm.SystemAlarmDispatcher$DequeueAndCheckForCompletion.run(SystemAlarmDispatcher.java:317)
at android.os.Handler.handleCallback(Handler.java:810)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:189)
at android.app.ActivityThread.main(ActivityThread.java:5529)
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:950)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:745)
Seems like the copy of wake locks can contain null keys. I couldn't reproduce this, but some devices on crashlytics are reporting this crash.