デバイスの適合性の概要

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

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

ただし必要な場合は、アプリの機能要件を指定し、Google Play ストアからアプリをインストールできるデバイスのタイプを管理することができます。このドキュメントでは、アプリにアクセスできるデバイスを制御する方法と、適切なユーザーに表示できるようにアプリを準備する方法について説明します。

「適合性」とは

Android 開発では、デバイスの互換性とアプリの互換性の 2 種類の互換性があります。

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

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

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

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

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

アプリのユーザーベースを最大限に拡大するには、1 つの APK または AAB でできる限り多くのデバイス構成をサポートします。これは多くの場合、実行時に必須ではない機能を無効にし、構成ごとに代替手段（各画面サイズで異なるレイアウトなど）をアプリリソースに提供することによって達成できます。必要に応じて、以下のデバイス特性に基づいて、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 doesn't have a compass. Turn off the compass feature.
    disableCompassFeature()
}

Java

PackageManager pm = getPackageManager();
if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
    // This device doesn't have a compass. Turn off the compass feature.
    disableCompassFeature();
}

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

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

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

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

build.gradle ファイルに minSdkVersion 値と targetSdkVersion 値を指定する必要があります。

Kotlin

android {
    defaultConfig {
        applicationId = "com.example.myapp"

        // Defines the minimum API level required to run the app.
        minSdkVersion(30)

        // Specifies the API level used to test the app.
        targetSdkVersion(33)
        ...
    }
}

Groovy

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

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

        // Specifies the API level used to test the app.
        targetSdkVersion 33
        ...
    }
}

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

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

注: targetSdkVersion 属性で指定したバージョンより新しいプラットフォームにもアプリをインストールできます。ただし、この属性は新しいバージョンでの動作変更にアプリが対応しているかどうかをシステムに示すため、重要な属性です。targetSdkVersion を最新バージョンに更新しない場合、システムは、アプリを最新バージョンで実行する際に下位互換性が必要であると仮定します。

ただし、最近のプラットフォーム バージョンで追加された 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 and drop features that use ClipboardManager APIs.
    disableDragAndDrop()
}

Java

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
    // Running on something older than API level 11, so disable
    // the drag and drop features that use ClipboardManager APIs.
    disableDragAndDrop();
}

画面構成

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

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

デフォルトでは、アプリはすべての画面サイズと画面密度に対応しています。これは、システムが各画面の UI レイアウトと画像リソースに対して適切な調整を必要に応じて行うためです。一般的な画面密度用に最適化されたビットマップ画像を用意します。

柔軟なレイアウトを可能な限り使用して、ユーザー エクスペリエンスを最適化します。縦向きと横向き、または大きなウィンドウ サイズと小さなウィンドウ サイズなど、構成の大きな変更に対応するレイアウトがある場合は、構成の細かい変更にも柔軟に対応できる代替レイアウトを提供することを検討してください。これにより、タブレット、スマートフォン、折りたたみ式デバイスなどのフォーム ファクタでのユーザー エクスペリエンスが向上します。また、マルチウィンドウ モードでウィンドウのサイズが変更された場合にも役立ちます。

画面ごとに代替リソースを作成する方法と、必要に応じてアプリを特定の画面サイズに制限する方法については、画面互換性の概要と大画面アプリの品質に関するガイドラインをご覧ください。

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

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

技術的な互換性（必要なハードウェア コンポーネントなど）に基づくフィルタリングは、常に APK ファイルまたは AAB ファイルに含まれる情報に基づいて行われます。ただし、技術的でない理由（地理的場所など）によるフィルタは、常に Google Play Console で処理されます。

関連ドキュメント:

アプリのリソースの概要

アプリリソースをアプリコードと区別するために Android アプリをどのような構造にするかに関する情報（特定のデバイス構成用の代替リソースの提供方法など）。

Google Play 上のフィルタ

Google Play ストアにおいてアプリが各種デバイスにインストールされないようにするためのさまざまな方法に関する情報。

Android での権限

アプリで特定の API を使用する場合にユーザーの同意を求める権限システムによって、Android でその API へのアプリからのアクセスを制限する方法。