Android 15 edge-to-edge: fix screens before content hides behind system bars

Android 15 changes how an app’s window meets the edges of the screen. For apps targeting Android 15 (API level 35) or higher, edge-to-edge display is the default on Android 15 devices. That means content can extend behind the status bar, navigation area, and display cutout. If a screen was laid out assuming those areas would always be reserved, a button, heading, or list row may end up underneath system UI.

Inspect actual screens and keep important content readable and usable. Do not add padding everywhere: backgrounds can reach the screen edges while foreground content respects insets. Identify elements that need protection, apply the right handling for your UI stack, and test supported navigation modes.

First check the target and the deviceCopy Anchor Link

Start by confirming the app’s target SDK and the Android versions in your release test matrix. The behavior change described here applies when the app targets Android 15 (API 35) or higher and runs on a device running Android 15. A project that targets a later API level still meets that condition. The change is about what the window does by default; it does not mean every screen will break.

Keep target SDK planning separate from layout testing. Google Play’s target API requirements concern release planning; edge-to-edge is a visual and interaction check. If reviewing both, pair this checklist with our Google Play target API deadline guide. Passing a target API review does not prove that content is positioned correctly.

Before changing code, capture the current target SDK value and identify how Android screens are implemented in your project. A native Android app, a React Native app, and an app built with another framework may expose window and inset behavior through different layers. Follow the documentation for the framework and libraries actually in use. Avoid copying a native fix into a cross-platform project without confirming where it belongs.

Look for overlap, not just a changed colorCopy Anchor Link

A screen may look mostly normal while a control becomes hard to reach. Review appearance and interaction.

On Android 15, the status bar is transparent by default and the top offset is disabled, so app content can draw behind it unless insets are applied. With gesture navigation, the navigation bar is transparent by default and the bottom offset is disabled. Three-button navigation has its own default appearance, and content can also draw behind that area unless insets are handled. A display cutout can expose another unsafe area near the top edge.

Check the parts of the interface most likely to collide with those boundaries:

• Screen titles, back buttons, and top app bars near the status bar.
• Bottom navigation, primary actions, and sheets near the navigation area.
• Floating buttons or important list actions close to a corner.
• Long lists whose final item or scroll controls sit behind system UI.
• Full-screen media, maps, camera previews, and custom-drawn surfaces.
• Screens with a display cutout or a landscape layout.

The goal is not to keep every background away from the edges. A photo or color field can extend behind a system bar while text and controls remain in a safe position. Check contrast and legibility when the bar is transparent, too; a pale status icon over a pale image may be difficult to see even if the layout has enough room.

Audit complete journeys and overlooked screensCopy Anchor Link

Do not stop at the first screen. Android calls out onboarding, sign-in, and settings as less-visited routes that may contain obscured UI. Also check states reached after an action: an open sheet, empty or error state, confirmation view, and keyboard.

Make a short inventory of important routes and mark where each screen places content close to the top, bottom, or cutout. Include at least one screen with a scrollable area and one with a persistent action. Then follow a real journey through the app rather than opening screens in isolation. For example, sign in, open a detail view, trigger its primary action, dismiss the resulting sheet, and navigate back. This reveals cases where inset handling changes between screens or containers.

For each route, record what is obscured, whether the user can still operate the control, and which component owns the layout. A screenshot is useful evidence, but it should be paired with a tap or scroll check. If the bottom action is visible but cannot receive a tap, the layout is still broken. If a list can scroll its final row fully above the navigation area, that is a different result from a row permanently covered by it.

Apply insets at the right layerCopy Anchor Link

The correct implementation depends on your UI stack. Android says Material 3 Compose bars are likely to handle insets automatically. Material 2 Compose components do not do so in the same way; the guide describes applying inset parameters manually for supported library versions. Many views-based Material Components handle insets, while AppBarLayout needs attention. Custom Compose content and view containers may need explicit inset padding.

Use these examples to investigate, not as a blanket patch list. Find the component owning the content, then check its official docs and your versions. Padding at both parent and child can create a double gap; padding on the wrong container can move a background that should remain full-bleed.

Pay attention to scroll containers. A list can appear correct at the top but hide its last item near the bottom. Conversely, adding a fixed bottom margin may leave a large dead zone when system bar dimensions change. Prefer the framework’s inset-aware layout tools and test the content at both ends of the scroll range.

If your app already draws edge-to-edge and applies insets, still test it. Android’s guidance notes that lower-traffic screens can contain occluded UI even when the main flow is prepared. It also highlights display cutout configuration for non-floating windows and possible splash-screen issues. If your app has a custom splash screen or unusual window configuration, inspect that path rather than assuming the main activity’s layout fix covers it.

Test navigation modes and real screen statesCopy Anchor Link

A single emulator setup is not enough to catch every boundary issue. Test with gesture navigation and three-button navigation because Android 15 gives them different system-bar defaults. Include a device profile with a cutout if your supported devices include one. Check both light and dark content where relevant, and test the app’s own themes or backgrounds behind transparent bars.

Use a repeatable pass for each important route:

1. Open the screen from a clean app launch.
2. Check the first visible control near the status bar.
3. Scroll to the bottom and confirm the final content and action remain usable.
4. Open sheets, dialogs, menus, and the keyboard if the route uses them.
5. Switch navigation mode and repeat the checks most likely to change.
6. Capture before-and-after evidence for any change.

Test the release build as well as a development build when possible. Layout wrappers, navigation libraries, and native configuration can differ across build paths. If a failure appears only in one build, keep that distinction in the bug report; it can point to a configuration or dependency path rather than a screen-level design error.

Keep the repair small and verifiableCopy Anchor Link

When you find overlap, record the route, device configuration, and owning component before editing. Make one focused change, then revisit the journey to avoid broad padding that shifts every screen.

After the repair, verify three outcomes: important content is no longer under system UI, backgrounds still reach the edge where intended, and controls remain reachable with each tested navigation mode. Recheck scrolling and the screen states that were part of the original failure. If you change a shared shell, also spot-check screens that depend on it but were not part of the first reproduction.

A useful release note for your team is concrete: which screen was covered, which component was adjusted, which device/navigation configuration reproduced it, and what passed after the change. “Looks good on my phone” does not tell the next person which condition was tested. A compact test record gives reviewers a way to reproduce the result and makes the next target SDK update easier to inspect.

A practical release checklistCopy Anchor Link

Before you ship a build targeting Android 15 or higher, answer these questions:

• Have you confirmed the target SDK and the Android 15 test device?
• Did you check status bar, navigation area, and display cutout boundaries?
• Did you test gesture and three-button navigation?
• Did you inspect onboarding, sign-in, settings, and other lower-traffic routes?
• Can users reach the last list item and bottom actions?
• Did you verify sheets, keyboard states, and custom surfaces used in the affected flow?
• Does the fix use the inset approach documented for the actual framework and component versions?
• Did you recheck backgrounds, contrast, and touch targets after the change?

If any answer is unknown, capture the unanswered case and test it before calling the UI ready. The Android 15 change is predictable once the app’s target and window behavior are understood; the screen-by-screen work is what reveals whether your own layouts are prepared.

SourcesCopy Anchor Link

• Behavior changes: Apps targeting Android 15 or higher — Android Developers