Android 15, edge to edge, CoordinatorLayout & tabs -> Toolbar above status bar

by

Summary

The reported issue describes an edge-to-edge layout regression when an application targets newer Android API levels (specifically transitioning from Android 15 to 16/Android 15 with new defaults). The symptom is that the AppBarLayout is drawn entirely above the status bar, rather than respecting the system window insets.

This happens because targeting newer APIs enables edge-to-edge enforcement by default. The existing layout attempts to handle this using android:fitsSystemWindows="true" on the AppBarLayout, but this method is incompatible with the modern edge-to-edge WindowInsets API used in the Activity code (WindowCompat.setDecorFitsSystemWindows(window, false)). Consequently, the system insets are not applied to the AppBarLayout, causing it to draw from coordinate (0,0) of the screen.

Root Cause

The root cause is an API mismatch between the window configuration and the view hierarchy.

  • Activity Configuration: The code explicitly calls WindowCompat.setDecorFitsSystemWindows(window, false). This instructs the system to draw behind the status and navigation bars, adopting a modern edge-to-edge approach.
  • View Hierarchy Configuration: The XML layout uses the legacy android:fitsSystemWindows="true" attribute on the AppBarLayout.
  • The Conflict: In the modern Insets system (API 30+), fitsSystemWindows="true" is often ignored or behaves unpredictably when windowDecorFitsSystemWindows is set to false. The CoordinatorLayout and AppBarLayout do not automatically consume the WindowInsets in the legacy way, leaving the status bar area as valid drawing space for the app content.

Why This Happens in Real Systems

  • Strict Full-Screen Enforcement: Modern Android (Android 10/Q and later) pushes for “gestural navigation” and content-first experiences. As part of this, the system is much stricter about how apps handle insets. It no longer “buffers” the layout against the system bars automatically if the developer has opted into edge-to-edge.
  • Legacy vs. Modern Insets: fitsSystemWindows is a callback-based mechanism that older Views (like CoordinatorLayout) rely on. However, when edge-to-edge is active, the system expects the app to query WindowInsets and apply padding/margins manually. CoordinatorLayout does not automatically apply top padding to itself when fitsSystemWindows is present in an edge-to-edge context, leading to the collision described.

Real-World Impact

  • Visual Corruption: The Toolbar (and usually the TabLayout) is rendered behind the status bar icons (clock, battery, etc.), resulting in unreadable text and cluttered UI.
  • Interaction Issues: If the Toolbar has menus, the top items may be unreachable if the status bar area intercepts touch events, or the UI simply looks broken.
  • User Experience: The app appears unpolished and not updated for the latest Android versions, leading to negative user reviews.
  • Developer Friction: This is a common migration pain point when updating compileSdk and targetSdk, requiring refactoring of root layouts.

Example or Code

XML Layout Fix (activity_test.xml):

The fix requires removing the legacy attribute from the AppBarLayout and ensuring the MaterialToolbar handles the insets.

Kotlin Code Fix (TestActivity.kt):

You must apply WindowInsets to the AppBarLayout or CoordinatorLayout to push the content below the status bar.

class TestActivity : AppCompatActivity() {
    private lateinit var ui: ActivityTestBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // 1. Enable Edge-to-Edge
        WindowCompat.setDecorFitsSystemWindows(window, false)

        ui = ActivityTestBinding.inflate(layoutInflater)
        setContentView(ui.root)

        // 2. Apply WindowInsets to the AppBarLayout
        ViewCompat.setOnApplyWindowInsetsListener(ui.appBarLayout) { view, insets ->
            val statusBars = insets.getInsets(WindowInsetsCompat.Type.statusBars())
            // Apply padding to the AppBarLayout so it sits below the status bar
            view.updatePadding(top = statusBars.top)
            insets
        }

        // ... existing setup code ...
        setSupportActionBar(ui.toolBar)
        // ...
    }
}

How Senior Engineers Fix It

Senior engineers approach this by aligning the window configuration with the view hierarchy strategy. They rarely rely on fitsSystemWindows="true" in XML anymore.

  • Strategy: Adopt Manual Insets Handling.
  • Step 1: Ensure WindowCompat.setDecorFitsSystemWindows(window, false) is set. This is the source of truth.
  • Step 2: Identify the top-most container that needs to avoid the status bar (usually the CoordinatorLayout or AppBarLayout).
  • Step 3: Inject code (usually in onCreate or via a ViewTreeObserver listener) to query WindowInsetsCompat.Type.statusBars() and apply paddingTop or updateMargins to that view.
  • Step 4: If using CoordinatorLayout, ensure the AppBarLayout is the direct child and that the app:layout_behavior is correctly defined on the scrolling content.

Why Juniors Miss It

  • “It works on my device” Fallacy: Juniors often test on devices with the navigation bar set to “3-button” mode, where edge-to-edge issues are less visually aggressive than on “Gesture” mode devices.
  • XML vs. Code Mismatch: They often assume XML attributes like fitsSystemWindows are “magic” properties that work universally. They don’t realize that fitsSystemWindows is a contract that requires the parent/ancestor to invoke fitSystemWindows, which CoordinatorLayout does, but only if the window configuration allows it.
  • Ignorance of WindowInsets: Juniors may not be aware of the WindowInsetsCompat library. They stick to the older “System UI Flag” ways or XML attributes, which are deprecated or broken in Android 15/16 edge-to-edge environments.