各種の画面サイズのサポート

Android デバイスにはさまざまな形とサイズがあります。そのため、アプリには、レスポンシブで適応性の高いレイアウトを使用する必要があります。特定の画面サイズやアスペクト比を前提とした固定ディメンションのレイアウトを定義するのではなく、さまざまな画面のサイズと向きを適切にサポートするようにアプリを設計してください。

アプリができるだけ多くの画面をサポートしていれば、1 つの APK または AAB でさまざまなデバイスに対応できるため、多くのユーザーがそのアプリを利用できます。さらに、さまざまな画面サイズをサポートするようにアプリを設計することで、デバイスのウィンドウ構成が変更されても(たとえば、ユーザーがマルチ ウィンドウ モードを有効にした場合や、アプリの動作中に画面サイズやアスペクト比が変化する可能性がある折りたたみ式デバイスでアプリが動作する場合)、アプリがその変更を確実に処理できます。

ただし、さまざまな画面のサイズや向きをサポートすることで、必ずしもすべての Android フォーム ファクタにアプリが対応するわけではありません。Wear OS、TV、Auto、Chrome OS をサポートするには、追加の手順が必要になります。

さまざまな画面の UI を作成する方法については、マテリアル デザインのレイアウトについてをご覧ください。

ウィンドウ サイズクラス

ウィンドウ サイズクラスは、サイズ変更可能なアプリ レイアウトを設計、開発、テストするための、独自のビューポート ブレークポイントのセットです。固有のケースに合わせてアプリを最適化する柔軟性とレイアウトのシンプルさのバランスを取れるよう、特別に選ばれたものです。

ウィンドウ サイズクラスは、アプリで利用可能な未加工のウィンドウ サイズを、管理しやすい意味のあるバケットに分割します。バケットには、コンパクト、中程度、拡大の 3 種類があります。利用可能な幅と高さは個別に分割されるため、どの時点でも、アプリには幅のウィンドウ サイズクラスと高さのウィンドウ サイズクラスという、2 つのサイズクラスが関連付けられています。

ウィンドウ サイズクラスは幅と高さの両方に指定されていますが、縦方向のスクロールが多いことから、ほとんどの場合、利用可能な幅の方が利用可能な高さよりも重要です。そのため、アプリの UI にとっては、幅のウィンドウ サイズクラスの方がより意味を持つ可能性があります。

幅に基づくウィンドウ サイズクラスの表現。
図 1. 幅に基づくウィンドウ サイズクラスの表現。
高さに基づくウィンドウ サイズクラスの表現。
図 2. 高さに基づくウィンドウ サイズクラスの表現。

上図のように、こうしたブレークポイントを使用すると、デバイスと構成の観点からレイアウトを引き続き検討できます。各サイズクラスのブレークポイントは、典型的なデバイス シナリオの一般的なケースを表しており、ブレークポイントに基づくレイアウトの設計を検討する際の基準として有用です。

サイズクラス ブレークポイント デバイスによる表現
コンパクトな幅 600 dp 未満 縦向きのスマートフォンの 99.96%
中程度の幅 600 dp 以上 縦向きのタブレットの 93.73%

開いた内側の大型ディスプレイ(縦向き)

拡大幅 840 dp 以上 横向きのタブレットの 97.22%

開いた内側の大型ディスプレイ(横向き)

ほとんどのアプリはここまで
コンパクトな高さ 480 dp 未満 横向きのスマートフォンの 99.78%
中程度の高さ 480 dp 以上 横向きのタブレットの 96.56%

縦向きのスマートフォンの 97.59%

拡大高さ 900 dp 以上 縦向きのタブレットの 94.25%

サイズクラスを物理デバイスで可視化することは有用ですが、ウィンドウ サイズクラスは、画面の物理サイズによって明確に決定されるわけではありません。つまり、ウィンドウ サイズクラスは「isTablet」ロジックを表すわけではありません。ウィンドウ サイズクラスは、アプリで利用可能なウィンドウ サイズによって決定されます。

