画面の互換性の概要

Android は、画面サイズとピクセル密度が異なるさまざまなデバイスで動作します。システムは、ユーザー インターフェースをさまざまな画面に適合させるために基本的なスケーリングとサイズ変更を実行しますが、UI を各画面タイプに適応させるための方法があります。

図 1 Android は、画面とピクセル密度が異なるさまざまなデバイスで動作します。

このページでは、アプリを状況に合わせて調整するために Android で利用できる機能の概要を説明します。さまざまな画面バリエーション用にアプリをビルドする方法について詳しくは、次のドキュメントをご覧ください。

画面サイズ

画面サイズは、アプリの UI の表示スペースです。アプリで認識される画面サイズは、デバイス画面の実際のサイズではありません。アプリでは、画面の向き、システム デコレーション(ナビゲーション バーなど)、ウィンドウ構成の変更(ユーザーがマルチ ウィンドウ モードを有効にした場合など)を考慮する必要があります。

柔軟なレイアウト

デフォルトでは、Android は現在の画面に合わせてアプリのレイアウトのサイズを変更します。画面サイズの小さな変化に対してレイアウトが適切にサイズ変更されるようにするには、柔軟性を念頭に置いてレイアウトを実装します。UI コンポーネントの位置とサイズはハードコードしないでください。代わりに、ビューサイズを拡大し、親ビューや他の兄弟ビューからの相対ビューの位置を指定することで、レイアウトが拡大しても意図した順序と相対サイズを維持できます。

柔軟なレイアウトについて詳しくは、レスポンシブ デザインをご覧ください。

代替レイアウト

柔軟なレイアウトは重要ですが、デバイスごとに使用可能なスペースに合わせてユーザー エクスペリエンスを最適化する、さまざまなレイアウトを設計することも必要です。Android では、現在のデバイスの画面サイズに基づいてシステムが実行時に適用する代替レイアウト ファイルを指定できます。

図 2. 同じアプリが、画面サイズごとに異なるレイアウトを使用します。

代替レイアウトを作成する方法については、アダプティブ デザインをご覧ください。

伸縮可能な画像

現在の画面に合わせてレイアウトを伸縮する必要があるため、レイアウト ビューに添付するビットマップも伸縮します。ただし、通常のビットマップを任意の方向に引き伸ばすと、スケーリングが不自然になったり、画像が歪んだりすることがあります。

この問題を解決するために、Android は 9-patch ビットマップをサポートしています。9-patch ビットマップでは、伸縮可能な小さなピクセル領域を指定し、画像の残りの部分はスケーリングしないままにします。

9-patch ビットマップの詳細については、NinePatch ドローアブルをご覧ください。

ピクセル密度

ピクセル密度は、画面の物理領域内のピクセル数です。dpi(1 インチあたりのドット数)で表されます。これは、画面の解像度(画面の総ピクセル数)とは異なります。

図 3.
同じサイズでピクセル密度が異なる 2 つのデバイスを誇張して表現した図。

密度非依存

図 3 に示すように、アプリが「密度非依存」を実現するには、図 3 に示すように、異なるピクセル密度の画面で表示されるときに、ユーザーの視点から見た UI デザインの物理サイズを維持する必要があります。密度非依存を維持することが重要です。そうしないと、ボタンなどの UI 要素が低密度画面では大きくなり、高密度画面では小さく表示される可能性があるためです。

Android では、使用する測定単位としてピクセル(px)ではなく密度非依存ピクセル(dp または dip)を指定することで、密度非依存を実現しています。

密度非依存ピクセルについて詳しくは、密度非依存ピクセルを使用するをご覧ください。

代替ビットマップ

すべての画面で画像が最適に表示されるように、各画面密度に合わせた代替ビットマップを指定します。アプリで低密度画面専用のビットマップを提供する場合、Android は、高密度画面が表示されるときにビットマップがスケールアップされ、画像が画面上の同じ物理スペースを占有します。これにより、ビットマップにスケーリングのアーティファクトが生じることがあります。そのため、アプリにより高い解像度で代替ビットマップを含める必要があります。

代替ビットマップを用意する方法については、代替ビットマップを提供するをご覧ください。

ベクター グラフィック

アイコンなどの単純な画像の場合は、ベクター グラフィックを使用して、密度ごとに別々の画像を作成せずに済みます。ベクター グラフィックでは、ピクセルではなく幾何学的なラインパスを使用してイラストを定義するため、アーティファクトを拡大することなく、任意のサイズで描画できます。

ベクター グラフィックの使用について詳しくは、ベクター グラフィックを優先するをご覧ください。

Wear OS、TV、Auto、ChromeOS

上記の推奨事項はすべての Android フォーム ファクタに適用されますが、Wear OS、Android TV、Android Auto、ChromeOS デバイス向けのアプリを作成する場合は、より多くの作業が必要になります。

これらの各デバイスタイプには、アプリが対応する必要がある独自のユーザー操作モデルがあります。場合によっては、Wear OS など、アプリのユーザー エクスペリエンスを見直し、そのデバイスに特化したアプリを作成する必要があります。一方、Google Pixelbook などの ChromeOS デバイスをサポートする場合は、既存のアプリを少し変更するだけで、キーボードやマウスの操作、および大画面に対応できます。

これらのデバイスをサポートするには、以下のドキュメントをご覧ください。

折りたたみ式デバイス

折りたたみ式デバイスは通常、複数のディスプレイを備えており、異なるディスプレイ(またはディスプレイの組み合わせ)が、デバイスのさまざまな折りたたみ状態に応じてアクティブになります。このドキュメントのガイドラインに沿って、そのような構成の変化にアプリを適応させます。ただし、一部の構成では通常とは異なるアスペクト比になる可能性があるため、さまざまなデバイスでアプリの動作をテストしてください。

図 4. 折りたたんでも広げても。

通常、さまざまなウィンドウ サイズでマルチウィンドウ モードで適切に動作するアプリは、折りたたみ式デバイスでも適切に動作します。

折りたたみ式デバイス向けのアプリの作成について詳しくは、折りたたみ式デバイスについてをご覧ください。

画面の非互換性

Android のフレームワークとツールには、アプリをすべての画面構成で使用できるようにするために必要なものがすべて揃っていますが、互換性がないため、一部の画面構成でアプリを使用したくない場合もあります。この場合は、画面サポートの制限を宣言できます。