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

アダプティブな動作を容易にするため、画面の向きとサイズ変更の API に大幅な変更を導入しました。また、移行を支援するため、一時的なオプトアウトも提供しています。API レベル 36 をターゲットとする場合、多くのデベロッパーがこの移行にうまく対応しています。

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

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

Android 17 の変更点

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

Android 16 以降、新たな変更は導入されていませんが、デベロッパーによるオプトアウトはできなくなっています。なお、アプリが大画面で実行されている場合（大画面とは、ディスプレイの小さい方のサイズが 600 dp 以上であることを意味します）、次のマニフェスト属性と API は無視されます。

注: Android 16 で前述したように、これらの変更は、sw 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)
)

max-width の制約と縦スクロールを組み合わせることで、アプリ ウィンドウのサイズがどれだけ幅広くなったり、短くなったりしても、アプリの機能とユーザビリティを維持できます。

アダプティブ レイアウトの作成に関するガイドをご覧ください。

構成変更で状態を保持する

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

デフォルトでは、こうした構成変更により、アクティビティが破棄され、再作成されます。アプリがこのライフサイクル イベントを適切に管理していない場合、ユーザーはスクロール位置が先頭にリセットされたり、入力途中のフォームが消去されたり、ナビゲーション履歴が失われたりして、不満を感じることになります。シームレスなアダプティブ エクスペリエンスを実現するには、アプリがこれらの構成変更を通じて状態を保持することが重要です。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 の準備を始めましょう。