その結果、次の 2 点が重要となります。

  • 物理デバイスで、特定のウィンドウ サイズクラスが保証されるわけではありません。アプリで利用可能な画面スペースがデバイスの物理画面サイズと異なる理由はさまざまです。モバイル デバイスでは、分割画面モードによって複数のアプリ間で画面を分割できます。Chrome OS では、任意にサイズ変更可能なフリーフォーム ウィンドウで Android アプリを表示できます。折りたたみ式デバイスは複数の物理画面を持つことができます。デバイスを折りたたむと、表示される画面が変わります。

  • ウィンドウ サイズクラスは、アプリの全期間を通じて変わる可能性があります。アプリが開いている間、デバイスの回転、マルチタスク、折りたたみにより、利用可能な画面スペースの量が変わります。そのため、ウィンドウ サイズクラスは動的であり、アプリの UI はそれに適応する必要があります。

ウィンドウ サイズのブレークポイントを使用すると、大まかなアプリ レイアウトを決定できます。たとえば、追加の画面スペースを利用するために特定の正規レイアウトを使用することを決定できます。また、レイアウト グリッドの列の変更について、マテリアル デザインのレイアウト ブレークポイントにも対応します。

ウィンドウ サイズクラスを計算するために、アプリは、Jetpack の WindowManager ライブラリで提供される、アプリで利用可能な現在のウィンドウ指標をクエリする必要があります。

ビュー

enum class WindowSizeClass { COMPACT, MEDIUM, EXPANDED }

class MainActivity : Activity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // ...

        // Replace with a known container that you can safely add a View
        // to where it won't affect the layout and the view won't be
        // replaced.
        val container: ViewGroup = binding.container

        // Add a utility view to the container to hook into
        // View.onConfigurationChanged.
        // This is required for all activities, even those that don't
        // handle configuration changes.
        // We also can't use Activity.onConfigurationChanged, since there
        // are situations where that won't be called when the configuration
        // changes.
        // View.onConfigurationChanged is called in those scenarios.
        container.addView(object : View(this) {
            override fun onConfigurationChanged(newConfig: Configuration?) {
                super.onConfigurationChanged(newConfig)
                computeWindowSizeClasses()
            }
        })

        computeWindowSizeClasses()
    }

    private fun computeWindowSizeClasses() {
        val metrics = WindowMetricsCalculator.getOrCreate()
            .computeCurrentWindowMetrics(this)

        val widthDp = metrics.bounds.width() /
            resources.displayMetrics.density
        val widthWindowSizeClass = when {
            widthDp < 600f -> WindowSizeClass.COMPACT
            widthDp < 840f -> WindowSizeClass.MEDIUM
            else -> WindowSizeClass.EXPANDED
        }

        val heightDp = metrics.bounds.height() /
            resources.displayMetrics.density
        val heightWindowSizeClass = when {
            heightDp < 480f -> WindowSizeClass.COMPACT
            heightDp < 900f -> WindowSizeClass.MEDIUM
            else -> WindowSizeClass.EXPANDED
        }

        // Use widthWindowSizeClass and heightWindowSizeClass
    }
}

ビュー

public enum WindowSizeClass { COMPACT, MEDIUM, EXPANDED }

public class MainActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // ...

        // Replace with a known container that you can safely add a View
        // to where it won't affect the layout and the view won't be
        // replaced.
        ViewGroup container = binding.container;

        // Add a utility view to the container to hook into
        // View.onConfigurationChanged.
        // This is required for all activities, even those that don't
        // handle configuration changes.
        // We also can't use Activity.onConfigurationChanged, since there
        // are situations where that won't be called when the configuration
        // changes.
        // View.onConfigurationChanged is called in those scenarios.
        container.addView(new View(this) {
            @Override
            protected void onConfigurationChanged(Configuration newConfig) {
                super.onConfigurationChanged(newConfig);
                computeWindowSizeClasses();
            }
        });

        computeWindowSizeClasses();
    }

    private void computeWindowSizeClasses() {
        WindowMetrics metrics = WindowMetricsCalculator.getOrCreate()
                .computeCurrentWindowMetrics(this);

        float widthDp = metrics.getBounds().width() /
                getResources().getDisplayMetrics().density;
        WindowSizeClass widthWindowSizeClass;

        if (widthDp < 600f) {
            widthWindowSizeClass = WindowSizeClass.COMPACT;
        } else if (widthDp < 840f) {
            widthWindowSizeClass = WindowSizeClass.MEDIUM;
        } else {
            widthWindowSizeClass = WindowSizeClass.EXPANDED;
        }

        float heightDp = metrics.getBounds().height() /
                getResources().getDisplayMetrics().density;
        WindowSizeClass heightWindowSizeClass;

        if (heightDp < 480f) {
            heightWindowSizeClass = WindowSizeClass.COMPACT;
        } else if (heightDp < 900f) {
            heightWindowSizeClass = WindowSizeClass.MEDIUM;
        } else {
            heightWindowSizeClass = WindowSizeClass.EXPANDED;
        }

        // Use widthWindowSizeClass and heightWindowSizeClass
    }
}

