2025 年に Android 16 をリリースした際、Google は、スマートフォン、折りたたみ式デバイス、タブレット、デスクトップ、車載ディスプレイ、XR など、あらゆる画面にアプリがシームレスに適応するデバイス エコシステムのビジョンを共有しました。ユーザーは、アプリがどこでも動作することを期待しています。タブレットでマルチタスクを行う場合、デバイスを開いて快適に読書する場合、デスクトップ ウィンドウ環境でアプリを実行する場合など、ユーザーは UI が利用可能な表示スペース全体に表示され、デバイスの姿勢に適応することを期待しています。

Google は、適応型の動作を促進するために、画面の向きとサイズ変更の API に 大幅な変更を加え、移行を支援するための一時的なオプトアウトを提供しました。API レベル 36 を対象とする場合、多くのデベロッパーがこの移行に成功しています。

Android 17 ベータ版のリリースに伴い、適応型ロードマップの次のフェーズに移行します。Android 17（API レベル 37）では、大画面デバイス（画面幅 600 dp 超）での画面の向きとサイズ変更の制限に対するデベロッパーのオプトアウトが削除されます 。対象 API レベル 37 をターゲットとする場合、アプリはさまざまな表示サイズに適応できる必要があります。

この動作変更により、Android エコシステムは、すべてのデバイス フォーム ファクタで一貫した高品質のエクスペリエンスを提供できるようになります。

Android 17 での変更点

Android 17 をターゲットとするアプリは、Android 16 で導入されたマニフェスト属性とランタイム API の段階的な廃止との互換性を確保する必要があります。一部のアプリでは大きな移行になる可能性があるため、このブログ投稿では、後で発生する一般的な問題を回避するための効果的な手法とツールを紹介します。

Android 16 以降、新しい変更は導入されていませんが、デベロッパーのオプトアウトはできなくなりました。アプリが大画面で実行されている場合（画面の小さい方の寸法が 600 dp 以上の場合は大画面と見なされます）、次のマニフェスト属性と API は無視されます。

注:  Android 16 で前述したように、これらの変更は、画面幅が 600 dp 未満の画面や、android:appCategory フラグに基づいてゲームとして分類されるアプリには適用されません。

また、ユーザーは引き続き制御できます。アスペクト比の設定で、ユーザーはアプリのリクエストされた動作を使用することを明示的にオプトインできます。

アプリを準備する

アスペクト比と画面の向きを縦向きまたは横向きに制限する方法がなくなるため、アプリは、ユーザーがアプリを使用できるアスペクト比の全範囲（サイズ変更可能なウィンドウを含む）で、横向きと縦向きのレイアウトをサポートする必要があります。

アプリをテストする

まず、これらの変更を加えてアプリをテストし、さまざまなディスプレイ サイズでアプリが正常に動作することを確認します。

Android Studio で Google Pixel Tablet シリーズと Google Pixel Fold シリーズのエミュレータを使用して Android 17 ベータ版 1 を使用し、targetSdkPreview = “CinnamonBun” を設定します。または、アプリがまだ対象 API レベル 36 をターゲットとしていない場合は、アプリ互換性フレームワークを使用してUNIVERSAL_RESIZABLE_BY_DEFAULTフラグを有効にすることもできます。

レイアウトが正しく適応されるようにするための追加ツールがあります。Compose UI Checkを使用すると、UI を自動的に監査し、UI をより適応型にするための提案を得ることができます。また、DeviceConfigurationOverrideを使用して、テストで特定のディスプレイ特性をシミュレートできます。

これまで画面の向きとアスペクト比を制限してきたアプリでは、構成変更の処理時に、カメラ プレビューの歪みや向きのずれ、レイアウトの引き延ばし、ボタンへのアクセス不能、ユーザーの状態の損失などの問題がよく発生します。

これらの一般的な問題に対処するための戦略をいくつか見てみましょう。

カメラの互換性を確保する

