IssueTracker

If you need to add a custom Navigator but don't want to subclass NavHost (which we expect will be needed in most cases), the correct approach is to add it before you set your graph:
1) Don't use app:navGraph in your XML
2) Get a reference to your NavController
3) Add your Navigator to the NavController
4) Call setGraph on the NavController

This relies on the fact that NavController waits until the graph is set before restoring state / doing anything at all.

Technically, the createFragmentNavigator() call in NavHostFragment is already called at the same time as your proposed onNavControllerCreated() method so as a workaround, you could override that method, add your Navigator, then return super.createFragmentNavigator().

The first solution does not work, because after screen rotation, the graph (probably a restored graph) is set when Activity.setContentView() is called.

The workaround with createFragmentNavigator() works, though it's not very elegant. Maybe the method could be renamed to createNavigators() and return a list or an array of Navigators?
Anyway, it is a good enough solution for now, so it is not very urgent.

In conclusion:
* I think that a better support for custom destinations should be provided before final release.
* I would suggest describing the "Add support for new destination types" section in the documentation in more details.

Thank you

I suspect the issue you're running into for the first solution is that you're using the setGraph(R.navigation.graph) method, which does indeed cause it to automatically inflate the graph by id on rotation. Using setGraph(navGraph) where navGraph is a navGraph object you've inflated with navController.getNavInflater().inflate(R.navigation.graph) will never automatically be recreated.

Definitely something we can do better on though :)

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

commit a2e68921841727237528c4ac7076d50af64663c8
Author: Ian Lake <ilake@google.com>
Date:   Wed Oct 17 16:46:28 2018

    Make setGraph(int) and setGraph(NavGraph) act identically
   
    Remove the auto restore functionality from NavController's
    setGraph(int) method so that it functions identically to
    setGraph(NavGraph).
   
    This ensures that developers that manually are calling
    setGraph() after adding custom navigators don't get
    recreated too early.
   
    Test: updated NavController test
    BUG: 110763345
    Change-Id: I51ae7c74451669d6bfed0fe84df445c2ff272e6e

M       navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M       navigation/runtime/src/main/java/androidx/navigation/NavController.java

https://android-review.googlesource.com/792819
https://goto.google.com/android-sha1/a2e68921841727237528c4ac7076d50af64663c8

We've decided to remove the automatic recreation that was unique to setGraph(int) - it now acts identically to setGraph(NavGraph), so the flow in #2 can be used to ensure that you have custom Navigators added before calling setGraph.

This fix will be available in 1.0.0-alpha07

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

commit f40bad0faef05bded2d226711338e489309885ba
Author: Ian Lake <ilake@google.com>
Date:   Tue Oct 23 21:03:24 2018

    Ensure NavHostFragment calls setGraph on restore
   
    If a graph is set on NavHostFragment via
    NavHostFragment.create() or through
    app:navGraph, it should be restored immediately
    after the call to restoreState.
   
    Test: testapp now works
    BUG: 110763345
    Change-Id: I7a0c656480e27a66637667519eabe61820b09a6c

M       navigation/fragment/src/main/java/androidx/navigation/fragment/NavHostFragment.java

https://android-review.googlesource.com/799721
https://goto.google.com/android-sha1/f40bad0faef05bded2d226711338e489309885ba

I think your compileSdk is too low.  WorkManager requires it to be 28 or higher: https://irina-dot-devsite.googleplex.com/topic/libraries/architecture/adding-components

I'm not sure why you are running into the warnings about Unsafe, but you can try using -dontwarn sun.misc.Unsafe in your proguard file to see if it helps.  We haven't observed it ourselves.

For what it's worth, one of the notes is referring to WorkParameters still - are you sure it was changed properly?

Sorry, the right url above should be: https://developer.android.com/jetpack/docs/release-notes

I changed the ProGuard configuration as you can see it in the GitHub repository. It matches with your change here https://android-review.googlesource.com/c/platform/frameworks/support/+/782087/2/work/workmanager/proguard-rules.pro if I don't miss anything. I cannot tell why "WorkParameters" is still listed. I verified the output once again by running ./gradlew clean --info --debug aCcc34c3Release. Feel free to run the build yourself. All you need to do is to create a random release-keystore and the app/gradle.properties from the app/gradle.properties.example.

So you saying when I want to migrate my app to targetSdkVersion 26 until November I need to raise the compileSdkVersion to 28 in order to use WorkManager? Using targetSdkVersion 26 with compileSdkVersion 28 won't work?

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.