Android system bars

Together, the status bar and the navigation bar are called the system bars. They display important information such as battery level, the time, and notification alerts, and provide direct device interaction from anywhere.

It's critical to take the prominence of system bars into account, whether you're designing UI for interactions with the Android OS, input methods, or other device capabilities. Keep system bars at the top of most layers to ensure they're accounted for.

Figure 1: Images behind system bars

Takeaways

  • Include system bars in your designs to account for UI safe zones, system interactions, input methods, display cutouts, and other device capabilities. Keep system bars at the topmost layer ensures they are accounted for.

  • Make system bars transparent and lay out your app in full screen, continuing the UI under the bars to give full edge-to-edge experience.

  • Avoid adding tap gestures or drag targets under gesture insets; these conflict with edge-to-edge and gesture navigation.

    Figure 2: System gesture insets. Avoid placing tap targets under these areas

Draw your content behind the system bars

The edge-to-edge feature allows Android to draw the UI under the system bars for a more immersive experience. We recommend using edge-to-edge because making the navigation bar transparent is a common request from users. (Read about how to support edge-to-edge).

An app can address overlaps in content by reacting to insets. Insets describe how much the content of your app needs to be padded to avoid overlapping with parts of the Android OS UI such as the navigation bar or status bar, or with physical device features such as display cutouts.

Be aware of the following types of insets when designing for edge-to-edge use cases:

  • System bars insets apply to UI that is both tappable and that shouldn't be visually obscured by the system bars.
  • System gesture insets apply to gesture-navigational areas used by the system that take priority over your app.

Status bar

On Android, the status bar contains notification icons and system icons. The user interacts with the status bar by pulling it down to access the notification shade.

Figure 3: Status bar region highlighted on top of top app bar

The status bar can appear differently depending on the context, time of day, user-set preferences or themes, and other parameters. You can also set the status bar style, as in the following examples.

Figure 4: Status bar in light and dark theme.

Ensure that your app content spans the entire screen now that edge-to-edge is required. Use transparent system bars with edge-to-edge content, as shown in the following example.

Figure 5: Transparent bars using the edge-to-edge feature, ideal for letting your content shine through using the most screen space.


Figure 6: Do style your system bars to enhance your content or match your app's branding. Don't leave the system bars set to the default attributes.

When a notification arrives, an icon usually appears in the status bar. This signals to the user that there's something to see in the notification drawer. This can be your app icon or symbol to represent the channel. See Notifications design.

Figure 7: Notification icon in the status bar

Set the status bar style

Style the status bar background as a part of your app theme, with a custom color or style, along with setting transparency and opacity.

<style name="Theme.MyApp">
  <item name="android:statusBarColor">
    @android:color/transparent
  </item>
</style>

If you're manually setting the background color, you can optionally style status bar contents as light or dark for optimal contrast.

Display cutouts and the status bar

A display cutout is an area on some devices that extends into the display surface to provide space for front-facing sensors. It can affect the appearance of status bars. Display cutouts can vary depending on the manufacturer.

Read about how to support display cutouts.

Figure 8: Examples of display cutouts

Android lets users control navigation using back, home, and overview controls:

  • Back returns directly back to the previous view.
  • Home transitions out of the app and to the device's home screen.
  • Overview shows the apps are open and have recently been opened.

Users can choose from various navigation bar configurations including gesture navigation (recommended) and three-button navigation.

Gesture navigation

Introduced in Android 10 (API level 29), gesture navigation is the recommended type of navigation, although you can't override the user's preference. Gesture navigation doesn't use buttons for back, home, and overview, instead showing a single gesture handle for affordance. Users interact by swiping from the left or right edge of the screen to go back and forward and up from the bottom to go home. Swiping up and holding opens the overview.

Gesture navigation is a more scalable navigation pattern for designing across mobile and larger screens. To provide the best user experience, account for gesture navigation by:

  • Supporting edge-to-edge content.
  • Avoid adding interactions or touch targets under gesture navigation insets.

Read about implementing gesture navigation.

Figure 9: Gesture handle navigation bar

Three-button navigation

Three-button navigation provides three buttons for back, home, and overview.

Figure 10: Three-button navigation bar

Other navigation bar variations

Depending on Android version and device other navigation bar configurations may be available to your users. Two-button navigation, for example, provides two buttons for home and back.

Figure 11: Two-button navigation bar

Set a navigation style

The following example shows how to implement a navigation style.

<style name="Theme.MyApp">
  <item name="android:navigationBarColor">
    @android:color/transparent
  </item>
</style>

Android handles all visual protection of the user interface in gesture navigation mode or in the button modes.

  • Gesture navigation mode: The system applies dynamic color adaptation, in which the contents of the system bars change color based on the content behind them. In the following example, the handle in the navigation bar changes to a dark color if it's placed above light content, and vice versa.

    Figure 12: Dynamic color adaptation
  • Button modes: The system applies a translucent scrim behind the system bars (for API level 29 or higher) or a transparent system bar (for API level 28 or lower).

    Figure 13: Dynamic color adaptation, where system bars change color based on the content behind them

Keyboard and navigation

Figure 14: On-screen keyboard with navigation bars

Each navigation type reacts appropriately to the on-screen keyboard to allow the user to perform actions such as dismissing or even changing the keyboard type. To ensure a smooth keyboard transition, To ensure a smooth transition that synchronizes the transition of the app with the keyboard sliding up and down from the bottom of the screen, use WindowInsetsAnimationCompat.

Immersive mode

Figure 15: Immersive mode showing a full-screen experience on a landscape-oriented mobile device

You can hide system bars when you need a full-screen experience, for example when the user is watching a movie. The user should still be able to tap to reveal system bars and UI in order to navigate or interact with system controls. Learn more about designing for full screen modes, or read about how to hide the system bars for immersive mode.