折りたたみ式デバイス向けアプリでアスペクト比を変更する方法

  • Android 16 では、大画面 (sw ≥ 600dp) での向きとアスペクト比の制限が無視され、アダプティブ UI が強化されます。
  • 引き伸ばしを回避し、状態を維持するために、Compose でウィンドウ サイズ クラスとレスポンシブ パターンを採用します。
  • Pixel Tablet/Fold エミュレータでテストし、rememberSaveable、ViewModel、互換性ツールを使用します。
  • すぐに調整するには、フルスクリーン アプリを 1 つずつ使用し、密度 (幅を小さくする) を慎重に変更します。
Joaquin Romero

12分

折りたたみ式スマートフォンのアスペクト比を設定する方法

折りたたみ式デバイスのアプリでアスペクト比を変更する方法を知りたい場合は、適切な場所に来ています。 折りたたみ式の携帯電話やタブレットでは、サイズや向きの多様性が劇的に増加しました。そして、それはアプリの見た目に直接影響します。Android 16の新しいポリシー、システムの調整、デザインのベストプラクティスなど、コンパクト、ミディアム、エクステンデッドの画面にすべてが完璧にフィットするようにするには、考慮すべき点が数多くあります。

状況は明らかです。 Android では、すべてのアプリがサイズ変更可能になり、大画面でのエクスペリエンスを尊重することを推進しています。 （タブレット、デスクトップモード、内蔵折りたたみ画面）それでも、アプリごとにアスペクト比を調整したり、エミュレータでテストしたり、互換性動作を有効にしたり、必要に応じて例外を作成したりする方法があります。遠回しにせず、順を追って説明していきましょう。

Android 16（API 36）の変更点：向き、外観、サイズ

Android 16（API レベル 36）では、大画面でのアプリの向き、アスペクト比、サイズ変更に関する制限をシステムが無視できます。 これは、最小幅（sw）が600dp以上のデバイスに適用されます。タブレット、 多くの折りたたみ式携帯電話の内部画面 デスクトップウィンドウモードにも対応しています。十分なスペースがある場合、ユーザーの好みに合わせて向きやサイズを調整し、大画面でも一貫したエクスペリエンスを提供することを目指しています。

API 36をターゲットとするアプリでは、 アクティビティはデフォルトでサイズ変更可能になります デバイスのswが600dp以上の場合（resizeableActivity="true"に相当）、マルチウィンドウモードに移行できます。実際には、システムは大画面で固定動作を強制するために使用していたいくつかの属性を無視します。

API 36 をターゲットとする場合、大画面では属性が無視されます

アプリが Android 16 をターゲットとしている場合、ディスプレイ sw ≥ 600dp ではいくつかのマニフェスト フラグと関連 API が無視されます。 効果がなくなる属性の中には screenOrientation (縦向き、横向き、センサー/ユーザーのバリエーション)、resizeableActivity、minAspectRatio、maxAspectRatio、および同じ固定値を持つ setRequestedOrientation()/getRequestedOrientation() などの呼び出し。

タブレットをノートパソコンに変える方法
関連記事
Androidタブレットをキーボードとマウス付きのノートパソコンに変える

この変更により、コンテンツを表示するためのスペースがたくさんある場合に、アプリが縦向きまたは狭いアスペクト比で「ロック」されることがなくなります。 適応型レイアウトを優先し、不要な伸縮や切り取りを避けることが目的です。 大画面のユーザーをイライラさせます。

例外：これらの変更が適用されない場合

折りたたみ式携帯電話のアスペクト比

新しいモデルでは大画面に対して厳しくなっていますが、例外もあります。 これらのオーバーライドは、sw < 600dp の画面には適用されません。 （多くのスマートフォン、一部の折りたたみ式スマートフォンは外部モードで動作します）、およびゲーム（カテゴリ android:appCategory="game"）は除外されます。さらに、ユーザーがアスペクト比オプションでアプリのデフォルトの動作を有効にしている場合は、その設定が優先されます。

