2025 年の Android 16 のリリースに伴い、スマートフォン、折りたたみ式デバイス、タブレット、デスクトップ、車載ディスプレイ、XR など、あらゆる画面にアプリがシームレスに適応するデバイス エコシステムのビジョンを共有しました。ユーザーは、アプリがどこでも動作することを期待しています。タブレットでマルチタスクを行っている場合でも、デバイスを開いて快適に読書をしている場合でも、デスクトップ ウィンドウ環境でアプリを実行している場合でも、ユーザーは UI が利用可能な表示スペースを埋め、デバイスの姿勢に適応することを期待しています。
アダプティブな動作を容易にするため、向きとサイズ変更の API に大幅な変更を導入しました。移行を支援するため、一時的なオプトアウトも提供しています。API レベル 36 をターゲットとする場合、多くのデベロッパーがこの移行にうまく対応しています。
Android 17 ベータ版のリリースに伴い、Google は適応型ロードマップの次のフェーズに移行します。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 | 無視される値 |
| screenOrientation | portrait、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 を使用して、テストで特定のディスプレイ特性をシミュレートすることもできます。
これまで画面の向きとアスペクト比を制限してきたアプリでは、カメラ プレビューの歪みや向きのずれ、レイアウトの引き伸ばし、ボタンへのアクセス不能、設定変更の処理時のユーザー状態の喪失といった問題がよく見られます。
こうした一般的な問題に対処するための戦略をいくつか見ていきましょう。
カメラの互換性を確認する
横向きの折りたたみ式デバイスや、マルチ ウィンドウ、デスクトップ ウィンドウ、接続ディスプレイなどのシナリオでアスペクト比を計算する場合に、カメラ プレビューが引き伸ばされたり、回転したり、切り取られたりすることがあります。
カメラ プレビューが引き伸ばされたり回転したりしていないことを確認します。
この問題は、大画面デバイスや折りたたみ式デバイスでよく発生します。アプリが、カメラ機能(アスペクト比やセンサーの向きなど)とデバイス機能(デバイスの向きや自然な向きなど)の間に固定された関係があることを前提としているためです。
カメラ プレビューがウィンドウ サイズや画面の向きに正しく適応するようにするには、次の 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 の準備を始めましょう
-
プロダクト ニュース本日、Galaxy Unpacked で、Samsung は折りたたみ式デバイスとウェアラブル デバイスの最新ラインナップを発表しました。デベロッパーにとっては、アプリがサポートする必要のあるフォーム ファクタ、画面サイズ、デバイスの姿勢のバリエーションが再び拡大することを意味します。
Fahd Imtiaz, Miguel Montemayor • 所要時間: 3 分 -
プロダクト ニュースGoogle Pixel 10 Pro Fold のような新しいフォーム ファクタが Android エコシステムに加わることで、スマートフォン、タブレット、折りたたみ式デバイス全体で高品質なユーザー エクスペリエンスを実現するには、アダプティブ アプリ開発が不可欠になります。
Fahd Imtiaz, Miguel Montemayor • 所要時間: 3 分 -
プロダクト ニュースGoogle Play では、サブスクリプション プラットフォームを継続的に拡大し、成長の促進、新しいビジネスモデルへの適応、ユーザーのニーズへの対応をサポートしています。
Sheenam Mittal • 所要時間: 4 分
Android 開発に関する最新の分析情報を毎週メールでお届けします。