アプリでコンテンツをエッジ ツー エッジで表示し、Compose でウィンドウ インセットを処理する

Android プラットフォームは、ステータスバーやナビゲーション バーなどのシステム UI を描画する役割を担います。このシステム UI は、ユーザーが使用しているアプリに関係なく表示されます。

WindowInsets は、アプリが正しい領域に描画され、UI がシステム UI で隠れないように、システム UI に関する情報を提供します。

Android 14（API レベル 34）以前では、アプリの UI はデフォルトでシステムバーとディスプレイ カットアウトの下に描画されません。

Android 15（API レベル 35）以降では、アプリが SDK 35 をターゲットとすると、アプリはシステム バーの下に描画され、切り欠きが表示されます。これにより、よりシームレスなユーザー エクスペリエンスが実現し、アプリは利用可能なウィンドウ領域を最大限に活用できます。

システム UI の背後にコンテンツを表示することを、エッジ ツー エッジと呼びます。このページでは、さまざまな種類のインセット、エッジツーエッジにする方法、インセット API を使用して UI をアニメーション化し、アプリのコンテンツがシステム UI 要素に隠れないようにする方法について説明します。

インセットの基本

アプリがエッジ ツー エッジ表示になる場合は、重要なコンテンツや操作がシステム UI で隠れないようにする必要があります。たとえば、ボタンがナビゲーション バーの背後に配置されている場合、ユーザーがクリックできない可能性があります。

システム UI のサイズと配置場所に関する情報は、インセットで指定します。

システム UI の各部分には、サイズと配置場所を表す対応するタイプのインセットがあります。たとえば、ステータスバーのインセットはステータスバーのサイズと位置を指定しますが、ナビゲーション バーのインセットはナビゲーション バーのサイズと位置を指定します。各タイプのインセットは、上、左、右、下の 4 つのピクセル寸法で構成されます。これらのディメンションでは、システム UI がアプリのウィンドウの対応する側からどの程度延びるかを指定します。そのため、このようなシステム UI と重ならないように、アプリ UI をその分だけ内側に配置する必要があります。

これらの Android の組み込みインセットタイプは、WindowInsets で使用できます。

これらのタイプは、コンテンツが隠れないようにする 3 つの「安全な」インセット タイプにまとめられます。

• WindowInsets.safeDrawing
• WindowInsets.safeGestures
• WindowInsets.safeContent

これらの「安全な」インセット タイプは、基盤となるプラットフォームのインセットに基づいて、さまざまな方法でコンテンツを保護します。

• システム UI の下に描画されないコンテンツを保護するには、WindowInsets.safeDrawing を使用します。これは、システム UI によって隠されているコンテンツ（部分的または完全に）の描画を防ぐために、インセットを使用する最も一般的な方法です。
• WindowInsets.safeGestures を使用して、ジェスチャーでコンテンツを保護します。これにより、システム ジェスチャーがアプリのジェスチャー（ボトムシート、カルーセル、ゲームなど）と競合するのを防ぐことができます。
• WindowInsets.safeDrawing と WindowInsets.safeGestures の組み合わせとして WindowInsets.safeContent を使用して、コンテンツの視覚的な重複やジェスチャーの重複がないようにします。

インセットの設定

アプリでコンテンツの描画位置を完全に制御できるようにするには、次の設定手順を行います。これらの手順を実施しないと、アプリがシステム UI の背後に黒色または単色を描画したり、ソフトウェア キーボードと同期してアニメーション化されなかったりする可能性があります。

1. Android 15 以降でエッジツーエッジを適用するには、ターゲット SDK 35 以降にする必要があります。アプリはシステム UI の背後に表示されます。インセットを処理することで、アプリの UI を調整できます。
2. 必要に応じて、Activity.onCreate() で enableEdgeToEdge() を呼び出します。これにより、以前の Android バージョンでアプリをエッジ ツー エッジにできます。

3. アクティビティの AndroidManifest.xml エントリに android:windowSoftInputMode="adjustResize" を設定します。この設定により、アプリはソフトウェア IME のサイズをインセットとして受け取ることができます。これにより、アプリで IME が表示されたり消えたりしても、コンテンツを適切にパディングしてレイアウトできます。

   <!-- in your AndroidManifest.xml file: -->
   <activity
     android:name=".ui.MainActivity"
     android:label="@string/app_name"
     android:windowSoftInputMode="adjustResize"
     android:theme="@style/Theme.MyApplication"
     android:exported="true">
   