ゲームを公開する場合、 Google Playはアプリのカテゴリ管理に役立ちます Android App Bundle と Google Play アプリ署名を使用すると、配信上のさらなるメリットが得られます。ゲーム以外のアプリの場合、重要なのはレスポンシブな UI を構築し、ウィンドウ表示をシステムに任せることです。

API 36 の動作を無効にする方法と API 37 の通知

正当な理由により、API 36でこの動作を適用しないことを選択する必要がある場合、 マニフェストプロパティを宣言することができます 「android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY」。特定のアクティビティまたはアプリケーション全体に設定します。

<activity ...>
    <property
        android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY"
        android:value="true" />
</activity>
<application ...>
    <property
        android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY"
        android:value="true" />
</application>

これに注意してください: フレームワークはAPI 37の「オプトアウト」オプションを削除します。つまり、37 以上をターゲットとするアプリの場合、sw ≥ 600dp の画面では、向き、アスペクト比、サイズ変更の制限は常に無視されます。

エミュレータとデバイスでのテスト：実際のケースを再現する方法

アプリが変更の影響を受けるかどうかを確認するには、 Android Studio で Pixel Tablet と Pixel Fold のエミュレータを使用するモジュールの build.gradle ファイルで targetSdkPreview = "Baklava" を定義し、UI が方向、折りたたみ/展開、ウィンドウ サイズの変更にどのように反応するかを確認します。

ユニバーサルなサイズ変更動作を有効にすることもできます 互換性マーク UNIVERSAL_RESIZABLE_BY_DEFAULT 付き テストデバイスでテストできます。また、自動テストでは、Espresso と Jetpack Compose のテスト API を使って、サイズ変更、回転、マルチウィンドウを含むフロー全体を検証できます。

大画面でよくある問題とその回避方法

固定の向き、特定のアスペクト比、またはサイズ変更できないアクティビティに関連付けられたアプリは、Android 16 で問題が発生する傾向があります。 引き伸ばされた要素、重なり、ビューポート外のボタン プレビューでカメラエラーが発生することがあります。解決策はレスポンシブデザインを採用することです。

  • 引き伸ばされたコンポーネントを避ける: カード、ツールバー、または画像が水平方向に制御不能にならないように、最大​​幅を追加します。
  • 適切な場所でスクロールを有効にします。 変位がない場合、 ユーザーは重要なコントロールを失う可能性がある 横向きモードに切り替えるとき。
  • どちらの方向でもカメラを慎重に取り扱ってください。 ファインダーと回転をセンサーに合わせて調整します。固定のアスペクト比を想定しないでください。
  • サイズ変更時に状態を保持します: アクティビティは再作成可能で、フォーム入力とユーザー コンテキストが保持されます。
  • ウィンドウ サイズ クラスを使用する: サイズのカテゴリーと 空間に合わせて適応するレスポンシブレイアウト.

ユーザーの声:「Fold ではアプリが変に見えます」

折りたたみ式のデバイスを使用する場合 ギャラクシーフォールド Instagram や Reddit の画像が誇張されすぎていたり、引き伸ばされていたりすることに気づいたとしても、それはあなただけではありません。 これは大画面向けに最適化されていないアプリの症状です あるいは強制的にスケーリングされることもあります。さらにゲームでは、スペースを有効活用できず、見栄えの悪いタイトルも存在します。

設定はありますか？多くのメーカーでは、アプリごとに全画面表示を強制できます。 ただし、アプリが適応されていない場合、結果は最適にならない可能性があります。理想的には、開発者はアダプティブ レイアウトを採用する必要があります。ユーザーは、[設定] > [表示] > [全画面表示アプリ] (または [アプリのスケーリング]) をチェックして、各アプリを管理します。

便利なシステム設定: アプリごとのアスペクト比と密度

