persistentTopAppBarWindowInsets
Android implementation for the status-bar color spacer used by top app bars.
On Android API 35 and newer, the target-SDK edge-to-edge rules mean the content can extend into the status-bar region, so the spacer must consume WindowInsets.statusBars to paint and reserve that area. On older Android releases, the decor view commonly provides a content window that already starts below the status bar; applying statusBars there creates a duplicated top inset. The Pixel 3a XL/API 32 regression showed this as every screen toolbar being shifted down by exactly the status bar height. Returning zero before API 35 keeps legacy devices on their resized-window contract while preserving the required edge-to-edge spacing on newer devices.
Returns the top inset used only by the artificial status-bar color spacer above app bars.
This app paints a spacer before the actual screen toolbar so the status-bar area gets the same color as the top app bar. That spacer must follow the host window contract, not blindly apply WindowInsets.statusBars everywhere. On legacy Android windows the system already lays the app out below the status bar, so adding statusBars again pushes every top bar down by one status-bar height. On enforced edge-to-edge Android and on iOS, the app is responsible for reserving that area. Keeping this as a shared expect function makes the workaround visible at the boundary where the platform behavior diverges.
iOS implementation for the status-bar color spacer used by top app bars.
iOS keeps the expected safe-area behavior for the Compose host: the app bar background must extend through the status-bar area, and the layout must reserve that safe area so titles and controls do not collide with system indicators. The duplicated-top-inset bug was Android-specific and came from mixing a legacy resized content window with explicit Compose status-bar padding. Returning WindowInsets.statusBars here keeps the iOS behavior unchanged while documenting that the Android zero-inset branch is a compatibility workaround, not a cross-platform design decision.