Statusbar overlays complete app when setting `StatusBarOverlaysWebView` to `false` on Android 7/8 using `cordova-plugin-statusbar`

[GitToTheHub]

Bug Report

Problem

When using the plugin cordova-plugin-statusbar and setting StatusBarOverlaysWebView to false in config.xml:

<preference name="StatusBarOverlaysWebView" value="false" />

the complete app is covered by the statusbar:

Android 7.1.1 emulator

This does not happen on Android 9 and newer.

What is expected to happen?

Setting StatusBarOverlaysWebView to false should just display the statusbar and the web view after.

What does actually happen?

The statusbar covers the whole app.

Information

This was tested in a Hello World app with adding the lastest master of cordova-android.

Command or Code

Environment, Platform, Device

Version information

Checklist

• I searched for existing GitHub issues
• I updated all Cordova tooling to most recent version
• I included all the necessary information above

[cyril23]

We hit the same bug on a real device (Samsung Galaxy S7, Android 8.0.0 / API 26, WebView Chrome 138) with cordova-android 15.1.0 + cordova-plugin-statusbar 4.0.0 and StatusBarOverlaysWebView=false, and traced it through the sources. Root cause, evidence, a config-only workaround and a fix (#2009) below.

What is on screen

adb shell dumpsys activity top while the app shows only the solid StatusBarBackgroundColor:

android.widget.LinearLayout{f007cd2 V.E...... ........ 0,0-1080,1920}                 <- decor content root (screen_simple.xml), padded 72 px by fitsSystemWindows
  android.widget.FrameLayout{7099ca0 V.E...... ........ 0,72-1080,1920}
    androidx.appcompat.widget.FitWindowsLinearLayout{90a059 … 0,0-1080,1848 app:id/action_bar_root}
      androidx.appcompat.widget.ContentFrameLayout{9f564ff … 0,0-1080,1848 android:id/content}
        android.widget.FrameLayout{e7be2cc V.E...... ........ 0,0-1080,1848}          <- Cordova rootLayout
          org.apache.cordova.engine.SystemWebView{fa1e915 VFEDH.C.. .F...... 0,0-1080,1848}
          android.view.View{832d42a V.ED..... ........ 0,0-1080,1848}                 <- statusBarView: MATCH_PARENT x MATCH_PARENT, on top of the WebView

The WebView is fine (JS runs, Displayed is logged); it is just covered by the core's statusBarView, which SystemBarPlugin paints in StatusBarBackgroundColor. Without that preference the view is painted in BackgroundColor or the UI-mode color (cdv_background_color) instead: the same build without the preference shows a plain #FAF8FF screen below a black status bar (measured from screencap) — i.e. the bug then presents as a "white screen after the splash screen", which is probably how it gets reported most of the time.

with StatusBarBackgroundColor=#2A95D2	without StatusBarBackgroundColor

Why

1. CordovaActivity.createViews() creates statusBarView without LayoutParams and only sizes it inside rootLayout's OnApplyWindowInsetsListener. rootLayout.addView(statusBarView) therefore starts it with FrameLayout's default MATCH_PARENT x MATCH_PARENT. As long as the listener runs at least once, that default is never visible — but if it never runs, the view covers the WebView and SystemBarPlugin paints it in the status-bar color.

2. The listener never runs on API < 30 once SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN is cleared. createViews() calls WindowCompat.setDecorFitsSystemWindows(window, false); on API < 30 (WindowCompat.Api16Impl) that can only be emulated by setting SYSTEM_UI_FLAG_LAYOUT_STABLE | LAYOUT_HIDE_NAVIGATION | LAYOUT_FULLSCREEN on the decor view. The decor's content root (screen_simple.xml, fitsSystemWindows="true", flagged "optional" by PhoneWindow.generateLayout → makeOptionalFitsSystemWindows; appcompat's sub-decor is flagged the same way) then decides in View.computeSystemWindowInsets():

   • API < 30: an optional fitsSystemWindows view consumes the insets (pads itself) unless mAttachInfo.mSystemUiVisibility & SYSTEM_UI_LAYOUT_FLAGS != 0, where SYSTEM_UI_LAYOUT_FLAGS = LAYOUT_HIDE_NAVIGATION | LAYOUT_FULLSCREEN (LAYOUT_STABLE is not part of it). That is the 72 px padding in the dump above. ViewGroup.dispatchApplyWindowInsets then only continues to the children while !insets.isConsumed():
     • API 21–27: isConsumed() is systemWindow && windowDecor && stable consumed → true → nothing below the content root (appcompat's sub-decor, Cordova's rootLayout) is ever called.
     • API 28–29: isConsumed() additionally requires mDisplayCutoutConsumed, which is only true when the WindowInsets were built without a DisplayCutout object, and DecorView never consumes the cutout → the dispatch continues with zeroed system-window insets, Cordova's listener runs with top = 0 and sizes the view to 0 px. The app works, but only by accident: the WebView is not inset by Cordova at all but by the decor's padding, and statusBarView is never used.
   • API 30+: Window.setDecorFitsSystemWindows(false) sets ViewRootImpl.mContentOnApplyWindowInsetsListener = null, and with that the optional views return the insets untouched regardless of the system-UI flags. The listener runs, the view is sized, everything works — which is why the bug looks like an "old Android" problem.

