Anyone had issues with the top window insets when ...

# compose-android

[Mark]

Anyone had issues with the top window insets when using Floating Windows in MIUI? A user informed me that my app is top-cropped through the app bar (where there is a search box, so this has a functional impact). Unfortunately, I don’t have an MIUI to test with. My app is edge-to-edge and works in normal full screens and split screens.

[Mark]

Looks like it’s the captionBarPadding . So I should just add captionBarPadding alongside wherever I have statusBarPadding?

[Alex Vanyo]

Do you have a screenshot for what the UI looks like for reference?

Yes, your app should be handling captionBarPadding as well, which is a type of inset for the title bar in free-form windows.

captionBarPadding is included in systemBarsPadding (along well as statusBar and navigationBars) and safeDrawingPadding so you could also switch to a more general inset type to handle these cases.

[Mark]

I think the issue is that I’m applying the padding directly to the TopBar so I only want statusBar and captionBar to be taken into consideration because I only want the top padding to be taken into consideration. Is there a cleaner way to do this?

TopAppBar(
    modifier = modifier,
    windowInsets = WindowInsets.statusBars.add(WindowInsets.captionBar),

Here’s the screenshot without the WindowInsets.captionBar added. I don’t know for sure if the above solves the problem, but I guess it does.

[Tolriq]

You need to also take in account displayCutout for the camera that can be bigger than the statusBar height too.

[Alex Vanyo]

You can use .only(<http://WindowInsetsSides.Top|WindowInsetsSides.Top>) to only apply a certain side of insets - that should be a more flexible solution than assuming that certain insets are only applied on certain sides, I don't think that's necessarily guaranteed

[Alex Vanyo]

WindowInsets.safeDrawing.only(<http://WindowInsetsSides.Top|WindowInsetsSides.Top>) will also include the display cutout as @Tolriq mentioned

[Tolriq]

BTW @Alex Vanyo Do you have some input about https://issuetracker.google.com/issues/346852665 ? The other one vanished and did not provide an actual solution that is future proof.

[Alex Vanyo]

There are some additional APIs that need to be added for the more specific display cutout information beyond the inset values, like the path and bounding rect. The technical problem with pulling them from the View directly is that there isn't a direct signal to hook into when it changes - internal to Compose that's handled with a insets listener that updates snapshot state

[Alex Vanyo]

Before they're added to Compose, I think your best bet would be to add your own insets listener (on a different View than the Compose one, since there can only be one inset listener per View), and update a piece of snapshot state with the value you need

[Tolriq]

Hum thanks, but then I can just launch effect on the inset change on the direction I'm interested? It should do the same, as if the value does not change it means there's no cutout change in that direction no?

[Mark]

Thanks very much for all this. When I use

windowInsets = WindowInsets.safeDrawing.only(WindowInsetsSides.Top)

on the TopAppBar I notice (on the emulator - Pixel 6, API31) the camera cutout still appears within the TopAppBar bounds. It’s actually a good thing because I have quite a bit of top padding and so it just eats into that, which is not a problem. Is this intentional? Is there something that allows WindowInsets to creep into such padding? Otherwise, wouldn’t you expect there to be extra space above the hamburger icon vs. below it.

[Tolriq]

It's. Broken on the emulator, you see the image but it's not actual cutout inset you need to enable them on dev settings on API 33 min.

[Mark]

I see thanks. Are there some good real-world examples of devices where the cutout goes beyond the status bar? I’m trying to work out how much extra top blank space I might potentially get.