In March 2016, Google added Bottom Navigation to its design guidelines. This release was quite surprising to many, as Bottom Navigation hadn’t been mentioned in previous Material Design iterations. Bottom tab bars were common in iOS apps, while older Android guidance discouraged them. These were design recommendations, not platform limitations or a requirement for every iOS app.
This is the second article in a series on Android Bottom Navigation, covering style, behavior, and dimensions.
Version note (reviewed 2026-10-13): The main sections preserve 2016 Material Design 1 (M1) illustrations, not current Material 3 (M3) implementation requirements. Some values in the surviving M1 archive differ from the original images; those differences are identified below. Section 5 uses Compose Material3 1.3.0 as an explicit source reference, not an Android OS version.
See Part 1 for usage and window adaptation.
1. Style
1.1. Icons and Text
Use icons that communicate their destination. These are historical M1 label rules; “focused” here means the selected destination, not keyboard or accessibility focus:
- Show the icon and text label for the focused (active) item.
- If there are only three items, show icons and text labels for all items.
- If there are four or five items, show only the icon for inactive items.
1.2. Color
M1 recommended the primary color for the selected destination, as illustrated below. M3 uses theme color roles and an active indicator; this primary/black/white recipe is not its universal styling rule.
If the bottom navigation bar is colored, use black or white for the icons and text labels.
1.3. Text Labels
The M1 examples favor concise labels over confusing wrapping, truncation, or shrinking. Modern implementations must also accommodate translated labels, larger system fonts, and accessible names; do not shrink text merely to reproduce an old image.
2. Behavior
Read the M1 behavior advice within its scope:
- Each icon represents a top-level destination, not a menu or dialog command. The original translation’s ban on a “separate window” was broader than the source.
- Reselecting an item may return to its top or refresh, according to the product’s convention; the component does not perform that business logic automatically.
- The whole bar can be configured to hide or show during scrolling. Individual icons need not independently disappear, and scroll handling is not automatically wired up.
- M1 discouraged switching bottom-bar destinations by swiping content and recommended cross-fades. It did not prohibit carousels or other horizontal gestures within a destination.
- M1 also advised against cycling through bottom destinations with Back. Modern Back behavior must follow the actual navigation stack; do not simply intercept system Back or destroy the Android task on each switch. See Part 1 for Navigation 2.4.0 state restoration.
3. Dimensions
3.1. Fixed Bottom Navigation Bar
“Fixed” describes equal-width items, not an always-visible bar. Dividing available width by item count gives the entire item’s width, not the icon size; minimum and maximum constraints still apply on wider layouts.
Width constraints (including padding):
- Maximum: 168dp
- Minimum: 80dp in the surviving M1 archive. The original text gave 120dp/104dp for large/small layouts, and the retained image below explicitly says 104dp. These sources represent different revisions, not one combined specification.
Height: 56dp
Icon size: 24x24dp
Alignment: The icon sits above its label, horizontally centered; they are not a side-by-side pair.
Padding:
- 6dp above icon (active view), 8dp above icon (inactive view)
- 10dp below text label
- 12dp left and right of text label
Text Labels:
- Roboto Regular: 14sp (active view)
- Roboto Regular: 12sp (inactive view)
3.2. Shifting Bottom Navigation Bar
“Shifting” is the historical layout with different selected and unselected widths, not horizontal scrolling. The equal-width formula does not apply to every item here.
Width constraints (including padding):
Active Item:
- Maximum: 168dp
- Minimum: 96dp
Inactive Item:
- Maximum: 96dp
- Minimum: 64dp in the original image; the surviving M1 archive specifies 56dp. The image is retained as historical evidence.
Height: 56dp
Icon size: 24x24dp
Alignment: A selected icon sits above its label, horizontally centered. An icon-only inactive item is centered according to the old layout.
Padding:
- 6dp above icon (active view), 16dp above and below icon (inactive view)
- 10dp below text label
Text Labels:
- Roboto Regular: 14sp (active view)
4. Elevation and Hierarchy
M1 assigned conceptual elevations of 6dp to Snackbar and 8dp to bottom navigation. “Behind” describes layering, not a requirement to obscure the message: the image below keeps it readable above the bar. Modern placement cannot be inferred from those two numbers alone.
Drawers, modal sheets, and keyboards interact through their layouts, windows, and inset handling. The IME is a system window, not simply a higher-elevation View in the app, and does not invariably cover the entire navigation bar.
5. 2026 Update: Check the Component Version
The reference here is the Google Maven Compose Material3 1.3.0 source archive, specifically NavigationBar.kt, NavigationBarTokens.kt, and Scaffold.kt. These are versioned implementation details, not fixed values for every M3 implementation.
- Labels and width. With a label supplied,
NavigationBarItemdefaultsalwaysShowLabeltotrue; four or five items do not automatically hide inactive labels. Items receive equal weight. Historical shifting behavior is not this component’s default. - Size and color. Its ordinary
NavigationBaruses an 80dp container minimum-height token and a 24dp icon token. Constraints, content, and insets affect measured height; do not replace a hardcoded 56dp total with a hardcoded 80dp total. Default selected-icon, indicator, and label colors come fromonSecondaryContainer,secondaryContainer, andonSurface, respectively. - Insets. The bar handles bottom and horizontal system-bar insets by default, not the entire page or IME. Content must apply the
innerPaddingsupplied byScaffoldand consume insets appropriately, avoiding duplicate manual padding. See Material inset responsibilities and IME/inset handling. - Snackbar. In
Scaffold.snackbarHost, this version positions it using the actual bottomBar/FAB dimensions. Raising elevation to cover the bar is unnecessary. Custom layouts still need to keep messages and actions visible and reachable. - Accessibility. A 24dp icon is not a touch target. Check at least 48dp targets, meaningful names, selection state, font scaling, and RTL. Avoid duplicate announcements where a text label already supplies the name. See Compose accessibility defaults.
In-app navigation, system navigation, and the keyboard are separate surfaces with separate sizing and inset responsibilities.
About Me && Blog
Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”
- Blogger Intro
- Blog Content Navigation: A guide for my blog content.
- Curated Excellent Blog Articles - Android Performance Optimization Must-Knows
- Android Performance Optimization Knowledge Planet: The paid community stopped operating in 2026 and no longer accepts new members; this link preserves its history.
One walks faster alone, but a group walks further together.
