Android 17 でのサイズ変更と画面の向きの変更に対応するため、アプリを準備してください。

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 以降、新たな変更は導入されていませんが、開発者によるオプトアウトはできなくなりました。念のため申し上げますが、アプリが大型スクリーンで実行されている場合（大型スクリーンは、ディスプレイの小さい方の寸法が 600dp 以上であることを意味します）、以下のマニフェスト属性と API は無視されます。

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

また、ユーザーは制御権を保持します。アスペクト比設定では、ユーザーはアプリの要求された動作を使用することを明示的に選択できます。

アプリを準備してください

アプリは、ユーザーが選択できるあらゆるアスペクト比のディスプレイサイズ（サイズ変更可能なウィンドウを含む）に対応した、横向きと縦向きのレイアウトをサポートする必要があります。これは、アスペクト比と向きを縦向きまたは横向きに制限する方法がなくなるためです。

アプリをテストする

まず最初に、これらの変更を加えたアプリをテストし、様々な画面サイズでアプリが正しく動作することを確認してください。

Android Studio で Pixel Tablet および Pixel Fold シリーズのエミュレーターを使用して Android 17 Beta 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
    }
}

ユーザーが折りたたみ式デバイスやタブレットでアプリを横向きに開いた場合、画面下部の Save や Login などのアクションボタンが画面外に表示されることがあります。コンテナがスクロールできない場合、ユーザーは先に進むことができなくなる可能性があります。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 Beta 1 をダウンロードして targetSdkPreview = “CinnamonBun” にアップデートするか、アプリ互換性フレームワーク を使用して特定の変更を有効にしてください。

Android の未来は適応型であり、私たちはその実現を支援するためにここにいます。Android 17 の準備にあたっては、アダプティブレイアウトの構築 に関するガイドと 大画面品質ガイドライン を確認することをお勧めします。これらのリソースは、複数のフォームファクターやウィンドウサイズを自信を持って扱えるように設計されています。

待ってはいけません。今日から Android 17 の準備を始めましょう！