横向きの折りたたみ式デバイスや、マルチウィンドウ、デスクトップ ウィンドウ、接続されたディスプレイなどのシナリオでのアスペクト比の計算では、カメラ プレビューが引き延ばされたり、回転したり、切り抜かれたりすることがよくあります。

カメラ プレビューが引き延ばされたり、回転したりしないようにします。

この問題は、大画面デバイスや折りたたみ式デバイスでよく発生します。これは、アプリがカメラ機能（アスペクト比やセンサーの向きなど）とデバイス機能（デバイスの向きや自然な向きなど）の間に固定された関係があることを前提としているためです。

カメラ プレビューがウィンドウ サイズや画面の向きに正しく適応されるようにするには、次の 4 つの解決策を検討してください。

解決策 1: Jetpack CameraX（推奨） 

最もシンプルで堅牢な解決策は、Jetpack CameraX ライブラリを使用することです。その PreviewView UI 要素は、プレビューの複雑さをすべて自動的に処理するように設計されています。

• PreviewView は、センサーの向き、デバイスの回転、スケーリングに合わせて正しく調整されます。
• PreviewView は、通常は中央に配置して切り抜く（FILL_CENTER）ことで、カメラ画像のアスペクト比を維持します。
• 必要に応じて、スケールタイプを FIT_CENTER に設定してプレビューをレターボックス表示にできます。

詳しくは、CameraX ドキュメントの プレビューを実装するをご覧ください。

ソリューション 2: CameraViewfinder 

既存の Camera2 コードベースを使用している場合は、CameraViewfinder ライブラリ（API レベル 21 との下位互換性あり）も最新のソリューションです。TextureView または SurfaceView を使用してカメラフィードの表示を簡素化し、必要な変換（アスペクト比、スケール、回転）をすべて適用します。

詳しくは、カメラ ビューファインダーの概要のブログ投稿とカメラ プレビューのデベロッパー ガイドをご覧ください。

解決策 3: 手動による Camera2 の実装 

CameraX または CameraViewfinder を使用できない場合は、画面の向きとアスペクト比を手動で計算し、構成が変更されるたびに計算が更新されるようにする必要があります。

• CameraCharacteristics からカメラセンサーの向き（0、90、180、270 度など）を取得します。
• デバイスの現在のディスプレイの回転を取得します（0、90、180、270 度など）。
• カメラセンサーの向きとディスプレイの回転の値を使用して、SurfaceView または TextureView に必要な変換を決定します。
• 歪みを防ぐため、出力 Surface のアスペクト比がカメラ プレビューのアスペクト比と一致していることを確認します。

重要: カメラアプリは、マルチウィンドウ モードまたはデスクトップ ウィンドウ モード、または接続されたディスプレイで、画面の一部で実行されている可能性があります。そのため、画面サイズを使用してカメラ ビューファインダーのサイズを決定しないでください。代わりにウィンドウ指標を使用してください。そうしないと、カメラ プレビューが引き延ばされる可能性があります。

詳しくは、カメラ プレビューのデベロッパー ガイドとさまざまなフォーム ファクタでのカメラアプリの動画をご覧ください。

ソリューション 4: インテントを使用して基本的なカメラ操作を行う 

多くのカメラ機能が必要ない場合は、デバイスのデフォルトのカメラ アプリケーションを使用して写真や動画の撮影などの基本的なカメラ操作を行うのが、シンプルで簡単な解決策です。この場合、カメラ ライブラリと統合する代わりに Intent を使用するだけで、メンテナンスと適応性を高めることができます。

詳しくは、カメラのインテントをご覧ください。

UI の引き延ばしやボタンへのアクセス不能を回避する

アプリが特定のデバイスの向きやディスプレイのアスペクト比を想定している場合、さまざまな画面の向きやウィンドウ サイズで使用すると問題が発生する可能性があります。

ボタン、テキスト フィールド、その他の要素が大画面で引き延ばされないようにします。