Compose

enum class WindowSizeClass { COMPACT, MEDIUM, EXPANDED }

@Composable
fun Activity.rememberWindowSizeClass() {
    val configuration = LocalConfiguration.current
    val windowMetrics = remember(configuration) {
        WindowMetricsCalculator.getOrCreate()
            .computeCurrentWindowMetrics(this)
    }
    val windowDpSize = with(LocalDensity.current) {
        windowMetrics.bounds.toComposeRect().size.toDpSize()
    }
    val widthWindowSizeClass = when {
        windowDpSize.width < 600.dp -> WindowSizeClass.COMPACT
        windowDpSize.width < 840.dp -> WindowSizeClass.MEDIUM
        else -> WindowSizeClass.EXPANDED
    }

    val heightWindowSizeClass = when {
        windowDpSize.height < 480.dp -> WindowSizeClass.COMPACT
        windowDpSize.height < 900.dp -> WindowSizeClass.MEDIUM
        else -> WindowSizeClass.EXPANDED
    }

    // Use widthWindowSizeClass and heightWindowSizeClass
}

アプリでウィンドウ サイズクラスを確認したら、現在のサイズクラスに基づいてレイアウトの変更を開始できます。ウィンドウ サイズクラスを使用してビューベースのレイアウトをレスポンシブにする方法については、UI をレスポンシブ レイアウトに移行するをご覧ください。ウィンドウ サイズクラスを使用して Compose ベースのレイアウトをレスポンシブにする方法については、アダプティブ レイアウトを作成するをご覧ください。

さまざまなウィンドウ サイズクラスをサポートするためのチェックリスト

変更を加える際は、すべてのウィンドウ サイズ(特にコンパクト、中程度、拡大のレイアウト幅)でレイアウトの動作をテストします。

小画面用の既存のレイアウトがある場合は、まず拡大幅のサイズクラスに合わせてレイアウトを最適化します。これにより、追加のコンテンツまたはレイアウトの変更のためのスペースを最大限確保できます。その後、中程度の幅のクラスに適したレイアウトを確認し、そのサイズに特化したレイアウトの追加を検討します。さらに優れたユーザー エクスペリエンスを提供するには、折りたたみ式デバイスの形状のサポートや、キーボード、マウス、タッチペンによる入力のサポートなど、アプリに適した機能を追加します。

すべてのデバイスと画面サイズで優れたアプリを実現する方法の詳細については、大画面のアプリの品質をご覧ください。

柔軟なレイアウトを作成する

まずどのようなハードウェア プロファイルをサポートするにしても、画面サイズのわずかな変更にも対応できるレイアウトを作成する必要があります。

ConstraintLayout を使用する

さまざまな画面サイズに対応するレスポンシブ レイアウトを作成するには、UI の基本レイアウトとして ConstraintLayout を使用することをおすすめします。ConstraintLayout を使用すると、レイアウト内の他のビューとの空間的な関係に従って各ビューの位置とサイズを指定できます。これにより、画面サイズの変化に応じてすべてのビューを同時に移動したり拡大したりできます。

ConstraintLayout でレイアウトを作成するときは、Android Studio の Layout Editor を使用すると簡単です。このツールを使用すると、XML を手作業で編集することなく、新しいビューをレイアウトにドラッグし、その制約を親ビューや他の兄弟ビューに追加して、ビューのプロパティを編集できます(図 1 を参照)。

詳しくは、ConstraintLayout でレスポンシブ UI を作成するをご覧ください。

