A Primer on Android Navigation

Liam Spradlin
Jul 6, 2017 · 12 min read

Any vehicle someone uses to move between scenes in your interface — that’s navigation

As soon as you link two screens together in an app, you have navigation. That link—whatever it may be—is the vehicle that carries users between those screens. And although creating navigation is relatively simple, creating the right navigation for your users isn’t always straightforward. In this post we’ll take a look at some of the most common navigation patterns used on Android, how they impact system-level navigation, and how to mix and match patterns to suit your interface and your users.

✏️ Defining navigation

Before digging into common navigation patterns, it’s worth stepping back and finding a starting point for thinking about navigation in your app.

  • Build navigation for people

🗂 Tabs


Tabs provide quick navigation between sibling views inside the same parent screen. They’re coplanar, meaning they can be swiped around, and they live in an extensible, identifiable tab bar.

Tabs in action

Play Music, Google+, Play Newsstand


Tabs exist on one level together, inside the same parent screen. So navigating between tabs should not create history either for the system back button or for the app’s up button.

🍔 Nav drawers


The navigation drawer is generally a vertical pane attached to the left edge of the canvas. Drawers can manifest off-screen or on, persistent or not, but they always share some common characteristics.

Nav drawers in action

Play Store, Google Camera, Inbox


Nav drawers should generally create history for the system back button when the app has a distinct “Home” destination. In the Play Store, the home destination is the Apps & Games entry, which actually presents the user with tab navigation to see highlighted content of all types. So the Play Store creates history to get back to that destination from other areas of the app.

The “start driving” entry augments the primary map view

🚨 Bottom nav


On Android, the bottom nav component is comprised of between three and five primary destinations. Importantly, “more” is not a destination. Neither are menus nor dialogs.

Bottom nav in action

Google Photos

Additional considerations

If the bar is persistent across the entire app, the next logical consideration would be behavior when jumping between destinations using the bar. If the user is several layers deep in a hierarchy stemming from one destination and they switch to another destination and then switch back to the first, what should they see? The parent screen, or the child screen on which they left off?


Bottom nav shouldn’t create history for the system back button. Going deeper into hierarchies stemming from bottom nav destinations can create history for the system back button and the app’s up button, but the bottom bar can serve as its own sort of historical navigation as well.

🕹 In-context navigation


In-context navigation is comprised of any navigational interaction outside of the components described above. This includes things like buttons, tiles, cards, and anything else that takes the user elsewhere in an app.

In-context navigation in action

Clock, Google, and Google Calendar


There’s no hard rule for creating history via in-context navigation. Whether history is created relies entirely on what kind of in-context navigation the app uses and where the user is taken. In cases where it’s not clear exactly what kind of history should be created, it’s good to know what the up and back buttons do in general.

↖️ Up, back, and close buttons

  • Back is always present in the system nav bar. It navigates backward chronologically, irrespective of app hierarchy, even if the previous chronological screen was inside another app. It also dismisses temporary elements like dialogs, bottom sheets, and overlays.
  • Close is typically used to dismiss transient layers of the interface or discard changes in a full-screen dialog. Consider the event detail screen in Google Calendar (shown below). The temporary nature of the detail screen becomes even more clear on larger screens. In Inbox (below), the transition from inbox to message suggests the message is a layer on top of the inbox, so the close button is appropriate. Gmail (below) positions the message as a distinct level of the app and uses the up button.
Calendar, Inbox, and Gmail

🔄 Combining patterns

Throughout this primer we’ve seen examples of apps that successfully implement each of the various explicit navigation components. Many of these examples also succeed in combining navigation patterns to form a structure that makes sense for users. To wrap up, let’s review a couple of those examples with an eye toward mixing and matching.

Play Store
Google Calendar

🤔 Have more questions?

Navigation is a complex topic. Hopefully this primer provides a good foundation for understanding common navigation principles on Android. If you still have questions, leave a response or catch up on our first #AskMaterial session with the Material Design & Design Relations teams on Twitter here!

Google Design

Stories by Googlers on the people, product, and practice of UX at Google