IssueTracker

After creating the issue I've noticed that I mixed up a few terms, sorry about that. JobService should be JobScheduler. When referring to jobs in the description, those are classes extending Worker.

We have a large set of users seeing this same issue... I can confirm that it seems to only effect users using Android OS 4.4 - 5.1.  We are also using WorkManager 2.0.0

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 098c163581a360c32baa6e4c215227f0efd10889
Author: Rahul Ravikumar <rahulrav@google.com>
Date:   Mon Mar 25 14:05:34 2019

    Reset WorkConstraintsTracker when cleaning up in DelayMetCommandHandler.
   
    * DelayMetCommandHandler would previously not cleanup correctly and WorkConstraintsTracker
      would trigger callbacks without going through the SystemAlarmDispatcher lifecycle
      of processing a command.
   
    Fixes: b/129226383
    Test: Added a unit test.
    Change-Id: Id2aaf0cce7c4a1a4526a25a211f3fe0551dbe557

M       work/workmanager/src/androidTest/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcherTest.java
M       work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/DelayMetCommandHandler.java

https://android-review.googlesource.com/933140
https://goto.google.com/android-sha1/098c163581a360c32baa6e4c215227f0efd10889

Great to see such a quick fix. Do you have any estimate when a new version that includes this change will be released?

It should be available in the next 2.x.x version.

ETA?

Hi, we have implemented a new big feature using WorkManager and got the same issue. We have been considering third party alternatives because we need to deliver this ASAP. But if you confirm that we will have that version within next few days we can wait for it.

Thanks for reporting this, OP, and thanks for the quick fix, Android team... my users were seeing this too...

We are using workmanager 2.1.0-alpha01 which include code change of https://android-review.googlesource.com/933140, but a lot crashes caused by same problems still showing in firebase console.

Affected Android Version
62% Android 5
37% Android 4
1%  Android 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@42203f30
       at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:769)
       at android.os.Handler.handleCallback(Handler.java:733)
       at android.os.Handler.dispatchMessage(Handler.java:95)
       at android.os.Looper.loop(Looper.java:136)
       at android.app.ActivityThread.main(ActivityThread.java:5433)
       at java.lang.reflect.Method.invokeNative(Method.java)
       at java.lang.reflect.Method.invoke(Method.java:515)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1268)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1084)
       at dalvik.system.NativeStart.main(NativeStart.java)

Caused by java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@421dec00 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@4222d1a8[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:759)
       at android.os.Handler.handleCallback(Handler.java:733)
       at android.os.Handler.dispatchMessage(Handler.java:95)
       at android.os.Looper.loop(Looper.java:136)
       at android.app.ActivityThread.main(ActivityThread.java:5433)
       at java.lang.reflect.Method.invokeNative(Method.java)
       at java.lang.reflect.Method.invoke(Method.java:515)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1268)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1084)
       at dalvik.system.NativeStart.main(NativeStart.java)

Are you sure that these crash reports are coming from the latest version of your app which has the new version of WorkManager ?

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.

This would still happen in some rare conditions. So we have another fix for it in 2.1.0-alpha03.

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.

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!

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

Thank you. Can you please point me to the commit/file which represents the configuration for WorkManager 1.0.0-alpha09? Maybe here https://android.googlesource.com/platform/frameworks/support/+log/androidx-master-dev/work/workmanager/proguard-rules.pro?

There isn't one for alpha09... it's already released.  You can modify that commit and adapt it to alpha09.

Just change WorkParameters -> WorkerParameters.

Which commit do you refer to? The link I posted show the history of the proguard-rules.pro commits. Since the file exists for a year I would have expected that there was a version of the file which shipped with WorkManager 1.0.0-alpha which was released by September 19, 2018.

Or do you mean that the proguard-rules.pro being shipped with WorkManager 1.0.0-alpha is buggy?

Yes, alpha09 had a bug.  #19 suggests a modification to your app's proguard config to get around the issue.  alpha10 should be out soon with the fix.

Thank you for the clarification.

I prepared my test branch according to your recommendations (ProGuard, compileSdkVersion, targetSdkVersion, support libraries) as you can see here:
https://github.com/EventFahrplan/EventFahrplan/compare/master...workmanager

The release build however still fails:

