IssueTracker

One more detail here.
The body of navigateUp() method of NavController class (1.0.0-rc01) looks like this:

if (mBackStack.size() == 1) {
    // If there's only one entry, then we've deep linked into a specific destination
    // on another task so we need to find the parent and start our task from there
    ...        
} else {
    return popBackStack();
}

If I put a breakpoint on the very first line of that code and invoke this method anyhow, I can see that the size of mBackStack is actually 2 (with both root and child fragments).
So, the code doesn't consider the current case a deeplink case, but as a regular opening of the child destination.

I described this issue earlier, in https://issuetracker.google.com/issues/126014176

Partially agree, but my case doesn't use nested graphs at all, so my issue is just simpler.
However, the actual problem seems to be the same: the library treats absence of Intent.FLAG_ACTIVITY_NEW_TASK as it is actually set, because all 'start destinations' are still added before the actual deeplink destination (as it is explained in the documentation where the flag is set).

This is a regression caused by https://android-review.googlesource.com/833717 where the NavGraph destinations would always be added to the back stack (it isn't both the root and child fragments, but the root graph and the child fragment) to avoid IllegalArgumentExceptions. Unfortunately, that broke the navigateUp() behavior, which is something we'll fix :)

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

commit 781d0178da33d84f615b409b17975c8ba290401c
Author: Ian Lake <ilake@google.com>
Date:   Mon Feb 25 15:38:23 2019

    Fix navigateUp() logic when on another app's task
   
    When using deep linking on another app's task,
    only the final destination is created, ensuring that
    hitting the system back button goes back to the
    other app. The Up button, via navigateUp(), should
    take users to your own task on the parent destination.
   
    Recent changes made it so that we always add the
    parent NavGraphs to the back stack, meaning the simple
    check of back stack size == 1 does not properly handle
    this change in behavior so instead we need to check for
    the number of non-NavGraph destinations on the back
    stack.
   
    Test: new NavControllerActivityTest
    BUG: 126082008
    Change-Id: I7bf18d38e1cdd3818e7414ba44d84df0abd81b88

M       navigation/runtime/src/androidTest/AndroidManifest.xml
A       navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerActivityTest.kt
M       navigation/runtime/src/main/java/androidx/navigation/NavController.java

https://android-review.googlesource.com/912258
https://goto.google.com/android-sha1/781d0178da33d84f615b409b17975c8ba290401c

A fix will be available in Navigation 1.0.0-rc02. Thanks for reporting it and the great sample app!

Thanks, Ian.

Just a "+1" "me too" to add another voice to this... would make so much sense to be able to have setInitialDelay() on PeriodicWorkRequest.Builder

Android must list down the challenges of Periodic Work request  in there documents, I am  tracking Work Manager since it was alpha.Here are the limitations of Priodic Work request:
1. Periodic work request does not support setInitialDelay.
2. Periodic Work request does not support the Chining.

Both of these items are listed in the official documentation for PeriodicWorkRequest: https://developer.android.com/reference/androidx/work/PeriodicWorkRequest

"Periodic work has a minimum interval of 15 minutes and it cannot have an initial delay."
"Periodic work cannot be part of a chain or graph of work."

Still not supported...
I feel that many people need it...would make so much sense to be able to have setInitialDelay() on PeriodicWorkRequest.Builder

Setting a flex period effectively delays a PeriodicWorkRequest.

+1 from me too, with an extra option to limit the number of repeats, for example, run a periodic job daily for 7 days and then stop.

+1 for setInitailDelay() and limitNumberOfFires() for Periodic work request!

What is the best solution for now to setInitailDelay() ?

You can use a PeriodicWorkRequest.Builder with a flex Period as suggested in #13.
This behaviour is documented: https://developer.android.com/reference/androidx/work/PeriodicWorkRequest.Builder#PeriodicWorkRequest.Builder(java.lang.Class%3C?%20extends%20androidx.work.ListenableWorker%3E,%20long,%20java.util.concurrent.TimeUnit,%20long,%20java.util.concurrent.TimeUnit)

The call creates a PeriodicWorkRequest to run periodically once within the flex period of every interval period.

What I mean by setInitailDelay() is the delay before the first run then a fixed periodic delay.

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

commit 25dc21990f5b0d606f3141b9120516b880599b6c
Author: Rahul Ravikumar <rahulrav@google.com>
Date:   Mon Apr 29 10:27:18 2019

    Add support for initialDelays for PeriodicWorkRequests.
   
    Test: Additional WorkSpecTest unit tests.
    Integration tests on API 23, and API 21.
   
    Fixes: b/111404867
   
    Change-Id: I9eae1c7cf527c231b831f22c6a2d10089d6a63c9

M       work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/MainActivity.java
M       work/integration-tests/testapp/src/main/res/layout/activity_main.xml
M       work/integration-tests/testapp/src/main/res/values/strings.xml
M       work/workmanager/api/2.1.0-alpha01.txt
M       work/workmanager/api/current.txt
M       work/workmanager/src/androidTest/java/androidx/work/WorkSpecTest.java
M       work/workmanager/src/main/java/androidx/work/OneTimeWorkRequest.java
M       work/workmanager/src/main/java/androidx/work/WorkRequest.java
M       work/workmanager/src/main/java/androidx/work/impl/WorkerWrapper.java
M       work/workmanager/src/main/java/androidx/work/impl/background/systemjob/SystemJobScheduler.java
M       work/workmanager/src/main/java/androidx/work/impl/model/WorkSpec.java

https://android-review.googlesource.com/953484
https://goto.google.com/android-sha1/25dc21990f5b0d606f3141b9120516b880599b6c

still can't rely on it :(
I calculate millis to midnight and schedule a daily backup with PeriodicWorkRequest (should happen each 24h), and it just won't fire up the Worker.
When I remove setInitialDelay() call, PeriodicWorkRequest - it works!

classic