Header under the clock
Your sticky header starts at the very top of the screen, so the status bar icons sit on your logo and menu button.
What changed in Android 15 and Android 16
For apps that target Android 15 (API level 35), Android 15 displays the app edge-to-edge by default. The status bar and the gesture navigation bar become transparent, and the system no longer pushes your content below them; with three-button navigation the bar is translucent. Unless the app applies the window insets, part of its content sits underneath the system bars. The traditional way to color the status bar, setStatusBarColor, is deprecated and has no effect on Android 15 for these apps.
Android 15 still offered a temporary opt-out through a theme attribute. For apps targeting Android 16 (API level 36), that opt-out is deprecated and disabled on Android 16 devices. Google Play requires new apps and updates to target API level 36, so a new upload has no opt-out left: the app has to handle insets.
What Play Console shows
Edge-to-edge problems do not come as a classic policy rejection. They show up as recommendations on the release dashboard, with titles such as "Edge-to-edge may not display for all users" and "Your app uses deprecated APIs or parameters for edge-to-edge". The second one lists calls such as Window.setStatusBarColor or setNavigationBarColor and the classes they start in, which are often libraries rather than your own code.
The real risk is what people see: a menu icon under the clock that cannot be tapped, or a checkout button behind the gesture bar. A reviewer can treat that as broken functionality, and users will certainly mention it in reviews. The broken functionality guide covers the other launch-day problems of wrapped apps.
Symptoms in a web-wrapped app
Tab bar behind the gesture handle
A navigation bar with position: fixed; bottom: 0 ends up under the gesture pill or the three-button bar, and taps hit the system bar instead.
Invisible status bar icons
With a transparent bar, white icons on a white page, or black icons on a dark one, disappear.
Double padding
The native shell and your CSS both add space for the bars, which leaves a thick empty band at the top or the bottom.
Keyboard covering inputs
Fields near the bottom of a form slip under the keyboard when the layout ignores the visual viewport.
My iOS WebView is finally approved. Thanks!!
Pick one owner for the insets
| Setup | WebViewGold Android settings | Your CSS |
|---|---|---|
| Native shell keeps the page below the bars (recommended for most apps) | TRANSPARENT_STATUS_BAR false: an opaque status bar in the colorPrimaryDark color from style.xml; blackStatusBarText for dark icons on a light color | Nothing required. Keep the safe-area CSS below as a safety net; when the shell already keeps the page clear of the bars it should add no extra space. Confirm once on a device. |
| Page draws behind the status bar (true full screen) | TRANSPARENT_STATUS_BAR true | viewport-fit=cover in the viewport meta tag, env(safe-area-inset-top) padding on the header and the bottom inset on fixed bottom bars |
| Native bottom navigation | ENABLE_NAVIGATION_FOOTER true, entries in res/menu/menu_drawer.xml | Hide your own fixed tab bar inside the app so the two do not stack |
| Immersive screens (video, games, kiosk) | hidebars://on and hidebars://off from JavaScript | The bars come back with a swipe from the edge; keep important controls away from the edges |
Edge-to-edge-safe CSS for your web app
First add viewport-fit=cover to the viewport meta tag: <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">. Then pad fixed elements with the safe-area insets. The same CSS works in the iOS app; the guideline 4.0 safe-area guide covers the iOS settings.
css
:root {
--inset-top: env(safe-area-inset-top, 0px);
--inset-bottom: env(safe-area-inset-bottom, 0px);
--inset-left: env(safe-area-inset-left, 0px);
--inset-right: env(safe-area-inset-right, 0px);
}
/* Sticky header: content starts below the status bar */
.app-header {
position: sticky;
top: 0;
padding-top: calc(12px + var(--inset-top));
padding-left: calc(16px + var(--inset-left));
padding-right: calc(16px + var(--inset-right));
}
/* Fixed tab bar: stays above the gesture handle or the button bar */
.tab-bar {
position: fixed;
left: 0;
right: 0;
bottom: 0;
padding-bottom: calc(8px + var(--inset-bottom));
}
/* Room for the tab bar, and dynamic viewport units instead of 100vh */
main {
min-height: 100dvh;
padding-bottom: calc(72px + var(--inset-bottom));
}Fix it step by step
About an hour, most of it testing on two emulators.
Update the template instead of raising targetSdk
Older WebViewGold projects targeted an API level below 35 and never had to deal with edge-to-edge. Raising the number by hand skips the code that goes with it. The current template includes the Android 15 status bar work (changelog version 16.4 onward) and later status bar refinements; carry your settings over as described in the target API level guide, or rebuild in the Cloud Builder.
Decide who owns the insets
For most vibe-coded apps the native setup is the safest:
TRANSPARENT_STATUS_BARfalse and your brand color ascolorPrimaryDark. Choose the transparent setup only if your design needs content behind the status bar, and then handle the insets in CSS consistently.Set colors and icon contrast
Set
blackStatusBarTextto match your color. If the color changes per page (dark mode, a colored hero), switch it from JavaScript withstatusbarcolor://R,G,Bandstatusbartextcolor://whiteorstatusbartextcolor://black;bottombarcolor://andnavbartextcolor://do the same for the Android navigation bar. See the Dynamic UI API.Add the CSS, app-only if you prefer
Put the safe-area CSS into your web app, or into the project's custom.css if it should apply only inside the app. Replace
100vhwith100dvhfor full-height screens.Test the matrix
Android 15 and Android 16 emulators, each once with gesture navigation and once with three-button navigation; one device profile with a display cutout; landscape, where
HIDE_NAVIGATION_BAR_IN_LANDSCAPEcan help; and a form with the keyboard open. On each, check the header, the bottom bar and the first and last list item.Upload and re-check the dashboard
Upload with a higher version code. A recommendation about deprecated APIs that points into a library can remain; what matters is that nothing in your interface sits under a system bar.
Prompt: make your web app edge-to-edge safe
The prompt keeps the desktop layout untouched and only adds the insets.
Paste into Lovable, Bolt, Cursor or Claude Code
My web app also runs inside native Android and iOS apps (WebViewGold). Android 15 and later draw apps edge-to-edge, so fixed elements can end up under the status bar and the navigation bar. Please update the layout: 1. Add viewport-fit=cover to the existing viewport meta tag and keep its other values. 2. Define CSS variables for env(safe-area-inset-top), env(safe-area-inset-bottom), env(safe-area-inset-left) and env(safe-area-inset-right), each with a 0px fallback. 3. Add the top inset to the padding of the sticky or fixed header, and the bottom inset to the padding of every fixed bottom bar, floating action button and cookie banner. 4. Add matching bottom padding to the main content so the last item is not hidden behind the bottom bar. 5. Replace 100vh with 100dvh for full-height layouts. 6. Do not change colors, spacing or behavior in a normal desktop browser. List every file and selector you changed.
Edge-to-edge checklist
- Built from the current WebViewGold template, not an old project with a raised targetSdk.
- One owner for the insets: native (opaque status bar) or CSS (transparent status bar), never both.
- Status bar icons readable on every page, in light and dark mode.
- Header and bottom bar clear of the system bars with gesture and three-button navigation.
viewport-fit=coverplusenv(safe-area-inset-*)padding on fixed elements.- Tested on Android 15 and 16, in portrait and landscape, with the keyboard open.
Frequently asked questions
Can I still opt out of edge-to-edge on Android?
Not for a new upload. The opt-out attribute worked for apps targeting API level 35; for apps targeting API level 36 it is disabled on Android 16 devices, and Google Play now requires API level 36 for new apps and updates.
Why are my status bar icons invisible?
The bar has the same color as the icons, usually because it is transparent over a light or dark header. Set blackStatusBarText to match your status bar color, or switch it per page with statusbartextcolor://white or statusbartextcolor://black.
Does Android edge-to-edge affect my iOS app?
No, but iOS has safe areas of its own. WebViewGold for iOS handles them by default with autoAdjustSafeAreaInsets, and the CSS on this page works in both apps.
Play Console says I use setStatusBarColor, but I never wrote that. Why?
The recommendation lists calls found anywhere in the bundle, including libraries such as Material components. It is a recommendation, not a rejection. Keep the template and its SDKs current and make sure your interface is not covered by the system bars.
My tablet layout changed after the update. Is that related?
Partly. For apps targeting Android 16, Android ignores orientation and resizability restrictions on large screens (smallest width of 600 dp or more), so a portrait lock in TABLET_ORIENTATION may no longer apply there. Make sure your web app has a usable tablet and landscape layout.
Three ways to get your app into the stores
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
Do it yourself
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main pageCloud Builder
$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demoFull Service
$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.