00:20:09.182 [QUIET] [system.out] Note: androidx.work.impl.Schedulers: can't find dynamically referenced class androidx.work.impl.background.firebase.FirebaseJobService
00:20:09.182 [QUIET] [system.out] Note: androidx.work.impl.Schedulers: can't find dynamically referenced class androidx.work.impl.background.firebase.FirebaseJobScheduler
00:20:09.210 [QUIET] [system.out] Note: kotlin.internal.PlatformImplementationsKt: can't find dynamically referenced class kotlin.internal.jdk8.JDK8PlatformImplementations
00:20:09.210 [QUIET] [system.out] Note: kotlin.internal.PlatformImplementationsKt: can't find dynamically referenced class kotlin.internal.JRE8PlatformImplementations
00:20:09.210 [QUIET] [system.out] Note: kotlin.internal.PlatformImplementationsKt: can't find dynamically referenced class kotlin.internal.jdk7.JDK7PlatformImplementations
00:20:09.210 [QUIET] [system.out] Note: kotlin.internal.PlatformImplementationsKt: can't find dynamically referenced class kotlin.internal.JRE7PlatformImplementations
00:20:09.212 [QUIET] [system.out] Note: kotlin.jvm.internal.Reflection: can't find dynamically referenced class kotlin.reflect.jvm.internal.ReflectionFactoryImpl
00:20:09.228 [QUIET] [system.out] Note: okhttp3.internal.platform.AndroidPlatform: can't find dynamically referenced class com.android.org.conscrypt.SSLParametersImpl
00:20:09.228 [QUIET] [system.out] Note: okhttp3.internal.platform.AndroidPlatform: can't find dynamically referenced class org.apache.harmony.xnet.provider.jsse.SSLParametersImpl
00:20:09.228 [QUIET] [system.out] Note: okhttp3.internal.platform.AndroidPlatform$CloseGuard: can't find dynamically referenced class dalvik.system.CloseGuard
00:20:09.228 [QUIET] [system.out] Note: okhttp3.internal.platform.ConscryptPlatform: can't find dynamically referenced class org.conscrypt.ConscryptEngineSocket
00:20:09.229 [QUIET] [system.out] Note: okhttp3.internal.platform.Platform: can't find dynamically referenced class sun.security.ssl.SSLContextImpl
00:20:09.955 [QUIET] [system.out] Note: the configuration keeps the entry point 'androidx.core.graphics.drawable.IconCompatParcelizer { android.support.v4.graphics.drawable.IconCompat read(androidx.versionedparcelable.VersionedParcel); }', but not the descriptor class 'androidx.versionedparcelable.VersionedParcel'
00:20:09.955 [QUIET] [system.out] Note: the configuration keeps the entry point 'androidx.core.graphics.drawable.IconCompatParcelizer { void write(android.support.v4.graphics.drawable.IconCompat,androidx.versionedparcelable.VersionedParcel); }', but not the descriptor class 'androidx.versionedparcelable.VersionedParcel'

These aren't failures (unless your configuration has a problem).  As you can see, you have things listed from other libraries like okhttp as well.

Maybe, I missing the specific part in the output. I pasted a large part of the lower end here: http://pastebin.de/8421/

You need to add:

-dontwarn sun.misc.Unsafe

Thank you. This made the release build succeed.
Can you please explain which library (version) introduces the Unsafe class?

I am still facing this issue with WorkManager-1.0.0-beta01

2018-12-31 01:40:32.701 2947-2977/de.aurora.mggvertretungsplan.debug E/WM-WorkerFactory: Could not instantiate de.aurora.mggvertretungsplan.services.DownloadTimeTableWorker
    java.lang.IllegalAccessException: Class java.lang.Class<androidx.work.WorkerFactory> cannot access  method void de.aurora.mggvertretungsplan.services.DownloadTimeTableWorker.<init>(android.content.Context, androidx.work.WorkerParameters) of class java.lang.Class<de.aurora.mggvertretungsplan.services.DownloadTimeTableWorker>
        at java.lang.reflect.Constructor.newInstance0(Native Method)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:343)
        at androidx.work.WorkerFactory.createWorkerWithDefaultFallback(WorkerFactory.java:92)
        at androidx.work.impl.WorkerWrapper.runWorker(WorkerWrapper.java:191)
        at androidx.work.impl.WorkerWrapper.run(WorkerWrapper.java:125)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)
2018-12-31 01:40:32.701 2947-2977/de.aurora.mggvertretungsplan.debug E/WM-WorkerWrapper: Could not create Worker de.aurora.mggvertretungsplan.services.DownloadTimeTableWorker

My code can be found at https://github.com/d-Rickyy-b/MGGVertretungsplan.

I'd be very grateful for any kind of support.

Okay... I feel pretty stupid now - it seems that my constructor was package-private and for workmanager to work, it needed to be public. Maybe the exception could point to that issue?

That is correct. Worker must have a public constructor unless you instantiate it via your own WorkerFactory.