fix(android): keep SystemBars bottom inset on API < 30

CO
3d ago
+5-4

Description

On API < 30, SystemBars injects --safe-area-inset-bottom: 0px even though the navigation bar is visible, so content renders under the navigation bar.

injectSafeAreaCSS checked keyboard visibility with isVisible(ime()) on the insets rebuilt with WindowInsetsCompat.Builder. Below API 30, androidx guesses whether the IME is open from systemWindow.bottom > rootStable.bottom. Rebuilt insets carry no root window data, so root stable is 0 and any visible navigation bar counts as an open keyboard. The bottom inset is then forced to 0 (androidx issue 194911957).

This PR passes keyboardVisible from the listener's original insets into injectSafeAreaCSS. The listener already computes this value and uses it for padding.

Refs #8603

Testing

Tested on a Nokia 7.1 (Android 10 / API 29, WebView 151, setDecorFitsSystemWindows(false), viewport-fit=cover):

  • Before: --safe-area-inset-bottom: 0px with the navigation bar visible
  • After: --safe-area-inset-bottom: 48px, and 0px while the keyboard is open

API 30+ is unaffected, because there isVisible(ime()) uses the platform API, so the original and rebuilt insets give the same result.

Notes

  • env(safe-area-inset-bottom) still reads 0 on API < 30 with WebView 144+. The WebView has the same problem in AwDisplayCutoutController.onApplyWindowInsets, which Capacitor can't fix. On these devices, only the injected CSS variable is reliable.
  • The original report in #8603 (EdgeToEdge.enable(), so SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION) may have a second cause in how the listener reads insets. This PR doesn't cover that, so it uses "Refs" instead of "Fixes".