サービスに関する最新情報

Android 17 でのサイズ変更と画面の向きの変更に対応できるようアプリを準備する

所要時間: 6 分
Miguel Montemayor のプロフィールを表示
Miguel Montemayor デベロッパー リレーションズ エンジニア

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

Google は、アダプティブな動作を促進するために、画面の向きとサイズ変更に関する 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 フラグに基づいてゲームに分類されているアプリには適用されません。

マニフェスト属性 / API無視される値
screenOrientationportrait、reversePortrait、sensorPortrait、userPortrait、landscape、reverseLandscape、sensorLandscape、userLandscape
setRequestedOrientation()portrait、reversePortrait、sensorPortrait、userPortrait、landscape、reverseLandscape、sensorLandscape、userLandscape
resizeableActivityすべて
minAspectRatioすべて
maxAspectRatioすべて

また、ユーザーは管理権限を保持します。アスペクト比の設定で、ユーザーはアプリのリクエストされた動作を明示的にオプトインできます。

アプリを準備する

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

アプリをテストする

最初のステップは、これらの変更を加えたアプリをテストして、さまざまなディスプレイ サイズでアプリが適切に動作することを確認することです。

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 を使用すると、テストで特定のディスプレイ特性をシミュレートできます。

これまで向きやアスペクト比を制限していたアプリでは、カメラ プレビューの歪みや向きの誤り、レイアウトの引き伸ばし、ボタンにアクセスできない、構成変更の処理時にユーザーの状態が失われるなどの問題がよく見られます。

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

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

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

camera_preview_issue.png

カメラのプレビューが引き伸ばされたり回転したりしていないことを確認します。

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

カメラ プレビューがウィンドウのサイズや向きに正しく適応するようにするには、次の 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 の引き伸ばしやボタンの操作不能を回避する

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

elementsLS.png

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

ボタン、テキスト フィールド、カードを 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 レベルとする際にこれらの変更をオプトアウトしていたアプリは、API レベル 37 を対象 API レベルとした後にのみ、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 への対応を始めましょう。

作成者:
続きを読む