IssueTracker

This requirement for addObserver to be called on the main thread is part of the Lifecycle 2.3.0-alpha06 release notes, which Fragment/Activity depend on:

LifecycleRegistry now verifies that its methods are called on main thread. It was always a requirement for lifecycles of activities, fragments etc. An addition of observers from non-main threads resulted in hard to catch crashes in runtime.

It affects all APIs that use Lifecycle, including Navigation.

Thanks! Somehow I've missed that.

For the upcoming Navigation 2.4.0-alpha01 release, we've made it explicit that setGraph() and navigate() should only be called on the main thread (by adding @MainThread annotations to the methods), thus aligning with the main thread enforcement of Lifecycle 2.3.

NavBackStackEntry is still not triggering RESUMED on androidx.navigation:navigation-fragment:2.6.0-alpha09 in certain cases, where after a locale or uiMode change with

AppCompatDelegate.setApplicationLocales
AppCompatDelegate.setDefaultNightMode

Issue can be reproduced with attaching LifecycleObserver to the currentBackStackEntry of a Home fragment like so:

       findNavController().currentBackStackEntry?.lifecycle?.let {
            if (it.currentState.isAtLeast(Lifecycle.State.RESUMED)) {
                Timber.d(Constants.LOG_INFO, "lifecycle.currentState", "resumed")
            } else {
                val testLifecycleObserver = object : DefaultLifecycleObserver {
                    override fun onResume(owner: LifecycleOwner) {
                        Timber.d(Constants.LOG_INFO, "lifecycle.currentState", "onResumed")
                        it.removeObserver(this)
                    }
                }
                it.addObserver(testLifecycleObserver)
            }
        }

After performing a config change as mentioned above on a Settings fragment, upon performing a popBackStack/navigateUp to Home fragment, the DefaultLifecycleObserver's onResume will not be triggered. Issue does not occur if a config change is not performed.

I believe this was actually addressed as part of the Navigation 2.6.0-beta01 release. Can you try that out and see if you can still reproduce?