図 1. ConstraintLayout ファイルを表示している Android Studio の Layout Editor

ConstraintLayout によってすべてのレイアウト シナリオが解決されるわけではありませんが(特に、動的に読み込まれるリストについては RecyclerView を使用する必要があります)、どのレイアウトを使用するにしても、レイアウト サイズのハード コーディングは避けることをおすすめします(次のセクションを参照)。

レイアウト サイズのハード コーディングを避ける

さまざまな画面サイズに合わせて調整できる柔軟なレイアウトにするには、ほとんどのビュー コンポーネントの幅と高さに、ハードコードされたサイズではなく "wrap_content" または "match_parent" を使用します。

"wrap_content" は、コンテンツをビュー内に収めるために必要なサイズに設定するよう、そのビューに伝えます。

"match_parent" は、ビューを親ビュー内で可能な限り拡大します。

次に例を示します。

<TextView
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:text="@string/lorem_ipsum" />

ビューの実際のレイアウトはその親ビューや兄弟ビューのその他の属性によって異なりますが、この TextView では使用可能なすべてのスペースを埋めるように幅が設定され(match_parent)、ビューの高さはテキストの高さに合わせて設定されます(wrap_content)。これにより、さまざまな画面サイズとテキストの長さにビューが対応できるようになります。

図 2 は、デバイスの向きに応じて画面の幅が変わったときにテキストビューの幅が "match_parent" によってどのように調整されるかを示しています。

図 2. 柔軟なテキストビュー

LinearLayout を使用している場合、レイアウト ウェイトを使用して子ビューを拡大することもできます。これにより、各ビューがその weight 値に比例して残りのスペース全体に表示されます。ただし、ネストされた LinearLayout でウェイトを使用する場合、各ビューのサイズを決めるために複数のレイアウトパスが行われるため UI のパフォーマンスが低下します。幸い、ConstraintLayout はパフォーマンスに影響を与えずに LinearLayout で可能なほぼすべてのレイアウトを実現できるため、レイアウトを ConstraintLayout に変換してみてください。その後、制約チェーンを使用してウェイト レイアウトを定義できます。

リストと詳細の UI に SlidingPaneLayout を使用する

リストと詳細の UI では、画面サイズによって異なる動作が必要になる場合があります。大きなディスプレイで動作する場合、リストペインと詳細ペインを並べて表示するために十分なスペースがあります。リストのアイテムをクリックすると、その詳細が詳細ペインに表示されます。しかし小さな画面では表示が込み入ります。両方のペインを表示するのではなく、1 つずつ表示することをおすすめします。最初に、リストペインがウィンドウ全体に表示されます。ユーザーがアイテムをタップすると、リストペインからそのアイテムの詳細ペインに置き換わり、ウィンドウ全体に表示されます。

SlidingPaneLayout を使用して、2 つのユーザー エクスペリエンスのどちらが現在のウィンドウ サイズに適しているかを判断するロジックを管理できます。

<?xml version="1.0" encoding="utf-8"?>
<androidx.slidingpanelayout.widget.SlidingPaneLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <androidx.recyclerview.widget.RecyclerView
        android:id="@+id/recycler_view"
        android:layout_width="280dp"
        android:layout_height="match_parent"
        android:layout_gravity="start" />

    <androidx.fragment.app.FragmentContainerView
        android:id="@+id/nav_host_fragment"
        android:name="androidx.navigation.fragment.NavHostFragment"
        android:layout_width="300dp"
        android:layout_height="match_parent"
        android:layout_weight="1"
        app:defaultNavHost="true"
        app:navGraph="@navigation/item_navigation" />

</androidx.slidingpanelayout.widget.SlidingPaneLayout>

この幅と高さが、動作を決定する主な要素です。ウィンドウが両方のビューを表示するために十分な大きさ(580 dp 以上)であれば、横並びの UI が使用されます。これより小さい場合は、代わりに全画面のリストから全画面の詳細に置き換わる UI が使用されます。

