IssueTracker

Component used: Navigation Version used: 2.4 Devices/Android versions reproduced on: all

AppCompatActivity::setupActionBarWithNavController can be called to automatically update app bar content when navigation destination changes. In particular, setupActionBarWithNavController promises to automatically hide the Up arrow for "top-level" destinations and show the Up arrow for all other destinations. To achieve this, setupActionBarWithNavController needs to infer or be told which destinations are "top-level".

When using a BottomNavigationView, I wanted

• the root screen of each tab to have no Up arrow, and
• all other screens to have an Up arrow.

I tried calling setupActionBarWithNavController and passing a custom AppBarConfiguration constructed using the Menu instance from the BottomNavigationView:

AppBarConfiguration.Builder(
  topLevelMenu = bottomNavigationViewMenu
).build()

Unfortunately, when passed a Menu whose entries correspond to navigation graph IDs, AppBarConfiguration::Builder sets the graph IDs as top-level destination IDs, rather than the setting the graph start destination IDs as top-level destination IDs. The result is that the AbstractAppBarOnDestinationChangedListener applied by setupActionBarWithNavController mistakenly classifies every destination as top-level and no screens have an Up arrow.

This can be worked around by explicitly passing the IDs of the start destinations of each tab's graph when constructing the AppBarConfiguration builder:

AppBarConfiguration.Builder(
  topLevelDestinationIds = setOf(
    tab1StartDestinationId,
    tab2StartDestinationId,
    tab3StartDestinationId,
  )
).build()

However, the behavior of AppBarConfiguration.Builder(Menu) remains surprising and it would be good to investigate whether that constructor could be made to behave as I anticipated!

Android Study Group Slack thread: https://androidstudygroup.slack.com/archives/CAZCL8AVB/p1656470310000929?thread_ts=1655997032.467509&cid=CAZCL8AVB