Android: DisplayEdgeToEdgePreference still triggers Play Console's deprecated edge-to-edge API advisory

[Duracell1989]

Description

Setting IInsetsManager.DisplayEdgeToEdgePreference = true on Android does not clear Google Play Console's "Your app uses deprecated APIs or parameters for edge-to-edge" advisory, because AndroidInsetsManager.UpdateDisplayEdgeToEgdeState() calls the legacy WindowCompat.SetDecorFitsSystemWindows(...) API unconditionally (regardless of the preference value):

https://github.com/AvaloniaUI/Avalonia/blob/master/src/Android/Avalonia.Android/Platform/AndroidInsetsManager.cs

WindowCompat.setDecorFitsSystemWindows is itself an AndroidX compat shim that dispatches to per-SDK-level EdgeToEdgeApi21/23/26/29/35 impl classes, and those are what Play Console's static bytecode analysis flags as calling the deprecated Window.setStatusBarColor/setNavigationBarColor. This is flagged regardless of runtime SDK branching elsewhere in the file (e.g. the existing if (!OperatingSystem.IsAndroidVersionAtLeast(35)) guard around SystemBarColor's own direct calls) because Play's analysis traces reachable bytecode, not executed branches.

Play Console's own advisory text suggests the fix: "call enableEdgeToEdge() for Kotlin or EdgeToEdge.enable() for Java for backward compatibility" — i.e. migrate off WindowCompat.SetDecorFitsSystemWindows onto the modern androidx.activity.EdgeToEdge / WindowCompat.EnableEdgeToEdge helper.

.NET MAUI hit the identical advisory and is fixing it the same way: migrating MauiAppCompatActivity.OnCreate from SetDecorFitsSystemWindows(Window, false) to WindowCompat.EnableEdgeToEdge(Window) — see dotnet/maui#36226 (open, targets .NET 11).

To Reproduce

1. Create an Avalonia Android app targeting API 35 (targetSdkVersion 35 / SupportedOSPlatformVersion high enough to trigger Android 15 edge-to-edge enforcement).
2. Set TopLevel.InsetsManager.DisplayEdgeToEdgePreference = true somewhere in the view lifecycle (e.g. OnAttachedToVisualTree).
3. Build a release AAB and upload it to Google Play Console.
4. Under "Release > (your track) > Pre-launch report" or "For your next release", the advisory "Edge-to-edge may not display for all users" / "Your app uses deprecated APIs or parameters for edge-to-edge" is present, naming androidx.activity.EdgeToEdgeApi35.setUp as the origin.

Expected behavior

Enabling DisplayEdgeToEdgePreference (or Avalonia's Android edge-to-edge support generally) should route through AndroidX's modern EdgeToEdge.enable()/WindowCompat.EnableEdgeToEdge API rather than the legacy WindowCompat.SetDecorFitsSystemWindows, so apps don't carry a reachable deprecated-API call purely from using Avalonia's own insets plumbing.

Environment

• Avalonia 12.1.1
• net10.0-android, SupportedOSPlatformVersion 23, targeting SDK 35
• Reproduced on a real shipped app (Google Play Console, release 0.4.1)

[emmauss]

Issue with using the new API is it doesn't allow users to disable edge to edge on devices using android 14 and below. i.e. once you call it, you can't revert. This will break our current behavior of allowing users to disable edge to edge on supported OS.

[Duracell1989]

Retracting this. I got the root cause wrong, and having gone back to the AndroidX sources, the change I asked for would have made things worse rather than better. Details below in case they are useful to anyone who finds this later.

1. WindowCompat.setDecorFitsSystemWindows does not reach the EdgeToEdgeApi* impls.

That was the central claim in the issue body and it is simply false. Those impl classes belong to androidx.activity.EdgeToEdge, a separate API. WindowCompat.setDecorFitsSystemWindows only touches View.setSystemUiVisibility (Api16Impl) and Window.setDecorFitsSystemWindows (Api30Impl). It sets no bar colours on any API level, so it cannot be what Play Console flagged.

2. The suggested replacement calls the deprecated setters unconditionally.

WindowCompat.enableEdgeToEdge(Window):

setDecorFitsSystemWindows(window, false);
window.setStatusBarColor(Color.TRANSPARENT);
window.setNavigationBarColor(Color.TRANSPARENT);

No API-level guard. The same is true of every androidx.activity.EdgeToEdgeApi23/26/29/30/35.setUp. Migrating Avalonia onto it would introduce two unguarded deprecated calls where there are currently none, and would not clear the advisory.

Relevant to the MAUI precedent I cited: androidx.activity.EdgeToEdge.enable() is itself now deprecated in favour of WindowCompat.enableEdgeToEdge, which is what dotnet/maui#36226 migrates to. It carries the same two calls.

3. The flagged class is dead code in my own build, not something Avalonia calls.

Avalonia never references androidx.activity.EdgeToEdge anywhere. My app project set neither AndroidEnableProguard nor AndroidLinkTool, and .NET for Android leaves AndroidLinkTool empty unless AndroidEnableProguard=True (Xamarin.Android.Common.targets), so no R8 shrinking runs and every class in every AndroidX AAR ships. androidx.activity.EdgeToEdgeApi35 was in the AAB purely because nothing removed it.

Also structural, and the part I should have thought about first: Avalonia's own Window.SetStatusBarColor calls are managed C# reaching Java over JNI at runtime. There is no DEX call site, so Play's static bytecode analysis cannot see them regardless of what Avalonia does. Only bundled Java/Kotlin AAR code is visible to it. That makes this class of advisory an app build-configuration matter rather than something a .NET UI framework can influence.

@emmauss your objection stands on its own merits, and I would not want the revert behaviour traded away either, but it turns out to be moot here since the migration would not have bought anything. Apologies for the noise, and thanks for taking the time to look.

One small thing I noticed while reading AndroidInsetsManager, happy to file separately if it is worth having: when _isDisplayEdgeToEdgeForced is true (targetSdk >= 35 on an API 35+ device), UpdateDisplayEdgeToEgdeState returns before doing anything, so setting DisplayEdgeToEdgePreference is a silent no-op on exactly those devices. Defensible given the platform enforces edge-to-edge there, but not obvious from the API surface.

Closing.