insetsController Is null Before setContentView

Conclusion

window.insetsController returns null before setContentView() is called. The DecorView is not resolved yet. Written null-safely, it does not crash either — instead the immersive hide() never runs and the code finishes as if nothing had happened.

Symptom

A signage device needed one Activity permanently in fullscreen. Its onCreate() looked like this.

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

    window.addFlags(
        WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON or
            WindowManager.LayoutParams.FLAG_FULLSCREEN or
            WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED
    )

    // Fullscreen immersive
    enterImmersiveMode()

    val root = FrameLayout(this).apply { setBackgroundColor(Color.BLACK) }
    // ... addView a WebView and others to root ...

    setContentView(root)
    // ...
}

enterImmersiveMode() is called before setContentView(root). It builds, and it does not crash at runtime. But on the device, the status bar and navigation bar do not go away.

Cause

Here is what enterImmersiveMode() did on the Android 11 / API 30 and later branch.

private fun enterImmersiveMode() {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
        window.setDecorFitsSystemWindows(false)
        window.insetsController?.let {
            it.hide(android.view.WindowInsets.Type.systemBars())
            it.systemBarsBehavior =
                android.view.WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE
        }
    } else {
        // ...
    }
}

window.insetsController is only available once the DecorView is resolved. The DecorView is resolved when setContentView() runs, so accessing insetsController before that returns null.

The trap is that the call is written null-safely as ?.let { ... }. When it is null, the whole block — including it.hide(...) — is skipped without an exception and without a log line. “Called but had no effect” never shows up as a crash, so nothing surfaces until someone looks at the screen.

The fix

Move the enterImmersiveMode() call after setContentView(root).

setContentView(root)

// Immersive mode must come after setContentView: insetsController is only
// valid once the DecorView is resolved.
enterImmersiveMode()

That alone fixes it, but the insetsController calls were also wrapped in try-catch so that a null or an exception does not stop the rest of the initialisation.

private fun enterImmersiveMode() {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
        try {
            window.setDecorFitsSystemWindows(false)
        } catch (_: Throwable) {}
        window.insetsController?.let {
            try {
                it.hide(android.view.WindowInsets.Type.systemBars())
                it.systemBarsBehavior =
                    android.view.WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE
            } catch (_: Throwable) {}
        }
    } else {
        // ...
    }
}

Preventing a repeat

Fixing the order alone means the same trap waits for whoever next adds initialisation before setContentView(). Both setDecorFitsSystemWindows and the insetsController calls are now wrapped in try-catch, so that even with the order wrong, only immersive mode fails and the rest of startup continues.

A null-safe ?.let blurs the difference between “does not crash” and “works as intended”. When calling an API that depends on the DecorView, the safe-either-way form has to go in at the same time.