さまざまなメーカーの Android スキンには、特定のアプリを全画面または特定のアスペクト比で実行するためのオプションがあります。 通常のパス: 設定 > ディスプレイ > アプリのスケーリング / アプリを全画面で表示アプリから有効化して結果を確認してください。

それでも内容が一致しない場合は、 開発者オプションから密度（最小幅）を調整できますビルド番号を7回タップして開発者モードを有効にし（設定 > システム > 端末情報）、開発者向けオプションに移動して「最小幅」を調整します。値を下げると画面全体が大きくなり、上げると画面全体が小さくなります。この手順を1つずつ実行し、元の値をメモしておいてください。

曲面スクリーンの場合、一部のシステムには 「エッジのランダムタッチを無視する」 または「誤タッチ保護」。影響範囲は特定のレイヤー（例えば一部のXiaomiモデル）でカスタマイズできます。アスペクト比は固定されませんが、設定をテストする際に誤タッチを軽減します。

Compose とレスポンシブ デザイン: ウィンドウ サイズ クラス

Jetpack Compose は、UI が壊れることなく拡張できる完璧なツールを提供します。 ウィンドウサイズクラス（マテリアル3）はロジックを簡素化します レイアウトを物理的な画面サイズから切り離します。幅と高さに基づいてコンパクト、ミディアム、エクスパンデッドに分類し、それに応じてUIを調整します。

ルート コンポーザブルでは、サイズ クラスを取得し、それを状態として伝播できます。 「タブレットかどうか」や固定のアスペクト比に基づいてデザインを決定しないでください。アプリは、マルチウィンドウ モード、画面セグメント、または外部モニターで実行できます。

内部コンポーネントの場合は、実際のレンダリング幅を使用します。 BoxWithConstraints を使用すると、使用可能なスペースに基づいて、表示される内容を変更できます。 (たとえば、列レイアウトから詳細を含む行レイアウトに移行するなど)、レイアウト フェーズでの遅延構成のコストを想定します。

すべてのコンテンツがいつでも利用可能

十分な幅がある場合にコンポーネントの詳細を表示すると、 サイズに基づいてデータをロードしないでください常にこれら（例えば、imageUrl、title、description）を渡し、コンポーザブル内でどの部分を表示するかを決定します。これにより、サイズ変更時の副作用を回避し、状態を保持できます。

レイアウトが変更された場合 (1 列から 2 列へ、またはその逆)、showMore などのステータス フラグを最上位に上げることをお勧めします。 これにより、レイアウトが変更されてもユーザーの意図が維持されます。Compose では、rememberSaveable が Activity の再作成を通じて状態を維持するのに役立つことに注意してください。

サイズ変更をブロックするマニフェストと制限

アプリのサイズが変更されない場合、または特定のアスペクト比で固定されている場合は、AndroidManifest.xml を確認してください。 android:maxAspectRatio、android:resizeableActivity=»false»を削除し、screenOrientationを修正しました。 大画面やフリーフォーマット向けに最適化している場合、API 36 はシステムによって無視されるため、600dp 以上のソフトウェア サイズではほとんど役に立ちません。

レガシー アプリの場合、この手順が重要です。 ウィンドウを拡大したり縮小したりできるようにする これは、デスクトップ モード、分割画面モード、または折りたたみ式画面を展開したときに UI が適切に応答することを保証するための最初の主要なフィルターです。

構成の変更とライフサイクル

ウィンドウサイズを変更する場合、 設定が更新されました。 （幅/高さ、向き、アスペクト比）。クラシックビューではonConfigurationChangedで確認できますが、ComposeではLocalConfiguration.currentがこれらの変更を自動的に反映します。

ライフサイクルへの影響もわかります。 API 24以降、大幅なサイズの変更のみがアクティビティを再作成します。ただし、発生する可能性はあります。LifecycleEventObserver でイベントをログに記録し、アクティビティがいつ破棄/作成されたかを確認してください。外部モニターを接続したり、密度が変化したりした場合も、アクティビティが再作成される可能性があります。

