IssueTracker

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

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.

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

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

Gg

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

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.

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!

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.

There shouldn't be any issues with targetSdkVersion 26 and compileSdkVersion 28.

Okay. I will try that. Thanks.
Feel free to contact me if you are not able to build my project.

Does it suffice to raise the compileSdkVersion to 28 or do I also have to raise the version of the support library artifacts at the same time? I tried your suggestion in comment #11 but the build still fails.

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

commit cee9ab55352f3ad506552afb4753baf8648b4c30
Author: Sumir Kataria <sumir@google.com>
Date:   Mon Oct 08 14:20:57 2018

    Fix class name in Proguard configuration.
   
    Bug: 116296569
    Test: N/A
    Change-Id: I3525f9d2f3b06523cbe842b35f97014677879a64

M       work/workmanager/proguard-rules.pro

https://android-review.googlesource.com/782087
https://goto.google.com/android-sha1/cee9ab55352f3ad506552afb4753baf8648b4c30

Support library as well.

Do the latest changes (WorkParameters -> WorkerParameters, NonBlockingWorker -> ListenableWorker) in the ProGuard configuration apply to WorkManager 1.0.0-alpha09 or 1.0.0-alpha10 or both?

alpha10.

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.