[Bug]: Android 15 enforces edge-to-edge

[JumBay]

Capacitor Version

Latest Dependencies:

@capacitor/cli: 6.2.0
@capacitor/core: 6.2.0
@capacitor/android: 6.2.0
@capacitor/ios: 6.2.0

Installed Dependencies:

@capacitor/cli: 6.2.0
@capacitor/core: 6.2.0
@capacitor/android: 6.2.0
@capacitor/ios: 6.2.0

[success] iOS looking great! 👌
[success] Android looking great! 👌

Other API Details

No response

Platforms Affected

• iOS
• Android
• Web

Current Behavior

In Android 15 the navigation bar overlaps the app. My users a reporting it wako-app/wako#121
This seems to be different to #6423, that's why I open a new issue.

Expected Behavior

The navigation bars shouldn't overlap

Project Reproduction

Additional Information

No response

[Geschan]

This plugin might help: https://github.com/capacitor-community/safe-area

[JumBay]

Yes I've seen it, but it should work without it

[JanPolasek]

This is the same issue as #6423, except on Android 13 edge to edge was opt-in while on Android 15 it becomes opt-out, but it is the same issue nonetheless. And since the only way to opt-out on Android 15 is getting immediately deprecated, there really should be a 1st party solution, otherwise capacitor will become quite literally unusable without using 3rd party plugins (or writing one yourself) once the opt-out is removed, and that's not a great place to be at.

To be honest this is actually something Google should fix. The way safe areas are supposed to be handled on web is via standard CSS env(safe-area-inset-*) values which are supported everywhere except for Android System WebView which still doesn't support them and simply reports all of the insets as 0px. Unfortunately given the activity this issue has seen in the chromium issue tracker and the general sorry state of the android webview I don't think we'll ever see it fixed there https://issues.chromium.org/issues/40699457.

One option to get it working for now is something like the aforementioned @capacitor-community/safe-area (though there are some issues with that one that I've opened a PR for, so I don't consider it a solution just yet, but it's close) which solves this by adding the insets via --safe-area-inset-* CSS variables since it cannot touch the env() variables.

Another, albeit temporary, alternative is to restore the previous behaviour with

<application
    android:windowOptOutEdgeToEdgeEnforcement="true"
    ...>
    ...
</application>

[danpercic86]

I have the same issue and nothing works for me, unable to update to capacitor 7 until official support for edge-to-edge is added

[ckoon-infopro]

Please let us know if there are any plans to address this in Capacitor. For now, we can either opt out or use @capacitor-community/safe-area. I have tested both options, and they both worked.

[MovingHead]

I have the same problem. With Capacitor 6 the setting <item name="android:windowOptOutEdgeToEdgeEnforcement">true</item> worked for me to fix the problem until Capacitor has a solution. But now I updated to Capacitor 7 and the setting is not working anymore. The app is not useable now on android...
This is a big problem.

[bohdanovdmytro]

same here

[pjamessteven]

I don't think this is something that Capacitor should fix since you have to deal with safe areas like these on iOS as well. I use the @aashu-dubey/capacitor-statusbar-safe-area plugin and this works fine with the below tweaks.

I think the focus should probably be on properly supporting safe area insets on Android in Capacitor so we don't need to use a plugin, and only applying the bottom safe area if the navigation bar is actually set to overlap the webview.

I have this in MainActivity.java. I think this is the most important part for getting the safe areas to work correctly (with a safe area plugin). Without this the layout is cooked.

@Override
  protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      Window window = getWindow();
      if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
        window.getDecorView().setSystemUiVisibility(View.SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION
                | View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
                | View.SYSTEM_UI_FLAG_LAYOUT_STABLE);
      }
  } 

With the above snippet 😍 (and using safe areas in my layout):

Without the above snippet 🤢 (bottom safe area is detected even though the nav bar isn't overlapping the webview):

I also have the following specified in my AndroidManifest.xml:

        <activity
            android:configChanges="orientation|keyboardHidden|keyboard|screenSize|locale|smallestScreenSize|screenLayout|uiMode"
            android:name=".MainActivity"
            android:label="@string/title_activity_main"
            android:theme="@style/AppTheme.NoActionBarLaunch"
            android:windowSoftInputMode="adjustResize"
            android:launchMode="singleTask"
            android:screenOrientation="unspecified"
            android:exported="true">

It seems that the android:windowSoftInputMode="adjustResize" property is important when it comes to getting the color of the nav buttons to automatically change depending on the background. It looks quite sexy because the bar is transparent but the button color is dynamic. If this is set for older API levels, the nav buttons will always have a black background.

Hope this info helps someone :)

[mla03]

@pjamessteven

In the addition to MainActivity, the "setSystemUiVisibility" is deprecated?
"This constant was deprecated in API level 30.
Use WindowInsetsController.hide(int) with Type.statusBars() instead."

[pjamessteven]

@mla03 you're right, I didn't notice that. I don't spend enough time in Android Studio!

I updated my code with this method for newer API levels and it has the same effect.

    if (Build.VERSION.SDK_INT >= 30) {
        window.setDecorFitsSystemWindows(false);
    } else {
        window.getDecorView().setSystemUiVisibility(View.SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION
                | View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
                | View.SYSTEM_UI_FLAG_LAYOUT_STABLE);
    }

[mla03]

@pjamessteven great. I've tried it, together with the capacitor-community/safe-area.

I set the margins of the footer and header in my global.scss:
`ion-header {
margin-top: var(--safe-area-inset-top, 0px);
}

ion-footer {
margin-bottom: var(--safe-area-inset-bottom, 0px);
}`

Still not perfect. Below screenshot from my Google Pixel 7.

I still think that it's something for Ionic/Capacitor to fix, since reading the documentation for their ion-footer/ion-header states:
"When a toolbar is used inside of a footer/header, the content will be adjusted so it is sized correctly, and the footer/header will account for any device safe areas."
https://ionicframework.com/docs/api/header
https://ionicframework.com/docs/api/footer

[pjamessteven]

Like with the navigation bar, you also need to set the menu bar to overlay the web view when using safe areas. I can’t remember how I achieved this, on mobile right now.

…

On Tue, 4 Feb 2025 at 7:47 PM, mla03 ***@***.***> wrote: @pjamessteven <https://github.com/pjamessteven> great. I've tried it, together with the capacitor-community/safe-area. I set the margins of the footer and header in my global.scss: `ion-header { margin-top: var(--safe-area-inset-top, 0px); } ion-footer { margin-bottom: var(--safe-area-inset-bottom, 0px); }` Still not perfect. image.png (view on web) <https://github.com/user-attachments/assets/c9ae75e3-68a1-49f9-91c3-261bcf0dada4> I still think that it's something for Ionic/Capacitor to fix, since reading the documentation for their ion-footer/ion-header states: "*When a toolbar is used inside of a footer/header, the content will be adjusted so it is sized correctly, and the footer/header will account for any device safe areas.*" https://ionicframework.com/docs/api/header https://ionicframework.com/docs/api/footer — Reply to this email directly, view it on GitHub <#7804 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AES7C2CEHZHG4O4SAVKQSGT2OBPBBAVCNFSM6AAAAABTUTPZOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMZTGAZDANJUHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>