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 または 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 ストアは、アプリに必要な機能を各ユーザーのデバイスで使用可能な機能と比較して、アプリがそのデバイスに対応しているかどうかを判断します。デバイスにアプリに必要な機能がすべて搭載されていない場合、ユーザーはアプリをインストールできません。
ただし、アプリの主要な動作において必須ではないデバイスの機能については、require a
device feature, set the
required
attribute to "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 上のフィルタ をご覧ください。
プラットフォームのバージョン
デバイスによっては、Android 12 や Android 13 など、異なるバージョンの Android プラットフォームが搭載されている場合があります。プラットフォームの後継バージョンでは、以前のバージョンで使用できない新しい 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(36) ... } }
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 36 ... } }
build.gradle ファイルの詳細については、
ビルドを設定するをご覧ください。
Android の各後継バージョンは、以前のプラットフォーム バージョンの API を使用してビルドされたアプリに対する適合性を備えています。そのため、アプリは Android の将来のバージョンにも対応します(作成時に指定した Android 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 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 ストアでは、技術面以外の理由(ユーザーの言語 / 地域や携帯通信会社など)でアプリの使用を制限するためのフィルタ オプションを Google Play Console で提供しています。
技術面の適合性(必要なハードウェア コンポーネントなど)のフィルタは、常に APK ファイルまたは AAB ファイルに含まれている情報に基づきます。ただし、技術面以外の理由(地理的場所など)によるフィルタは、常に Google Play Consoleで処理されます。
その他のリソース:
- アプリのリソースの概要
- アプリリソースをアプリコードと区別するために Android アプリをどのような構造にするかに関する情報(特定のデバイス構成用の代替リソースの提供方法など)。
- Google Play 上のフィルタ
- Google Play ストアにおいてアプリが各種デバイスにインストールされないようにするためのさまざまな方法に関する情報。
- Android での権限
- アプリで特定の API を使用する場合にユーザーの同意を求める権限システム によって、Android でその API へのアプリからのアクセスを制限する方法。