ボタン、テキスト フィールド、カードを fillMaxWidth または match_parent に設定している場合があります。スマートフォンでは、これは問題ありません。ただし、タブレットや折りたたみ式デバイスを横向きにすると、UI 要素が大画面全体に引き延ばされます。Jetpack Compose では、widthIn 修飾子を使用してコンポーネントの最大幅を設定し、コンテンツの引き延ばしを防ぐことができます。

Box(
    contentAlignment = Alignment.Center,
    modifier = Modifier.fillMaxSize()
) {
    Column(
        modifier = Modifier
            .widthIn(max = 300.dp) // Prevents stretching beyond 300dp
            .fillMaxWidth()        // Fills width up to 300dp
            .padding(16.dp)
    ) {
        // Your content
    }
}

折りたたみ式デバイスやタブレットでアプリを横向きで開くと、画面下部の [保存] や [ログイン] などの操作ボタンが画面外にレンダリングされることがあります。コンテナがスクロールできない場合、ユーザーは続行できなくなる可能性があります。Jetpack Compose では、コンポーネントに verticalScroll 修飾子を追加できます。

Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(16.dp)
)

最大幅の制約と縦スクロールを組み合わせることで、アプリのウィンドウ サイズがどれだけ広くなっても短くなっても、アプリが機能し、使用可能であることを保証できます。

詳しくは、適応型レイアウトの構築に関するガイドをご覧ください。

構成変更による状態の保持

画面の向きとアスペクト比の制限を削除すると、アプリのウィンドウ サイズが頻繁に変更されるようになります。ユーザーは、デバイスを回転させたり、折りたたんだり、開いたり、分割画面モードやデスクトップ ウィンドウ モードでアプリのサイズを動的に変更したりできます。

デフォルトでは、これらの構成変更によりアクティビティが破棄され、再作成されます。アプリがこのライフサイクル イベントを適切に管理しないと、ユーザーは不満を感じる可能性があります。スクロール位置が先頭にリセットされ、半分入力されたフォームが消去され、ナビゲーション履歴が失われます。シームレスな適応型エクスペリエンスを実現するには、アプリがこれらの構成変更を通じて状態を保持することが重要です。Jetpack Compose では、再作成をオプトアウトし、ウィンドウ サイズの変更に応じて UI を再構成して、利用可能な新しいスペースを反映させることができます。

詳しくは、_UI の状態を保存する_に関するガイドをご覧ください。

2027 年 8 月までに API レベル 37 をターゲットとする

アプリが API レベル 36 をターゲットとする際にこれらの変更をオプトアウトしていた場合、アプリが API レベル 37 をターゲットとするまで、Android 17 のオプトアウトの削除による影響はありません。事前に計画を立て、アプリに必要な調整を行うために、これらの変更が有効になる時期のタイムラインを示します。

• Android 17: 上記の変更は、API レベル 37 をターゲットとするアプリ の大画面デバイス（最小画面幅 600 dp 超）のベースライン エクスペリエンスとなります。デベロッパーはオプトアウトできません。

特定の API レベルをターゲットとする期限は、アプリストアによって異なります。Google Play では、新しいアプリとアップデートで対象 API レベル 37 をターゲットとする必要があり、2027 年 8 月に配信するにはこの動作が必須となります。

Android 17 の準備

Android 17 でアプリに影響するすべての変更については、Android 17 の変更ページをご覧ください。アプリをテストするには、Android 17 ベータ版 1 をダウンロードして targetSdkPreview = “CinnamonBun” に更新するか、アプリ互換性フレームワークを使用して特定の変更を有効にします。

Android の未来は適応型であり、Google はその実現をサポートします。Android 17 の準備を進めるにあたり、適応型レイアウトの構築に関するガイドと大画面の品質に関するガイドラインをご確認ください。これらのリソースは、複数のフォーム ファクタとウィンドウ サイズを自信を持って処理できるように設計されています。

今すぐ、Android 17 の準備を始めましょう。