デバイスの適合性の概要

Android はスマートフォン、タブレット、テレビなど、さまざまな種類のデバイスで動作するように設計されています。デバイスの範囲が広いため、アプリの潜在的ユーザーは多数います。こうしたあらゆるデバイスでアプリを成功させるには、機能のばらつきに対応し、さまざまな画面構成に適応する柔軟なユーザー インターフェースを提供する必要があります。

こうした目標の達成に向けた取り組みを促進するために、Android には、構成に固有のアプリリソース（各画面サイズで異なる XML レイアウトなど）を静的ファイルで提供可能な、動的なアプリ フレームワークが用意されています。Android は、現在のデバイス構成に基づいて適切なリソースを読み込みます。そのため、アプリの設計と追加のアプリリソースに関する計画を事前に立てることで、さまざまなデバイスで最適化されたユーザー エクスペリエンスを提供する単一のアプリ パッケージ（APK）を公開できます。

ただし必要な場合は、アプリの機能要件を指定し、Google Play ストアからアプリをインストールできるデバイスのタイプを管理することができます。このページでは、アプリに対応するデバイスを管理する方法と、適切なユーザーに表示できるようにアプリを準備する方法について説明します。アプリをさまざまなデバイスに適応させる方法について詳しくは、さまざまなデバイスのサポートをご覧ください。

「適合性」とは

Android 開発について調べていると、さまざまな状況で「適合性」という言葉を目にすると思います。適合性には、「デバイスの適合性」と「アプリの適合性」の 2 種類があります。

Android はオープンソース プロジェクトであるため、どのハードウェア メーカーも Android オペレーティング システムを搭載したデバイスを開発できます。ただし、「Android 対応」のデバイスは、Android 実行環境向けに作成されたアプリを適切に実行できる必要があります。Android 実行環境の詳細は Android 互換性プログラムで定義されており、「Android 対応」のデバイスとみなされるには互換性テストスイート（CTS）に合格する必要があります。

アプリ デベロッパーが、デバイスが Android 対応かどうかを気にする必要はありません。Google Play ストアを利用できるのは Android 対応のデバイスだけです。そのため、Google Play ストアからアプリをインストールするユーザーは間違いなく Android 対応のデバイスを使用していると言えます。

ただし、考えられるすべてのデバイス構成にアプリを対応させるかどうかについては検討する必要があります。Android はさまざまなデバイス構成で動作するため、デバイスによっては使用できない機能もあります。たとえば、一部のデバイスにはコンパス センサーが搭載されていません。アプリの主要機能でコンパス センサーを使用する必要がある場合、そのアプリはコンパス センサーが搭載されているデバイスでしか使用できません。

デバイスでのアプリの使用可否の管理

Android は、アプリがプラットフォーム API を介して利用できるさまざまな機能をサポートしています。機能にはハードウェア ベースのもの（コンパス センサーなど）とソフトウェア ベースのもの（アプリ ウィジェットなど）があり、また、プラットフォームのバージョンに依存するものもあります。すべてのデバイスがすべての機能をサポートしているわけではありません。そのため場合によっては、アプリで必要な機能に基づいて、デバイスでのアプリの使用可否を管理する必要があります。

アプリのユーザーベースを最大限に拡大するには、1 つの APK でできる限り多くのデバイス構成をサポートするように努める必要があります。これは多くの場合、実行時に必須ではない機能を無効にし、構成ごとに代替手段（各画面サイズで異なるレイアウトなど）をアプリリソースに提供することによって達成できます。ただし必要な場合は、以下のデバイス特性に基づいて、Google Play ストアを通じてデバイスでのアプリの使用を制限することができます。

デバイスの機能

デバイスの機能に基づいてアプリの使用可否を管理できるようにするために、Android では、一部のデバイスで使用できない可能性があるハードウェアまたはソフトウェア機能に対して機能 ID を定義しています。たとえば、コンパス センサーの機能 ID は FEATURE_SENSOR_COMPASS、アプリ ウィジェットの機能 ID は FEATURE_APP_WIDGETS です。

