デバイスの適合性の概要

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 API を使用しつつ、将来のバージョンの Android と互換性を持たせることができます。

注: 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 へのアプリからのアクセスを制限する方法。