Return the "safe area" as "inner" region on Android?

[torokati44]

Would it make sense to implement inner_size and inner_position on Android to return the "safe area" of the screen?
That is, without any navigation or notification bars, not stretching onto the curved edges, within any rounded corners, and avoiding any camera holes or notches.

[rib]

One thing possibly worth considering about this is that for the purpose of creating surfaces for rendering (such as via wgpu) then it's currently generally assumed that the inner_size is the physical size of the native window. (e.g. Bevy and egui integration with winit assumes this). That means at the very least a replacement API would probably be needed to fulfill that need, and existing usage of inner_size would probably need to switch to the new API. (If this were changed without corresponding downstream changes then it would break how surfaces get created for rendering to the Android native window)

This sounds kinda fiddly really because the inner/outer size/position APIs in winit are trying to differentiate the bounds of window decorations which would seemingly be a good fit for mapping the inner position/size to the safe area on Android but then there wouldn't be a reliable API for querying the physical width of the window on Android.

Just looking at the iOS backend though it does look like they report the safe area via the inner_size + inner_position, which makes me wonder how downstream projects determine the physical size to render content on iOS... Poking through bevy and into wgpu it looks like they automatically create a CAMetaLayer based on the size of view which gets queried explicitly - and it looks like they just happen to ignore any incoming size, so it's maybe a bit of a fluke that the inner_size doesn't cause any trouble on iOS.

Overall it looks like the inner/outer bounds have quite varied behaviour across window systems which makes it hard to use them in any kind of portable way currently.

My gut feeling is that it's the 'outer_size' and 'outer_position' that is the bigger portability nightmare here, when you take into account desktop vs mobile and composited vs non-composited desktops and whether applications have client-side decorations vs system decorations - you get a complex matrix of what platforms can support here and what coordinate system they use.

Even though it would break downstream assumptions about inner == physical I wonder if it would be best to add an explicit 'physical_size' API that can have much clearer semantics for downstream to trust/rely on (with no concept of a physical position) and then inner_size and inner_position could be documented relative to the physical_size and it would seem clearer that the 'inner_size' would also reflect the safe area for the application to render within. A change like this would presumably only break things temporarily for Android. Android support isn't generally very good atm for a number of other reasons so this might not be a bad time to introduce a change like this.

Incidentally Bevy tracks surface sizes via a "physical_width" and "physical_height" which currently just come from winit's inner_size.

Maybe something else to consider here is that on Android there are multiple inset regions that can be queried (see https://developer.android.com/reference/androidx/core/view/WindowInsetsCompat.Type) and I wonder if it's important to be able to expose those other regions too - in case that would justify a different API? Since they are probably Android specific (except for the main safe area) I guess they should just be exposed via some separate Android-specific binding.

[rib]

One other thing that occurred to me here is that on Android we can actually get an event when the insets change - which may be relevent in situations where the status / system / navigation bars temporarily obscure a window. Right now Winit doesn't have an ideal way of notifying that the inner size has changed vs the physical size. There is the Resized event which technically passes along the inner_size but as discussed above, I think in practice this is interpreted by downstream more like a physical size currently.

[madsmtm]

This is tracked in #2308, and will be fixed by #3890, so I'll close this now.