Compose API

アクティビティがすべてのインセットの処理を制御できるようになったら、Compose API を使用して、コンテンツが隠れないようにし、操作可能な要素がシステム UI と重ならないようにします。また、これらの API は、アプリのレイアウトをインセットの変更と同期します。

たとえば、アプリ全体のコンテンツにインセットを適用する最も基本的な方法は次のとおりです。

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

    enableEdgeToEdge()

    setContent {
        Box(Modifier.safeDrawingPadding()) {
            // the rest of the app
        }
    }
}
InsetsSnippets.kt

このスニペットは、safeDrawing ウィンドウ インセットをアプリのコンテンツ全体の周囲にパディングとして適用します。これにより、操作可能な要素がシステム UI と重複することがなくなりますが、アプリのいずれもシステム UI の背後に描画されなくなるため、エッジツーエッジ効果が実現されます。ウィンドウ全体を最大限に活用するには、画面ごとに、またはコンポーネントごとに、インセットを適用する場所を微調整する必要があります。

これらのインセット タイプはすべて、IME アニメーションが API 21 にバックポートされ、自動的にアニメーション化されます。これらのインセットを使用するすべてのレイアウトも、インセット値が変更されると自動的にアニメーション化されます。

これらのインセット タイプを使用してコンポーザブル レイアウトを調整するには、パディング修飾子とインセット サイズ修飾子の 2 つの主な方法があります。

パディング修飾子

Modifier.windowInsetsPadding(windowInsets: WindowInsets) は、Modifier.padding と同様に、指定されたウィンドウ インセットをパディングとして適用します。たとえば、Modifier.windowInsetsPadding(WindowInsets.safeDrawing) は、安全な描画インセットを 4 つの側面すべてにパディングとして適用します。

最も一般的なインセット タイプ用の組み込みユーティリティ メソッドもいくつかあります。Modifier.safeDrawingPadding() はそのようなメソッドの 1 つで、Modifier.windowInsetsPadding(WindowInsets.safeDrawing) と同等です。他のインセット タイプにも同様の修飾子があります。

インセット サイズの修飾子

次の修飾子は、コンポーネントのサイズをインセットのサイズに設定することで、ウィンドウの切り欠きの量を適用します。

これらの修飾子は、インセットのスペースを占有する Spacer のサイズ設定に特に便利です。

LazyColumn(
    Modifier.imePadding()
) {
    // Other content
    item {
        Spacer(
            Modifier.windowInsetsBottomHeight(
                WindowInsets.systemBars
            )
        )
    }
}
InsetsSnippets.kt

インセットの使用量

インセット パディング修飾子（windowInsetsPadding と safeDrawingPadding などのヘルパー）は、パディングとして適用されるインセットの部分を自動的に消費します。コンポジション ツリーのさらに深いレベルまで進むと、ネストされたインセット パディング修飾子とインセット サイズ修飾子は、インセットの一部が外側インセット パディング修飾子によってすでに消費されていることを認識します。インセットの同じ部分を複数回使用すると余分なスペースが過剰になることを避けられます。

インセットサイズ修飾子を使用すると、インセットがすでに使用されている場合でも、インセットの同じ部分を複数回使用することがなくなります。ただし、サイズを直接変更するため、インセット自体は消費しません。

そのため、ネストされたパディング修飾子により、各コンポーザブルに適用されるパディングの量が自動的に変更されます。

前と同じ LazyColumn の例を見てみましょう。LazyColumn は imePadding 修飾子によってサイズ変更されています。LazyColumn 内では、最後のアイテムのサイズはシステムバーの底部の高さに設定されます。

LazyColumn(
    Modifier.imePadding()
) {
    // Other content
    item {
        Spacer(
            Modifier.windowInsetsBottomHeight(
                WindowInsets.systemBars
            )
        )
    }
}
InsetsSnippets.kt

IME が閉じている場合、IME には高さがないため、imePadding() 修飾子はパディングを適用しません。imePadding() 修飾子ではパディングが適用されないため、インセットは使用されず、Spacer の高さはシステムバーの下側のサイズになります。

IME が開くと、IME インセットが IME のサイズに合わせてアニメーション表示され、imePadding() 修飾子が下部パディングの適用を開始し、IME が開くと LazyColumn のサイズを変更します。imePadding() 修飾子が下部パディングの適用を開始すると、その量のインセットも消費され始めます。そのため、システムバーの間隔の一部として imePadding() 修飾子によってすでに適用されているので、Spacer の高さが減少し始めます。imePadding() 修飾子によってシステムバーよりも大きな下部パディングが適用されると、Spacer の高さは 0 になります。

