PopUpTo to parent NavGraph crashes when child nav-graph has non-nullable arguments [249988437]

Fixed

Bug

Status Update

No update yet.

Description

da...@sucharda.cz

created issue #1

Sep 30, 2022 02:32PM

Component used: Navigation
Version used: 2.5.1 and 2.5.2
Last known working version: 2.3.5
Devices/Android versions reproduced on: Huawei P20 Light / AN 9 (EMUI 9.1.0)

So our navigation is kinda complex so I will try to simplify the configuration. If there is a nested graph with arguments which cannot be null (and no default value is supplied) and popUpTo is used to remove nested graph during destination (nested) navigation it tries to recreate nested graph as a parent for the destination being navigated to.

<navigation xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:id="@+id/parentNavGraph"
    app:startDestination="@id/parentFragment">

    <fragment
        android:id="@+id/parentFragment"
        android:label="parentFragment"
        tools:layout="@layout/fragment_parent">

        <action
            android:id="@+id/actionToChildGraph"
            app:destination="@id/childNavGraph"/>

    </fragment>

    <navigation
        android:id="@+id/childNavGraph"
        app:startDestination="@id/childFragment">

        // Note: this is a duplicate due to NavArgs since it will not see "childFragment" args
        <argument
            android:name="argumentLong"
            app:argType="long"
            app:nullable="false"/>

        <fragment
            android:id="@+id/childFragment"
            android:label="childFragment"
            tools:layout="@layout/fragment_child">

            <argument
                android:name="argumentLong"
                app:argType="long"
                app:nullable="false"/>

            <action
                android:id="@+id/actionToChildFragment2"
                app:destination="@id/childFragment2"
                app:popUpTo="@id/childNavgraph"
                app:popUpToInclusive="true"/>

        </fragment>

        <fragment
            android:id="@+id/childFragment2"
            android:label="childFragment2"
            tools:layout="@layout/fragment_child_2"/>

</navigation>

So now if the navigation is triggered like this:

findNavController().navigate(
  ChildFragmentDirections.actionToChildFragment2()
)

It will pop fragments from back stack, but it will not change parent for ChildFragment2 which will be set to childNavGraph and since it is not in the back stack anymore it will try to recreate it with default values. But argumentLong is not nullable and has no default value so it will crash:

// NOTE: this crash is from Navigation version 2.5.1
java.lang.NullPointerException: null cannot be cast to non-null type kotlin.Long
  at androidx.navigation.NavType$Companion$LongType$1.get(NavType.kt:352)
  at androidx.navigation.NavType$Companion$LongType$1.get(NavType.kt:342)
  at androidx.navigation.NavArgument.verify(NavArgument.kt:76)
  at androidx.navigation.NavDestination.addInDefaultArgs(NavDestination.kt:502)
  at androidx.navigation.NavController.addEntryToBackStack(NavController.kt:1865)
  at androidx.navigation.NavController.addEntryToBackStack$default(NavController.kt:1813)
  at androidx.navigation.NavController$navigate$4.invoke(NavController.kt:1721)
  at androidx.navigation.NavController$navigate$4.invoke(NavController.kt:1719)
  at androidx.navigation.NavController$NavControllerNavigatorState.push(NavController.kt:287)
  at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.kt:246)
  at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.kt:162)
  at androidx.navigation.NavController.navigateInternal(NavController.kt:260)
  at androidx.navigation.NavController.navigate(NavController.kt:1719)
  at androidx.navigation.NavController.navigate(NavController.kt:1545)
  at androidx.navigation.NavController.navigate(NavController.kt:1472)
  at androidx.navigation.NavController.navigate(NavController.kt:1930)

Note: Interesting thing is that it does not crash with non-nullable String argument for some reason (ah I see, it is because String NavType is nullable by default: StringType: NavType<String?> vs LongType: NavType<Long>).

Possible fixes for us:

Do not use popUpTo to pop parent (navGraph) of a Fragment (node) from XML but use popBackStack from code instead.
Add default value to argumentLong.

Basically I am not sure if this an intended behavior or a bug. Gonna mark it as a bug because it worked in 2.3.5. I understand that Destination should have a parent but what is the reason to create a parent that does not exist and will never be displayed in this case, since it was already poped and thus it should not be displayed to the user.

At the moment two solutions come to mind:

Change new Fragment (node) parent to last destination in back stack after poping. Here I am not really sure if parent is designed this way and if it can be done without breaking something else.
Make LongType and other types nullable same as StringType. Again not sure if this can be done and it probably is not a proper solution (change).

There might of course be other solutions that I cannot see.

Thank you for your time and help.

Comments

da...@sucharda.cz <da...@sucharda.cz> #2Sep 30, 2022 02:38PM

Any update on this issue? We are seeing same crashes on lower end devices. Is there any temporary fix we could use?

jb...@google.com <jb...@google.com> #3Sep 30, 2022 04:37PM

da...@sucharda.cz <da...@sucharda.cz> #4Oct 20, 2022 04:26PM

deleted

da...@sucharda.cz <da...@sucharda.cz> #5Oct 20, 2022 04:30PM

In our case, we have b2b app running on dedicated devices.

After 1.1.0 DataStore update we had 6 terminals reported 30k androidx.datastore.core.CorruptionException fatal crashes on app start.

We use DataStore in WorkManager jobs and on regular Activity starts. Seems that after the application gets this state it will never will succeed to start successfully again. I am afraid that data is being corrupted.

Can't reproduce. But same as OP, we have very vanilla usage of DataStore Preferences. No multiple processes, just simple read/write key-values in a single process single Activity.

jb...@google.com <jb...@google.com> Nov 8, 2022 05:32PM

Assigned to cl...@google.com.

cl...@google.com <cl...@google.com> #6Mar 15, 2023 08:32PM

Marked as fixed.

Hi, thanks for the feedback, noticed the number of +1s, I'll prioritize an investigation.

To facilitate the process, could you please share how you create the DataStore instance?

ap...@google.com <ap...@google.com> #7Mar 15, 2023 08:32PM

Here is how we are creating our DataStore<Preferences> instances:

PreferenceDataStoreFactory.create(
    produceFile = { context.preferencesDataStoreFile(filename) }, // filename is [a-zA-Z]
    scope = scope, // CoroutineScope(Dispatchers.IO + SupervisorJob())
    migrations = listOf(
        SharedPreferencesMigration(
            context = context,
            sharedPreferencesName = sharedPrefFile, // we are using our package name here
            keysToMigrate = keysToMigrate, // a Set<String>, sometimes empty if nothing to be migrated
        ),
    ),
    corruptionHandler = ReplaceFileCorruptionHandler {
        // logging step omitted
        emptyPreferences()
    },
)

And these methods are called in Hilt @Provides methods in a @InstallIn(SingletonComponent::class) @Module for each preferences we use in our app.

pr...@google.com <pr...@google.com> #8Mar 22, 2023 08:23PM

@Module
@InstallIn(SingletonComponent::class)
class PreferencesDataStoreModule {

    @Provides
    @Singleton
    fun provideDataStore(@ApplicationContext context: Context): DataStore<Preferences> =
        PreferenceDataStoreFactory.create(
            produceFile = {
                context.preferencesDataStoreFile(PREFERENCES_FILE_NAME)
            },
        )
}