White stripes as statusbar and navigation bar on android

[markdevocht]

Fix: status bar background missing on API 35+ with edge-to-edge

On API 35+, EdgeToEdge.enable() no longer creates the android.R.id.statusBarBackground view in the DecorView. setupStatusBarBackground relied on finding this view to apply status bar colors — when it was null, setStatusBarColor fell back to the deprecated window.statusBarColor API, which is silently ignored on API 35+. This caused the status bar area to appear white/transparent regardless of the color set by the app.
The fix adds a fallback in setupStatusBarBackground: when the system view is not found, a manual view is created in android.R.id.content, positioned at Gravity.TOP and sized dynamically via WindowInsetsCompat.Type.statusBars() insets. This mirrors the existing approach used by setupNavigationBarBackground, which already creates its own view unconditionally.

Reproduction

Any app using activateEdgeToEdge() on an API 35+ device in dark mode — the status bar stays white instead of adopting the app's color. Visible as white stripes at the top of the screen.

https://wix.atlassian.net/browse/WOAINFRA-3301

[yedidyak]

I found one regression risk in the new API 35+ fallback path.

applyThemeStatusBarColor() is meant to seed the manual status-bar background with the activity’s initial/theme color, but right now it always forces Color.TRANSPARENT:

private void applyThemeStatusBarColor() {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.VANILLA_ICE_CREAM
            && SystemUiUtils.needsManualStatusBarBackground()) {
        //noinspection deprecation
        getWindow().setStatusBarColor(android.graphics.Color.TRANSPARENT);
        SystemUiUtils.setStatusBarColor(getWindow(), android.graphics.Color.TRANSPARENT);
    }
}

That fixes the white-stripe case in dark mode, but it also regresses apps that intentionally start with a non-transparent themed status bar. On API 35+ they will now briefly show the splash/content through the status bar until JS/options repaint it.

Suggested fix: preserve the existing/theme color instead of hardcoding transparent.

Minimal version:

private void applyThemeStatusBarColor() {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.VANILLA_ICE_CREAM
            && SystemUiUtils.needsManualStatusBarBackground()) {
        //noinspection deprecation
        int initialStatusBarColor = getWindow().getStatusBarColor();
        SystemUiUtils.setStatusBarColor(getWindow(), initialStatusBarColor);
    }
}

Even better: resolve android.R.attr.statusBarColor from the theme first, then fall back to getWindow().getStatusBarColor() if the theme does not define it.

I’d also recommend adding a regression test for the manual-view path so we cover:

• opaque themed status bar color is preserved
• transparent themed status bar stays transparent
• the fallback view is used instead of silently depending on the deprecated window API

[markdevocht]

@yedidyak We implemented this initially. getWindow().getStatusBarColor() returns the theme's inherited default, which for Theme.MaterialComponents.Light.NoActionBar.Bridge is #ff757575 — grey. That's the grey you kept seeing. The manual view was being created and painted grey, then StatusBarPresenter would override it with the screen's actual color a moment later, but the grey was visible in between.

That's why we switched to Color.TRANSPARENT — it lets the app's content show through the status bar area, so it naturally matches whatever is behind it (white in light mode, dark in dark mode). No flash of an arbitrary theme color.

The concern about "apps that intentionally start with a non-transparent themed status bar" is valid in theory, but in practice the theme's statusBarColor is almost never the app's intended color — it's just whatever the parent Material theme provides. Using TRANSPARENT is the safer default because it's invisible and the actual screen color takes over once StatusBarPresenter runs.