IME が閉じると、変更は逆になります。imePadding() がシステムバーの下側よりも小さく適用されると、Spacer は高さがゼロから拡大し始め、IME が完全にアニメーション化されると、Spacer はシステムバーの下側の高さに一致します。

この動作は、すべての windowInsetsPadding 修飾子間の通信によって実現され、他のいくつかの方法で影響を受けます。

Modifier.consumeWindowInsets(insets: WindowInsets) も Modifier.windowInsetsPadding と同じようにインセットを使用しますが、消費されたインセットをパディングとして適用しません。これはインセット サイズ修飾子と組み合わせて、一定量のインセットがすでに使用されていることを兄弟に示す場合に便利です。

Column(Modifier.verticalScroll(rememberScrollState())) {
    Spacer(Modifier.windowInsetsTopHeight(WindowInsets.systemBars))

    Column(
        Modifier.consumeWindowInsets(
            WindowInsets.systemBars.only(WindowInsetsSides.Vertical)
        )
    ) {
        // content
        Spacer(Modifier.windowInsetsBottomHeight(WindowInsets.ime))
    }

    Spacer(Modifier.windowInsetsBottomHeight(WindowInsets.systemBars))
}
InsetsSnippets.kt

Modifier.consumeWindowInsets(paddingValues: PaddingValues) は WindowInsets 引数のあるバージョンとよく似た動作をしますが、任意の PaddingValues を使用します。これは、通常の Modifier.padding や固定高のスペーサーなど、インセット パディング修飾子以外のメカニズムによってパディングまたは間隔が提供されている場合に、子に通知する場合に便利です。

Column(Modifier.padding(16.dp).consumeWindowInsets(PaddingValues(16.dp))) {
    // content
    Spacer(Modifier.windowInsetsBottomHeight(WindowInsets.ime))
}
InsetsSnippets.kt

未加工のウィンドウ インセットが消費なしで必要な場合は、WindowInsets 値を直接使用するか、WindowInsets.asPaddingValues() を使用して、消費の影響を受けないインセットの PaddingValues を返します。ただし、以下の注意事項があるため、可能であれば、ウィンドウ インセットのパディング修飾子とウィンドウ インセットのサイズ修飾子を使用することをおすすめします。

インセットと Jetpack Compose のフェーズ

Compose は、基盤となる AndroidX コア API を使用してインセットを更新し、アニメーション化します。このインセットは、インセットを管理する基盤となるプラットフォーム API を使用します。このようなプラットフォームの動作により、インセットは Jetpack Compose のフェーズと特別な関係があります。

インセットの値は、コンポジション フェーズの後、レイアウト フェーズの前に更新されます。つまり、コンポジションでインセットの値を読み取る場合、通常は 1 フレーム遅れたインセットの値が使用されます。このページで説明する組み込み修飾子は、インセットの値の使用をレイアウト フェーズまで遅らせるように構築されています。これにより、インセット値が更新されたフレームと同じフレームで使用されるようになります。

WindowInsets によるキーボード IME アニメーション

スクロール コンテナに Modifier.imeNestedScroll() を適用すると、コンテナの下部までスクロールしたときに IME を自動的に開閉できます。

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

        WindowCompat.setDecorFitsSystemWindows(window, false)

        setContent {
            MaterialTheme {
                MyScreen()
            }
        }
    }
}

@OptIn(ExperimentalLayoutApi::class)
@Composable
fun MyScreen() {
    Box {
        LazyColumn(
            modifier = Modifier
                .fillMaxSize() // fill the entire window
                .imePadding() // padding for the bottom for the IME
                .imeNestedScroll(), // scroll IME at the bottom
            content = { }
        )
        FloatingActionButton(
            modifier = Modifier
                .align(Alignment.BottomEnd)
                .padding(16.dp) // normal 16dp of padding for FABs
                .navigationBarsPadding() // padding for navigation bar
                .imePadding(), // padding for when IME appears
            onClick = { }
        ) {
            Icon(imageVector = Icons.Filled.Add, contentDescription = "Add")
        }
    }
}
MigrationOtherConsiderationsSnippets.kt

マテリアル 3 コンポーネントの切り抜きサポート

