Android system bars

Together, the status bar, caption bar, and 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.

Figure 1: Images behind system bars

Takeaways

  • Include system bars when designing your app. Account for UI safe zones, system interactions, input methods, display cutouts, status bars, caption bars, navigation bars, and other device capabilities.

  • Keep the system status and navigation bars transparent or translucent and draw content behind these bars to go edge-to-edge.

  • 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 an immersive experience, which is a common request from users.

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 status bar, caption bar, navigation bar; or with physical device features such as display cutouts. Read about how to support edge-to-edge and handle insets in Compose and views.

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.
  • Display cutout insets apply to device areas that extend into the display surface, like the camera cutout.

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

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

Figure 4: Status bar icons in light and dark theme.

Ensure that your app content spans the entire screen. Keep status and navigation bars transparent or translucent with edge-to-edge content as shown in the following example.

Figure 5: An edge-to-edge app with transparent system bars is ideal for letting your content shine through using the most screen space.

Edge-to-edge is enforced on Android 15 so that the system bars are transparent or translucent by default. On earlier versions of Android, don't leave the system bars opaque.

Figure 6: Do go edge-to-edge to enhance your content. Don't have opaque system bars.

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

Ensure the status bar is transparent on all versions by calling enableEdgeToEdge(). Ensure to update the status bar icon colors for contrast. For example, to create dark icons:

WindowCompat.getInsetsController(window, window.decorView)
    .isAppearanceLightStatusBars = false

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. To deliver the best experience, account for multiple types of 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 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 8: Gesture handle navigation bar

Three-button navigation

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

Figure 9: 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 10: Two-button navigation bar

Set a navigation style

Ensure the navigation bar is transparent or translucent on all versions by calling enableEdgeToEdge().

On Android 15 and later devices, or after calling enableEdgeToEdge(), gesture navigation is transparent by default. Three-button navigation is translucent by default or opaque if it is inside the taskbar on large screen device.

If your app has a bottom app bar, set Window.setNavigationBarContrastEnforced() to false to ensure the bottom app bar can draw underneath the system's navigation bar without having a translucent scrim applied in three-button navigation.

Android handles visual protection of the user interface in gesture navigation mode and 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 11: Dynamic color adaptation

Button modes: The system applies a translucent scrim behind button navigation bars, which can be removed by setting Window.setNavigationBarContrastEnforced() to false.

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

Keyboard and navigation

Figure 13: 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.

Display cutouts

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

Figure 14: Examples of display cutouts

Display cutouts can affect the appearance of your UI. When targeting Android 15 (API level 35) or higher, apps draw into the display cutout region by default. Apps must handle display cutout insets so that important UI does not draw underneath the display cutout. Read about how to support display cutouts.

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.