3. Who clears LAYOUT_FULLSCREEN: cordova-plugin-statusbar 4.0.0 still ships an Android implementation. Its initialize() runs synchronously during onCreate (runOnUiThread executes inline on the UI thread, i.e. before the first inset pass) and for StatusBarOverlaysWebView=false calls setStatusBarTransparent(false), which replaces the decor's system-UI visibility with LAYOUT_STABLE | VISIBLE. StatusBarOverlaysWebView=true sets LAYOUT_STABLE | LAYOUT_FULLSCREEN instead, which is why the default preference works. (The plugin's StatusBar.show() clears the flag at runtime as well.)

So the trigger is any code that clears LAYOUT_FULLSCREEN on an API 21–27 device (Android 5.0–8.1), and the hazard is the core's unparameterized statusBarView. That matches your observation (7 and 8 broken, 9+ fine); the S7 (API 26) is a real-device confirmation.

Verified with the same unpatched app (cordova-android 15.1.0, statusbar 4.0.0, StatusBarOverlaysWebView=false) on x86_64 Google APIs emulators, dumpsys activity top below the decor content root:

	decor content root	SystemWebView	statusBarView	result
Galaxy S7, API 26	padded 72 px	0,0-1080,1848	0,0-1080,1848 (MATCH_PARENT)	covered
emulator API 28	padded 96 px	0,0-1440,2464	0,0-1440,0	OK (by accident, see above)
emulator API 29	padded 96 px	0,0-1440,2464	0,0-1440,0	OK (by accident)
emulator API 30	not padded	0,96-1440,2560	0,0-1440,96	OK (as designed)

Workaround (config only)

Confirmed on the S7 with an unpatched cordova-android 15.1.0 (no core change): adding

<platform name="android">
	<preference name="StatusBarOverlaysWebView" value="true" />
</platform>

keeps LAYOUT_FULLSCREEN set, the decor passes the insets through and the core sizes its status-bar view normally — the S7 then even gets the as-designed layout (SystemWebView 0,72-1080,1920, statusBarView 0,0-1080,72), app rendered, status bar in StatusBarBackgroundColor; Samsung XCover 5 (Android 14) and Pixel 6a (Android 17) unchanged. Removing cordova-plugin-statusbar altogether gives the identical result on the S7 (same hierarchy, core alone) — so the plugin's Android side is the trigger, the core's MATCH_PARENT default is the hazard.

Fix

Give statusBarView initial params FrameLayout.LayoutParams(MATCH_PARENT, 0, Gravity.TOP) in createViews(): when insets arrive the listener resizes it exactly as today; when they never arrive it stays 0 px high instead of covering the WebView. Verified on the S7 (statusBarView 0,0-1080,0, app visible, system status bar as expected) with no change on Samsung XCover 5 (Android 14) and Pixel 6a (Android 17). PR: #2009 — we verified the change as an after_prepare hook patching CordovaLib.

before (top of the screen)	after

A second, independent improvement would be for cordova-plugin-statusbar's setStatusBarTransparent() to mask the layout bits instead of overwriting the whole visibility value, so it stops clobbering the core's setDecorFitsSystemWindows(false) emulation on API < 30 (on 28/29 that clobbering is harmless only thanks to the cutout quirk above).