Introduction

If your app opens with a navigation drawer, the highlighted drawer item should match the screen the user is actually seeing. In Android, the usual fix is to set the initial content first and then mark the corresponding menu item as checked with NavigationView.setCheckedItem(...).

The Basic Pattern

A NavigationView manages a menu, and one of those items can be checked at a time. The Android API exposes this directly through setCheckedItem.

In Kotlin:

1class MainActivity : AppCompatActivity() {
2
3    override fun onCreate(savedInstanceState: Bundle?) {
4        super.onCreate(savedInstanceState)
5        setContentView(R.layout.activity_main)
6
7        val navigationView = findViewById<NavigationView>(R.id.nav_view)
8
9        if (savedInstanceState == null) {
10            supportFragmentManager.beginTransaction()
11                .replace(R.id.content_frame, HomeFragment())
12                .commit()
13
14            navigationView.setCheckedItem(R.id.nav_home)
15            title = "Home"
16        }
17    }
18}

That gives you the correct startup highlight and prevents replacing the fragment again after configuration changes.

Keep the UI State in Sync

Setting the checked item alone is not enough. The selected drawer item, the visible fragment, and the toolbar title should all point to the same destination.

A clean startup sequence is:

1. decide which screen is the initial destination
2. load that screen
3. mark the matching drawer item as checked
4. update any title or app bar state

If you skip step two and only call setCheckedItem, the drawer highlight lies to the user. If you skip step three, the content is right but the drawer looks wrong.

Manual Navigation Listener Example

If you manage drawer navigation manually, keep the listener and the startup state aligned:

1navigationView.setNavigationItemSelectedListener { item ->
2    when (item.itemId) {
3        R.id.nav_home -> {
4            supportFragmentManager.beginTransaction()
5                .replace(R.id.content_frame, HomeFragment())
6                .commit()
7            title = "Home"
8        }
9        R.id.nav_settings -> {
10            supportFragmentManager.beginTransaction()
11                .replace(R.id.content_frame, SettingsFragment())
12                .commit()
13            title = "Settings"
14        }
15    }
16
17    item.isChecked = true
18    drawerLayout.closeDrawers()
19    true
20}

Notice the symmetry: startup should use the same destination assumptions as the listener.

Alternative: Mark the Menu Item Directly

You can also access the MenuItem and mark it checked:

navigationView.menu.findItem(R.id.nav_home).isChecked = true

This works, but setCheckedItem(R.id.nav_home) is clearer because it communicates the intent directly and uses the dedicated API designed for the NavigationView.

If You Use the Navigation Component

In newer apps using the Jetpack Navigation component, the checked state is often driven by the current destination. In that setup, your real job is to navigate to the correct start destination and wire the NavigationView to the NavController.

Even then, the underlying rule stays the same: the highlighted drawer item should reflect the active destination, not some separate startup flag.

If you are not using NavController, then manual setCheckedItem is the direct answer.

Handling Restored State Correctly

A common bug is resetting the startup destination every time onCreate runs. On rotation or process recreation, the fragment manager may already be restoring the previous fragment. If you blindly replace it again, you can break back stack behavior or momentarily show the wrong screen.

That is why this guard matters:

if (savedInstanceState == null) {
    // initial setup only
}

Use it when setting the initial fragment and initial checked item.

Java Version

If your project is in Java, the idea is identical:

1NavigationView navigationView = findViewById(R.id.nav_view);
2
3if (savedInstanceState == null) {
4    getSupportFragmentManager()
5        .beginTransaction()
6        .replace(R.id.content_frame, new HomeFragment())
7        .commit();
8
9    navigationView.setCheckedItem(R.id.nav_home);
10    setTitle("Home");
11}

The important part is not the language. It is syncing the highlighted item with the destination the activity actually shows.

Common Pitfalls

The most common mistake is setting the checked drawer item without loading the corresponding fragment. That leaves the UI in an inconsistent state.

Another issue is doing the startup replacement unconditionally, which can override restored state on rotation and make the selected item jump unexpectedly.

Developers also sometimes mark the menu item checked inside the listener but forget to do the same during the initial launch path. The result is a correct highlight after user interaction, but no correct highlight on startup.

Finally, avoid duplicating navigation rules in several places. If startup picks one destination while the listener or NavController logic assumes another, the drawer state drifts out of sync.

Summary

• Use navigationView.setCheckedItem(...) to highlight the startup drawer item.
• Load the matching fragment or destination at the same time.
• Guard the initial setup with savedInstanceState == null.
• Keep the checked item, visible content, and title synchronized.
• Prefer the dedicated setCheckedItem API over ad hoc menu-state manipulation when using NavigationView.