必要に応じて、アプリのマニフェスト ファイルの <uses-feature> 要素で特定の機能を宣言することで、デバイスがその機能を搭載していない場合にユーザーがアプリをインストールできないようにすることができます。

たとえば、コンパス センサーが搭載されていないデバイスでは適切に機能しないアプリの場合、次のマニフェスト タグでコンパス センサーが必要であることを宣言できます。

    <manifest ... >
        <uses-feature android:name="android.hardware.sensor.compass"
                      android:required="true" />
        ...
    </manifest>

Google Play ストアは、アプリに必要な機能を各ユーザーのデバイスで使用可能な機能と比較して、アプリがそのデバイスに対応しているかどうかを判断します。アプリに必要な機能がデバイスに搭載されていない場合、ユーザーはそのアプリをインストールできません。

ただし、アプリの主要な動作において必須ではないデバイスの機能については、required 属性を "false" に設定して、実行時にそのデバイスの機能を確認するようにしてください。現在のデバイスでアプリ機能を使用できない場合は、対応するアプリ機能のグレースフル デグラデーションを実行します。たとえば、ある機能を使用できるかどうかを照会するには、次のように hasSystemFeature() を呼び出します。

Kotlin

    if (!packageManager.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
        // This device does not have a compass, turn off the compass feature
        disableCompassFeature()
    }

Java

    PackageManager pm = getPackageManager();
    if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
        // This device does not have a compass, turn off the compass feature
        disableCompassFeature();
    }

Google Play ストアからアプリを入手できるユーザーを指定するフィルタの一覧については、Google Play 上のフィルタをご覧ください。

注: 一部のシステム パーミッションでは、デバイス機能が暗黙的に必要になります。たとえば、アプリで BLUETOOTH に対するアクセス権をリクエストする場合、FEATURE_BLUETOOTH デバイス機能が暗黙的に必要になります。この機能に基づくフィルタを無効にし、Bluetooth 機能のないデバイスでアプリを使用できるようにするには、<uses-feature> タグで required 属性を "false" に設定します。暗黙的に必要なデバイス機能について詳しくは、機能要件を暗黙的に伴うパーミッションをご覧ください。

プラットフォームのバージョン

動作可能な Android プラットフォームのバージョン（Android 4.0、Android 4.4 など）はデバイスごとに異なります。プラットフォームの後継バージョンでは、以前のバージョンでは使用できない新しい API が追加されることがよくあります。使用可能な API を示すために、プラットフォームのバージョンごとに API レベルが指定されています。たとえば、Android 1.0 は API レベル 1、Android 4.4 は API レベル 19 です。

<uses-sdk> マニフェスト タグとその minSdkVersion 属性を使用して API レベルを指定することで、アプリが対応している最小バージョンを宣言できます。たとえば、Calendar Provider API は Android 4.0（API レベル 14）で追加されました。これらの API がないとアプリが機能できない場合は、アプリの最小サポート バージョンとして API レベル 14 を宣言する必要があります。

minSdkVersion 属性では、アプリが対応している最小バージョンを宣言します。また、targetSdkVersion 属性では、アプリが最適化されている最も新しいバージョンを宣言します。

ただし、<uses-sdk> 要素の属性は、build.gradle ファイルの対応するプロパティでオーバーライドされることに注意してください。そのため、Android Studio を使用している場合は、minSdkVersion と targetSdkVersion の各値を代わりに指定する必要があります。

    android {
      defaultConfig {
        applicationId 'com.example.myapp'

        // Defines the minimum API level required to run the app.
        minSdkVersion 15

        // Specifies the API level used to test the app.
        targetSdkVersion 28

        ...
      }
    }

build.gradle ファイルについて詳しくは、ビルドの設定方法をご覧ください。

Android の各後継バージョンは、以前のプラットフォーム バージョンの API を使用してビルドされたアプリに対する適合性を備えています。そのため、アプリは Android の将来のバージョンにも対応します（作成時に指定した Android API を使用できます）。