状態と背景作業の継続性

UIの状態を再現から保護するために、 rememberの代わりにrememberSaveableを使用してください 状態が構成変更を生き残る必要がある場合。また、再作成間の真の連続性を確保するために状態をViewModelに昇格させ、コストのかかるリソースの重複を回避します。

onCreate() で初期化がトリガーされた場合は、繰り返すことができます。 初期化をViewModelのinitに移動する ViewModelのライフサイクルごとに1回だけ実行されるようにします。これは、ネットワーク呼び出しや大量のI/Oが発生する場合に特に重要です。

折りたたみ式書籍のWebデザイン：CSS、API、パフォーマンス

折りたたみ携帯電話
関連記事
折りたたみ式Androidスマートフォンの究極ガイド：レビュー、比較、おすすめ

ウェブサイトの場合、物事は並行して動作します。 折りたたみ式デバイスではより正確なメディアクエリが必要従来のブレークポイントだけではありません。最小/最大幅とアスペクト比を組み合わせることで、3:4（縦向き）や16:9（横向き）といったシナリオにも対応できます。メニュー、グリッド、画像を、実際に利用可能なスペースに合わせて再配置できます。

@media (min-width: 600px) and (max-width: 900px) {
  /* Pantallas intermedias: plegable semiabierto */
}
@media (aspect-ratio: 3/4) {
  /* Vertical plegado */
}
@media (aspect-ratio: 16/9) {
  /* Apaisado desplegado */
}

ウィンドウセグメントAPIは、 アクティブな画面セグメント マルチパネル環境で動作します。また、丸い角や切り抜き部分に対応するviewport-fit: coverも処理し、JSから方向を検出してちらつきのないUIを調整します。 パフォーマンスを最適化する 折りたたみ式デバイスの一般的なマルチタスク シナリオ向けに、遅延読み込みと圧縮を採用しています。

if (window.screenSegments) {
  const segments = window.screenSegments;
  console.log(segments);
}
/* CSS */
body { /* iOS/entornos compatibles */
  viewport-fit: cover;
}
/* JS */
if (screen.orientation.type === 'landscape-primary') {
  console.log('Modo apaisado');
}

サイズクラス: 推奨される閾値と例

Google は、モバイル、折りたたみ式デバイス、タブレットに最適な dp の幅と高さの 3 つの範囲を推奨しています。 コンパクト（0～599dp）、ミディアム（600～839dp）、エクスパンド（840dp以上）. 折りたたみ式携帯電話 垂直方向では「中」のままになることがあります。水平方向に拡張すると、通常は「拡張」になります。

それを踏まえて、 リストを2～3列のグリッドに置き換えることができます スペースがある場合は、フォントサイズをExpandedに設定し、Compactでコンテンツを読みやすく保ちます。Material 3は、これを確実に計算するための`material3-window-size-class`を提供しています（ただし、これは試験的な状態である可能性があり、`@OptIn`が必要です）。

UI の実践: 再利用可能なコンポーザブルと階層化されたロジック

良いパターンは、サイズ設定ロジックを1つのポイント（ルートコンポーザブルなど）に集中させ、 派生状態を渡す 残りの部分も同様です。これにより、内部のコンポーザブルが暗黙的にグローバル画面サイズに依存することがなくなり、再利用性とテスト性が向上します。

アダプティブ リストの詳細の場合は、最上位レベルで表示するかどうかを決定します。 幅に応じて1つまたは2つのパネル子どもたちがコンテンツに集中できるようにします。スペースに余裕がある場合にカードに追加情報を表示する場合は、BoxWithConstraintsや修飾子を使用して決定しますが、コンポーネントの位置やサイズを固定しないでください。

デスクトップとマルチウィンドウモード：移動の準備

