Android Development
ActionBar
Menu Item
UI Design
Android Programming

How do I hide a menu item in the actionbar?

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

Introduction

In Android, hiding a menu item is usually a visibility problem, not a layout problem. You define the item in XML, inflate the menu, and then decide at runtime whether the corresponding MenuItem should be visible.

The lifecycle detail that matters is that menu visibility usually belongs in onPrepareOptionsMenu, not only in onCreateOptionsMenu. That is how you keep the menu synchronized with changing UI state.

Define the Menu Item

Start with an ordinary menu resource:

xml
1<menu xmlns:android="http://schemas.android.com/apk/res/android"
2    xmlns:app="http://schemas.android.com/apk/res-auto">
3
4    <item
5        android:id="@+id/action_edit"
6        android:title="Edit"
7        app:showAsAction="ifRoom" />
8</menu>

There is nothing special about the XML for a hideable item. Hiding and showing happens later through the MenuItem API.

Toggle Visibility in an Activity

A standard AppCompatActivity solution looks like this:

kotlin
1class DetailActivity : AppCompatActivity() {
2
3    private var canEdit = false
4
5    override fun onCreateOptionsMenu(menu: Menu): Boolean {
6        menuInflater.inflate(R.menu.detail_menu, menu)
7        return true
8    }
9
10    override fun onPrepareOptionsMenu(menu: Menu): Boolean {
11        menu.findItem(R.id.action_edit).isVisible = canEdit
12        return super.onPrepareOptionsMenu(menu)
13    }
14
15    private fun updateEditPermission(enabled: Boolean) {
16        canEdit = enabled
17        invalidateOptionsMenu()
18    }
19}

The important call is invalidateOptionsMenu(). It tells Android to prepare the menu again, which reruns the visibility logic.

Why onPrepareOptionsMenu Is the Right Place

onCreateOptionsMenu mainly inflates the menu. It may run only once for the activity instance. If the user logs in, changes selection, enters edit mode, or receives new data, that original callback is not enough to keep the menu current.

onPrepareOptionsMenu is designed for the dynamic part. That makes it the right place to hide or show items based on state that can change over time.

If the state truly never changes after creation, setting visibility once is fine. But if the answer can change, call invalidateOptionsMenu() and let the framework re-prepare the menu.

Modern AndroidX Menu Handling

If you are using fragments and a Toolbar, AndroidX MenuProvider is often cleaner than overriding activity methods:

kotlin
1class DetailFragment : Fragment(R.layout.detail_fragment) {
2
3    private var canEdit = false
4
5    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
6        val host: MenuHost = requireActivity()
7
8        host.addMenuProvider(object : MenuProvider {
9            override fun onCreateMenu(menu: Menu, menuInflater: MenuInflater) {
10                menuInflater.inflate(R.menu.detail_menu, menu)
11            }
12
13            override fun onPrepareMenu(menu: Menu) {
14                menu.findItem(R.id.action_edit).isVisible = canEdit
15            }
16
17            override fun onMenuItemSelected(menuItem: MenuItem): Boolean {
18                return menuItem.itemId == R.id.action_edit
19            }
20        }, viewLifecycleOwner)
21    }
22}

The concept is the same. You still decide visibility at prepare time.

Hide Versus Disable

Sometimes removing the item is not the best user experience. If the action should remain visible but unavailable, disable it instead:

kotlin
menu.findItem(R.id.action_edit).isEnabled = false

Hiding removes the affordance completely. Disabling communicates that the action exists but is not currently available. Choose the behavior that best fits the product.

Common Pitfalls

One common mistake is setting visibility in onCreateOptionsMenu and expecting the menu to update automatically later. It will not unless the menu is invalidated and prepared again.

Another mistake is holding a stale MenuItem reference across recreations. It is safer to look the item up each time the menu is prepared.

A third issue is treating a hidden item as a security boundary. UI visibility is only presentation. Real permission checks still belong in the action handler or on the server.

Summary

  • Define the menu item normally in XML.
  • Use menu.findItem(...).isVisible to hide or show it.
  • Put dynamic visibility logic in onPrepareOptionsMenu or onPrepareMenu.
  • Call invalidateOptionsMenu() when the underlying state changes.
  • Hide an item only when disappearance is the right UX; otherwise consider disabling it.

Related reading
Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

All Rights Reserved.