使いやすさを考慮して、組み込みのマテリアル 3 コンポーザブル（androidx.compose.material3）の多くは、マテリアル仕様に従ってコンポーザブルがアプリに配置される方法に基づいて、インセット自体を処理します。

インセット処理コンポーザブル

以下に、インセットを自動的に処理するマテリアル コンポーネントの一覧を示します。

アプリバー

• TopAppBar / SmallTopAppBar / CenterAlignedTopAppBar / MediumTopAppBar / LargeTopAppBar: システムバーはウィンドウの上部に使用されるため、システムバーの上部と横をパディングとして適用します。
• BottomAppBar: システムバーの下部と水平側をパディングとして適用します。

コンテンツ コンテナ

• ModalDrawerSheet / DismissibleDrawerSheet / PermanentDrawerSheet（モーダル ナビゲーション ドロワー内のコンテンツ）: コンテンツに垂直方向と開始方向のインセットを適用します。
• ModalBottomSheet: 下インセットを適用します。
• NavigationBar : 下と横の切れ込みを適用します。
• NavigationRail: 縦インセットと開始インセットを適用します。

Scaffold

デフォルトでは、Scaffold はパラメータ paddingValues としてインセットを提供し、使用できるようにします。Scaffold はコンテンツにインセットを適用しません。この責任はユーザーにあります。たとえば、Scaffold 内の LazyColumn でこれらのインセットを使用するには、次のようにします。

Scaffold { innerPadding ->
    // innerPadding contains inset information for you to use and apply
    LazyColumn(
        // consume insets as scaffold doesn't do it by default
        modifier = Modifier.consumeWindowInsets(innerPadding),
        contentPadding = innerPadding
    ) {
        items(count = 100) {
            Box(
                Modifier
                    .fillMaxWidth()
                    .height(50.dp)
                    .background(colors[it % colors.size])
            )
        }
    }
}
InsetsSnippets.kt

デフォルトのインセットをオーバーライドする

コンポーザブルに渡される windowInsets パラメータを変更して、コンポーザブルの動作を構成できます。このパラメータは、代わりに適用する別のタイプのウィンドウ インセットにすることも、空のインスタンス（WindowInsets(0, 0, 0, 0)）を渡して無効にすることもできます。

たとえば、LargeTopAppBar のインセット処理を無効にするには、windowInsets パラメータを空のインスタンスに設定します。

LargeTopAppBar(
    windowInsets = WindowInsets(0, 0, 0, 0),
    title = {
        Text("Hi")
    }
)
InsetsSnippets.kt

ビューシステムの切り欠きとの相互運用

画面に同じ階層に View コードと Compose コードの両方がある場合は、デフォルトのインセットをオーバーライドする必要があります。この場合、インセットを使用するタイプと無視するタイプを明確にする必要があります。

たとえば、最外側のレイアウトが Android View レイアウトの場合は、View システムでインセットを使用し、Compose では無視する必要があります。または、最外側のレイアウトがコンポーザブルの場合は、Compose でインセットを使用し、それに応じて AndroidView コンポーザブルをパディングする必要があります。

デフォルトでは、各 ComposeView は WindowInsetsCompat レベルの使用量ですべてのインセットを使用します。このデフォルトの動作を変更するには、ComposeView.consumeWindowInsets を false に設定します。

システムバーの保護

アプリが SDK 35 以降をターゲットとしている場合、エッジツーエッジが適用されます。システム ステータスバーとジェスチャー ナビゲーション バーは透明ですが、3 ボタン ナビゲーション バーは半透明です。

デフォルトの半透明の 3 ボタン ナビゲーションの背景保護を削除するには、Window.setNavigationBarContrastEnforced を false に設定します。

リソース

• Now in Android: Kotlin と Jetpack Compose のみで構築された、完全に機能する Android アプリです。
• Android 15 でのエッジ ツー エッジの適用の処理 - Android 15 でのエッジ ツー エッジの適用について説明する Codelab
• Android 15 のエッジ ツー エッジの適用に関するインセット処理のヒント
• アプリのエッジ ツー エッジ UI をプレビューしてテストする
• Android アプリの利便性を高める 3 つの方法: エッジ ツー エッジ、予測型「戻る」、Glance - Android 15 のエッジ ツー エッジの適用について説明する YouTube 動画
• エッジツーエッジとインセット | Compose のヒント - インセットを処理してエッジツーエッジに描画する方法を紹介する YouTube 動画