@Gregman-js could you check here?
We are also currently making sure the frontend supports for edge to edge is extended to the rest of it home-assistant/frontend#25566

I think this PR should be changed to draft while the frontend is not yet ready to avoid merging it too early (in case the frontend changes don't make it in by 2025.6).

(...) since I have to enable edge to edge at the beginning of the activity [and on] API 36 (...) edge to edge [is enabled] by default so we have to handle it.

And the solution chosen to handle the insets on API 36 generally seems fine to me - adding 'normal'/empty space padding in case of a frontend that does not support it. Why not do the check again after the active server changed? Meaning we're always edge to edge and change the padding in our view as needed.

(...) since I have to enable edge to edge at the beginning of the activity [and on] API 36 (...) edge to edge [is enabled] by default so we have to handle it.

And the solution chosen to handle the insets on API 36 generally seems fine to me - adding 'normal'/empty space padding in case of a frontend that does not support it. Why not do the check again after the active server changed? Meaning we're always edge to edge and change the padding in our view as needed.

I initially wanted to do something by giving a lambda to the applyInsets function but then it becomes a bit more complicated with managing the nav bar and status bar coloring. We would need to also apply and remove coloring depending on the version of the server. I found it a bit too much for the value.
If you think it is important we can do it.

I initially wanted to do something by giving a lambda to the applyInsets function but then it becomes a bit more complicated with managing the nav bar and status bar coloring. We would need to also apply and remove coloring depending on the version of the server. I found it a bit too much for the value.

window.statusBarColor and window.navigationBarColor is already deprecated. Maybe it will be easier to replace it with top and bottom Spacer/Box. Then we can hide it to "enable edge to edge" for newer servers. And we can apply background color to this boxes without problem.

window.statusBarColor and window.navigationBarColor is already deprecated. Maybe it will be easier to replace it with top and bottom Spacer/Box. Then we can hide it to "enable edge to edge" for newer servers. And we can apply background color to this boxes without problem.

That could be nice, but may not be as easy on older API versions because of a scrim the system may try to force. Deprecated doesn't mean we should stopping it on older API versions if it works correctly and the behavior isn't the same on all API versions.

The deprecated API is disabled in API 36 so we have to migrate away from it unfortunately even for old version.
#5332

You don't have to migrate away if we can't make it work on older API versions. if (Build.VERSION.SDK_INT => Build.VERSION_CODES.BAKLAVA) { /* or what else the minimum is we can make work with edge to edge, new API */ } else { /* old API }

I've created POC in my repo and this approach hopefully solves all issues:
Gregman-js#1
I ve tested this in android 13,14,15,16 targeting api 36.

• Enable enableEdgeToEdge() for all
• changing active server supported (I think)
• Add <View> on top and bottom of <Webview> in xml
• Control above views height with InsetsUtil.kt

if (!serverHandleInsets) {
    statusBarBackground?.updateLayoutParams {
        height = safeInsets.top
    }
    navigationBarBackground?.updateLayoutParams {
        height = safeInsets.bottom
    }
} else {
// evaluateJavascript...
}

• Support new and old status bar apis
  Android >= 15 will use Views background color for servers that do not handle edge to edge
  Android < 15 will use Views background colors and statusBarColor on top for servers that do not handle edge to edge

if (statusBarColor != 0 && !serverHandleInsets) {
    window.statusBarColor = statusBarColor
    binding.statusBarBackground.setBackgroundColor(statusBarColor)
} else {
    Timber.e("Skipping coloring status bar...")
}
if (navigationBarColor != 0 && !serverHandleInsets) {
    window.navigationBarColor = navigationBarColor
    binding.navigationBarBackground.setBackgroundColor(navigationBarColor)
} else {
    Timber.e("Skipping coloring navigation bar...")
}

What do you think?

Could you make your PR to target my branch on the official repo? If your solution works I'm ok with it but we need to make it generic for the 3 places we have a webview

• AuthenticationFragment
• MyActivity
• WebViewActivity

Does that make sense to keep the call to the status bar color if it's deprecated if you provided an alternative solution.

Please remove the modification about the trailing , (I might make a big PR that adds all the , someday)

Okay, I will target your PR.
I kept status bar color because I wasn't able to test HA on older Androids (emulator, login page doesn't show) in context to @jpelgrom comment:

That could be nice, but may not be as easy on older API versions because of a scrim the system may try to force.

I can help if you want an old version of an emulator I did struggle with it too and I've found a workaround and posted it on stackoverflow https://stackoverflow.com/a/79514205/3289338 it helps you find a proper APK of the latest available webview for an old emulator.

I created PR here #5390 for use
I will try to test PR with your webview workaround