横並びモードのとき、ウィンドウが最小要件(この例では 580 dp)より大きくなることがあります。weight 値は、2 つのペインのサイズを比率で指定するために使用します。この例では、リストペインは常に 280 dp であり、詳細ペインは残りのスペースを埋めます。ただし、折りたたみ式デバイスで SlidingPaneLayout V1.2.0-alpha01 以降を使用する場合は例外です。このような場合、各ペインは SlidingPaneLayout によってサイズが自動的に調整され、折り目またはヒンジを挟んで両側に割り振られます。

代替レイアウトを作成する

レイアウトは、ビュー内またはビューの周囲のスペースを広げることで、常にさまざまな画面サイズに対応する必要がありますが、すべての画面サイズで最適なユーザー エクスペリエンスを得られるとは限りません。たとえば、スマートフォン用にデザインされた UI の場合、タブレットでは優れたエクスペリエンスを実現できません。このため、特定の画面サイズに合わせて UI デザインを最適化できるように、アプリで代替レイアウト リソースを提供する必要もあります。

図 3. 同じアプリでも画面サイズに合わせて異なるレイアウトを使用できる

画面固有のレイアウトを提供するには、追加の res/layout/ ディレクトリを(別のレイアウトを必要とする画面構成ごとに 1 つ)作成し、画面構成の修飾子を layout ディレクトリ名に追加します。たとえば、使用できる幅が 600 dp の画面の場合は layout-w600dp になります。

この構成修飾子は、アプリ UI が使用できる表示画面スペースを表します。アプリでレイアウトが選択されるとき、システムによって考慮されるのはシステム デコレーション(ナビゲーション バーなど)とウィンドウ構成の変更(ユーザーによるマルチウィンドウ モードの有効化など)です。

Android Studio(バージョン 3.0 以降)で代替レイアウトを作成する手順は次のとおりです。

  1. デフォルトのレイアウトを開いて、ツールバーで [Orientation for Preview] をクリックします。
  2. プルダウン リストで、[Create Landscape Variant] などの候補バリアントをクリックして作成するか、[Create Other] をクリックします。
  3. [Create Other] を選択すると、[Select Resource Directory] が表示されます。左側で画面の修飾子を選択し、その修飾子を [Chosen qualifiers] リストに追加します。修飾子の追加が完了したら、[OK] をクリックします(画面サイズの修飾子については、以降のセクションをご覧ください)。

これにより適切なレイアウト ディレクトリに同じレイアウト ファイルが作成されるので、その画面バリアントに対してレイアウトのカスタマイズを開始できます。

最小幅の修飾子を使用する

画面サイズの「最小幅」の修飾子を使用すると、最小幅(密度非依存ピクセル(dp または dip)単位)を持つ画面に対して代替レイアウトを指定できます。

画面非依存ピクセル単位で画面サイズを記述すると、特定の画面ディメンションに合わせてレイアウト デザインを作成でき、ピクセル密度にばらつきが出てくるという心配もありません。

たとえば、スマートフォンやタブレット用に最適化された main_activity という名前のレイアウトを作成するには、次のようにさまざまなバージョンのファイルをディレクトリに作成します。

res/layout/main_activity.xml           # For handsets (smaller than 600dp available width)
res/layout-sw600dp/main_activity.xml   # For 7” tablets (600dp wide and bigger)

画面の両辺の最小サイズは、デバイスのそのときの向きに関係なく最小幅の修飾子によって指定されます。したがって、レイアウトに使用できる全体的な画面サイズを指定する場合はこの方法が最も簡単です。

他の最小幅の値と、一般的な画面サイズの対応を次に示します。

  • 320dp: 通常のスマートフォンの画面(240x320 ldpi、320x480 mdpi、480x800 hdpi など)。
  • 480dp: 5 インチ未満の大画面スマートフォン(480x800 mdpi)。
  • 600dp: 7 インチ タブレット(600x1024 mdpi)。
  • 720dp: 10 インチ タブレット(720x1280 mdpi、800x1280 mdpi など)。

図 4 は、画面 dp 幅と、画面サイズおよび向きが一般的にどのように対応しているかを詳しく示しています。

図 4. さまざまな画面サイズをサポートするための推奨幅ブレークポイント

最小幅の修飾子の数値はすべて密度非依存ピクセルであることにご注意ください。これは、システムが(生ピクセル解像度ではなく)ピクセル密度を認識した後に利用できる画面スペースの大きさが重要であるためです。

