Edge-to-Edge Android Apps: Fixing Content Hidden Under the Bars

You publish an app update, and a week later a customer sends a screenshot: the Pay button is half hidden behind the phone's navigation bar. Nothing in your code changed on that screen. What changed is the rule about how far an Android app must stretch across the display. This post explains the rule, why updating your app can trigger it, and how to fix it properly.

What edge-to-edge means

An Android phone has system bars: the status bar at the top (clock, battery, signal) and the navigation bar at the bottom (gesture line or three buttons). For years, most apps sat neatly between them. An edge-to-edge app instead draws its background across the entire screen, behind those bars, so there are no coloured stripes at the top and bottom. The content itself must then be moved so that it is not covered.

The space the system bars, camera cut-outs and gesture areas take up is measured and reported to the app as insets. Think of insets as the margin the phone tells your app to respect. An app that ignores them lets text and buttons slide under the bars.

What was enforced and when

Google's documentation states that edge-to-edge is enforced on Android 15 (API level 35) and higher once an app targets SDK 35. The target SDK is the Android version your developer declares the app was built for. On such a phone, the window draws behind the status bar, caption bar and navigation bar, and the status and gesture navigation bars are transparent by default. Google adds that if the app is not already edge-to-edge, portions of it may be obscured and the developer must handle insets.

The next step is in the Android 16 notes. For apps targeting Android 16 (API level 36), the older opt-out setting (windowOptOutEdgeToEdgeEnforcement) is deprecated and disabled, so the app can no longer switch edge-to-edge off. On an Android 15 phone, the opt-out still works even for an app that targets 36.

Google Play's help page says that from 31 August 2026, new apps and app updates must target Android 16 (API level 36) or higher, with an extension available until 1 November 2026. That date has now passed. In practice, any update you publish today has to deal with edge-to-edge, with no option to switch it off.

The bugs customers will see

These are the problems we look for first on any app that has just moved to the newer target:

• Hidden buttons. A floating action button, a Pay Now bar or a Save button sits under the navigation bar and is hard to tap.
• Last list item cut off. In an order list, invoice list or product list, the final row cannot be scrolled fully into view.
• Header under the clock. The screen title collides with the status bar and notification icons.
• Camera cut-out overlap. In landscape, content slides under the notch or punch-hole camera.
• Keyboard problems. A login or search field is covered when the keyboard opens, because the space for the keyboard is also an inset.
• Swipe conflicts. A swipeable card or carousel near the screen edge triggers the phone's back gesture instead.

How developers fix it

The fix is not to shrink everything by a fixed amount, because bars differ between phones and navigation modes. Google's guidance is to read the insets the system provides and apply them. In the older view system that means listening for window insets and adding padding or margins, plus setting clipToPadding to false on lists so rows can scroll behind the bars but come to rest above them. In Jetpack Compose, Google notes that the Material 3 Scaffold component can reduce the work needed for the Android 15 enforcement, and that WindowInsets.safeDrawing protects content that must not sit under any system UI.

Two further points from the documentation are worth knowing. Material components such as the bottom navigation bar and navigation rail handle insets automatically, but AppBarLayout does not and needs an extra setting. And full-screen dialogs need their own call to enable edge-to-edge.

A checklist to give your developer

1. List every screen that has a bottom button, a floating button, a bottom sheet or a long list.
2. Test each on a phone with gesture navigation and on one with three-button navigation.
3. Test in landscape and with the on-screen keyboard open.
4. Test on at least one Android 15 or newer phone and one older phone, because behaviour differs.
5. Check dark and light mode, so status bar icons stay readable.
6. Ask for screenshots of all of these before the update goes to the Play Store.

Where VS Tech Builders fits in

When we move a client app to a new target version, edge-to-edge is one of the first things we test, on real phones and emulators, before submission. If you want an older app brought up to the current rules, see our native Android app development service, or read what else changed in Android 16 for business apps. The related back-button change is covered in our predictive back guide, and the cost side in app maintenance in India.

Sources

Checked on 3 November 2026. Technology changes quickly; always confirm details with the official source before you act on them.

• Display content edge-to-edge in views | Views | Android Developers — Android Developers
• Behavior changes: Apps targeting Android 16 or higher | Android Developers — Android Developers
• About window insets | Jetpack Compose | Android Developers — Android Developers
• Target API level requirements for Google Play apps - Play Console Help — Google Play Console Help

Frequently asked questions

Why does my Android app look broken after an update?

Most likely the update raised the app's target version to Android 15 or 16. From then on, phones running those versions draw the app behind the status and navigation bars, and any screen that does not handle insets shows buttons or lists under them. The layout code needs to read the system's inset values and add padding.

Can I turn edge-to-edge off?

Only temporarily. For apps targeting Android 15 the opt-out setting exists. For apps targeting Android 16 (API 36), Google says the opt-out attribute is deprecated and disabled, though it still works on an Android 15 phone. Since Play now expects updates to target API 36, plan to fix the layouts rather than rely on an opt-out.

Does this affect old phones running Android 10 or 12?

Enforcement applies on Android 15 and higher. Older phones keep the previous behaviour unless the developer chooses to enable edge-to-edge for them using a compatibility call. Because your customers use many Android versions, the app should be tested on both newer and older phones before release.

How long does fixing edge-to-edge take?

For a small app with a handful of screens it is usually a matter of days, because the work is applying inset padding and re-testing. A large app with many custom layouts, bottom sheets and dialogs takes longer. Your developer can give a firm estimate after a one-day audit of the screens listed in the checklist.