ChromeOSと アンドロイドデスクトップウィンドウは PC オペレーティング システムと同様にサイズ変更されます。 アプリは頻繁なサイズ変更に対応できる必要があります。 固定された向きやアスペクト比に縛られることなく、状態を維持できます。Google のエミュレータとコードラボは、これらすべてを体系的にテストするのに最適な方法です。

これは、アプリが 再計算や過剰請求は発生しません。 サイズ変更時のレイアウト遷移はスムーズである必要があります。ユーザーが最小化してから戻った場合、アプリはコンテキストを失うことなく再開する必要があります。

出版スケジュールと要件

Android 16 はベンチマークを設定します: 600dp以上の画面で、あらゆる方向、アスペクト比、サイズ変更に対応 API 36 を対象とするアプリの場合 (36 では無効にできる可能性がありますが、37 では無効にできません)。

締め切りは店​​舗によって異なりますが、 Google Playは2026年8月からターゲットAPI 36を必須とするまだ厳しい制限がある場合は、予期せぬ事態を避け、何よりも大画面でのエクスペリエンスを向上させるために、移行を計画する時期です。

推奨リソースとテスト

練習用に、Google はサイズ変更に焦点を当てたコードラボを提供しています。 LocalConfigurationを観察し、ライフサイクルを記録するマニフェストの制限を移行し、rememberSaveable を有効にします。サンプルアプリの Reply、JetNews、CanonicalLayouts は、大画面向けに検証されたパターンを示しています。

ウェブチームの場合、 Chrome DevTools、BrowserStack、Samsung Remote Test Lab これらは、折りたたみ状態／展開状態でのテストを容易にします。ネイティブAndroidで作業する場合は、Pixel Tablet/FoldエミュレータとUNIVERSAL_RESIZABLE_BY_DEFAULT互換性フレームワークが役立ちます。

Samsung Galaxy Z Flipの仕様と機能
関連記事
Samsung Galaxy Z Flip：革新的な折りたたみ式デバイスの詳細な仕様と機能

コミュニティノート：期待と現実

折りたたみ式ノートパソコンのユーザーの多くは、 アプリごとに修正する必要があります。 スケーリングは顕著で、一部のゲームでは見た目が悪化しています。これはエコシステムの移行においては理解できることですが、Android 16とそのアダプティブデザインプラクティスにより、アプリの改善への道が開かれました。 大画面を最大限に活用する移行が早ければ早いほど、伸びや切れ目に関する苦情は早くなくなるでしょう。

それでも、デバイスが期待どおりのエクスペリエンスを提供していないと感じた場合は、中古デバイスを買い戻して販売するという選択肢があります。 元のコンテンツでは、Moviloff のようなサービスについて言及されていました。 古い携帯電話を現金に変えて、また別の用途に使うことで、環境にも貢献できます。技術的な解決策ではありませんが、新しい携帯電話の購入を考えている方には興味深いかもしれません。

折りたたみ式アプリのアスペクト比とサイズ変更をマスターするには、新しいモデルを受け入れる必要があります。 システムが大きなウィンドウを処理し、レスポンシブな UI を構築し、状態を保持し、実際のシナリオでテストできるようにします。Android 16 が有利に働き（そして Android 37 が大画面の制限を撤廃）、進むべき道は明確です。ウィンドウ サイズ クラスを採用し、マニフェストをクリーンアップし、引き伸ばされたコンポーネントを避け、スクロールを有効にし、両方の方向でカメラに配慮し、パフォーマンスを測定します。

Android デバイスで画面のリフレッシュ レートを変更できます。
関連記事
Androidで画面のリフレッシュレートを変更する方法

すぐに調整が必要な場合は、フルスクリーンアプリなどのシステムオプションを使用し、「最小幅」設定を慎重に行ってください。ユーザーはすぐに違いに気づくでしょう。より見やすいコンテンツ、歪みの少ない画面、そして大画面にふさわしい体験が得られます。 この情報を共有すれば、より多くのユーザーが携帯電話のアスペクト比を変更する方法を知ることができるでしょう。.