利用可能な幅の修飾子を使用する

画面の最小幅に基づいてレイアウトを変更するのではなく、そのとき利用可能な幅または高さに基づいてレイアウトを変更したい場合があります。たとえば、2 ペイン レイアウトがあり、画面の幅が 600 dp 以上のときに必ずこのレイアウトを使用するとします。画面の幅は、デバイスが横向きか縦向きかに応じて変わる可能性があります。この場合は、次のように「利用可能な幅」の修飾子を使用します。

res/layout/main_activity.xml         # For handsets (smaller than 600dp available width)
res/layout-w600dp/main_activity.xml  # For 7” tablets or any screen with 600dp
                                     #   available width (possibly landscape handsets)

利用可能な高さを考慮する必要がある場合は、「利用可能な高さ」の修飾子を使用して同じことができます。たとえば、画面の高さが 600 dp 以上の画面の場合は layout-h600dp です。

向きの修飾子を追加する

「最小幅」の修飾子と「利用可能な幅」の修飾子の組み合わせでもすべてのサイズ バリエーションに対応できるかもしれませんが、縦向きと横向きを切り替えてユーザー エクスペリエンスを変更することも可能です。

それには、port 修飾子または land 修飾子をリソース ディレクトリ名に追加します。この修飾子は、必ず他のサイズ修飾子の後ろに追加してください。次に例を示します。

res/layout/main_activity.xml                # For handsets
res/layout-land/main_activity.xml           # For handsets in landscape
res/layout-sw600dp/main_activity.xml        # For 7” tablets
res/layout-sw600dp-land/main_activity.xml   # For 7” tablets in landscape

画面構成に関するすべての修飾子について詳しくは、リソースを提供するためのガイドの表 2 をご覧ください。

フラグメントで UI コンポーネントをモジュール化する

複数の画面サイズに合わせてアプリを設計するときは、UI の動作をアクティビティ間で不必要に重複させないようにします。そのためには、フラグメントを使用して UI ロジックを個別のコンポーネントに抽出する必要があります。フラグメントを組み合わせることで、大画面で動作させるときはマルチペイン レイアウトを作成でき、スマートフォンで動作させるときは個別のアクティビティに配置できます。

たとえば、あるニュースアプリで、タブレットでは左側に記事のリスト、右側に記事の全文が表示され、左側で記事を選択すると右側の記事ビューが更新されます。一方、スマートフォンではこの 2 つのコンポーネントはそれぞれ別の画面に表示され、リストから記事を選択すると、その記事を表示するために画面全体が切り替わります。

詳しくは、フラグメントを使った動的 UI の作成についての記事をご覧ください。

すべての画面サイズでテストする

UI を正しくスケーリングできるように、アプリをさまざまな画面サイズでテストすることが重要です。

Android 10(API レベル 29)以降では、サポートされるアスペクト比がさらに拡大しています。折りたたみ式デバイスの場合、フォーム ファクタは超縦長の細い画面(デバイスを折りたたんだ状態で 21:9 など)から 1:1 まで、さまざまです。

できるだけ多くのデバイスに対応するには、できるだけ多くの画面比率でアプリをテストする必要があります。

サポートできない画面比率がある場合は、従来の maxAspectRatiominAspectRatio を使用して、アプリが対処できる最大と最小の画面比率を指定できます。この比率範囲外の画面では、アプリが互換モードになる可能性があります。

下部のナビゲーション ビューに 5 つのアイコンが表示されている場合、Android 10(API レベル 29)以降を搭載しているデバイスでは、タップ ターゲットのサイズが最小の 2 インチになることが保証されます。互換性定義ドキュメントをご覧ください。

あらゆる画面サイズに対応する物理デバイスがない場合は、Android Emulator を使用すると、すべての画面サイズをエミュレートできます。

デバイスを購入せずに物理デバイスでテストする場合は、Firebase Test Lab を使用すると、Google データセンターのデバイスにアクセスできます。

特定の画面サイズのサポートを宣言する

アプリを特定の画面サイズでは動作しないようにする場合は、画面のサイズ変更量を制限したり、画面の構成に基づいてアプリをインストールできるデバイスを制限したりできます。詳しくは、画面サポートの制限の宣言をご覧ください。