注: targetSdkVersion 属性で指定したバージョンより新しいプラットフォームにもアプリをインストールできます。ただし、この属性は新しいバージョンでの動作変更にアプリが対応しているかどうかをシステムに示すため、重要な属性です。targetSdkVersion を最新バージョンに更新しない場合、システムは、アプリを最新バージョンで実行する際になんらかの下位互換性の動作が必要であると仮定します。たとえば、Android 4.4 での動作変更のうち AlarmManager API を使用して作成されたアラームは、デフォルトでは今のところ不正確なため、システムはアプリのアラームをまとめて処理し、システム電源を維持することができます。ただし、対象 API レベルが 19 未満の場合、システムはアプリに対する以前の API の動作を保持します。

ただし、最近のプラットフォーム バージョンで追加された API をアプリで使用しているものの、主要機能でその API が不要な場合は、API レベルを実行時に確認し、API レベルが低すぎる場合は対応する機能のグレースフル デグラデーションを実行する必要があります。この場合、minSdkVersion をアプリの主要機能に対して設定可能な最小値に設定し、現在のシステムのバージョン（SDK_INT）を、確認する API レベルに対応する Build.VERSION_CODES のコードネーム定数と比較します。次に例を示します。

Kotlin

    if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
        // Running on something older than API level 11, so disable
        // the drag/drop features that use <code><a href="/reference/android/content/ClipboardManager.html">ClipboardManager</a></code> APIs
        disableDragAndDrop()
    }

Java

    if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
        // Running on something older than API level 11, so disable
        // the drag/drop features that use <code><a href="/reference/android/content/ClipboardManager.html">ClipboardManager</a></code> APIs
        disableDragAndDrop();
    }

画面構成

Android は、スマートフォン、タブレット、テレビなど、さまざまなサイズのデバイスで実行されます。Android ではデバイスを画面のタイプで分類するために、画面サイズ（画面の物理サイズ）と画面密度（画面の物理的なピクセル密度。DPI と呼ばれます）という 2 つの特性をデバイスごとに定義します。さまざまな構成を単純化するために、Android ではこれらの構成をグループ分けして、ターゲットを設定しやすくしています。

  • 一般化された 4 つのサイズ: スモール、ノーマル、ラージ、エクストラ ラージ
  • 一般化された密度: mdpi（中密度）、hdpi（高密度）, xhdpi（超高密度）、xxhdpi（超超高密度）など

デフォルトでは、アプリはすべての画面サイズと画面密度に対応しています。これは、システムが各画面の UI レイアウトと画像リソースに対して適切な調整を必要に応じて行うためです。ただし、各画面サイズ用の特別なレイアウトと、一般的な画面密度用に最適化されたビットマップ画像を追加することにより、各画面構成のユーザー エクスペリエンスを最適化する必要があります。

各画面用の代替リソースを作成する方法と、必要に応じてアプリを特定の画面サイズに制限する方法については、さまざまな画面のサポートをご覧ください。

ビジネス上の理由によるアプリの使用の制限

デバイスの特性に基づいてアプリの使用を制限することに加え、ビジネス上の理由や法的な理由でアプリの使用を制限しなければならない場合もあります。たとえば、ロンドンの地下鉄の時刻表アプリは、英国以外のユーザーには役に立ちそうにありません。このような場合のために、Google Play ストアでは、技術面以外の理由（ユーザーの場所や携帯通信会社など）でアプリの使用を制限するためのフィルタ オプションを Play Console で提供しています。

技術面の適合性（必要なハードウェア コンポーネントなど）のフィルタは、常に APK ファイルに含まれている情報に基づきます。ただし、技術面以外の理由（地理的場所など）によるフィルタは、常に Google Play Console で処理されます。

関連情報:

リソースの提供
アプリリソースをアプリコードと区別するために Android アプリをどのような構造にするかに関する情報（特定のデバイス構成用の代替リソースの提供方法など）。
Google Play 上のフィルタ
Google Play ストアにおいてアプリが各種デバイスにインストールされないようにするためのさまざまな方法に関する情報。

その他の情報:

システム パーミッション
アプリで特定の API を使用する場合にユーザーの同意を求める権限システムによって、Android でその API へのアプリからのアクセスを制限する方法。
次へ
画面の互換性について