Navigation Component back‑stack restoration fails after process death when using dynamic NavGraph

Answer

Dynamic NavGraph modifications are not persisted across process death unless you rebuild the exact same graph (same destination IDs and structure) before the system restores the saved state. If you call setGraph() again after restoration, the restored back‑stack is overwritten and only the start destination remains.

Likely explanation

The Navigation component saves the back‑stack in NavController.onSaveState(). During activity recreation, NavHost restores that state by re‑applying the navigation actions that led to the current destination. This works only if the graph present at restoration time matches the graph that was active when the state was saved. When the graph is built dynamically with IDs that change each run (e.g., counters, UUIDs, or data‑derived values), the restored NavBackStackEntry objects reference IDs that no longer exist, so they are dropped and the stack appears empty.

Confirmed facts

• NavController stores each NavBackStackEntry in a SavedStateHandle attached to the NavController.
• During onCreate of the host activity, the NavHost calls navController.setGraph(graph); if the graph already contains a restored state, the call merges the saved back‑stack.
• If setGraph() is invoked a second time after the state has been merged, the graph is replaced with a fresh one and the saved entries are discarded.
• This behavior is consistent across Navigation library versions 2.2+; restoration bugs were addressed in 2.4.0‑alpha06 and later, but the core requirement of a stable graph remains.

Steps to fix

1. Build the NavGraph deterministically: use hard‑coded, stable integer IDs (or IDs derived from constants) for every destination, regardless of runtime data.
2. Guard the graph‑setup code so it runs only when no graph has been restored yet. Example:

if (navController.graph.startDestinationId == 0) { // 0 indicates no graph set yet
    val dynamicGraph = buildDynamicGraph() // deterministic builder
    navController.setGraph(dynamicGraph)
}

3. If the graph must vary based on runtime data (e.g., server‑driven start destination), persist the minimal inputs needed to rebuild the identical graph in onSaveInstanceState() or a SavedStateHandle, then rebuild the graph before any possible state restoration.
4. Verify that you are not calling setGraph() again later in the lifecycle (e.g., in a ViewModel observer or after a deep‑link handler) after the initial setup.

Missing diagnostic detail

If you are using a custom NavController.Factory, please confirm whether it recreates the NavController with the same arguments after process death; a factory that supplies a different graph instance can affect whether the above guard is sufficient.