Android は、スマートフォン、タブレット、テレビなど、さまざまなデバイスで動作するように設計されています。幅広いデバイスにより、アプリの潜在的なユーザー層が膨らみます。アプリがすべてのデバイスで成功するには、機能のばらつきを許容し、さまざまな画面構成に適応する柔軟なユーザー インターフェースを提供する必要があります。
デバイスの互換性を維持するため、Android には動的アプリ フレームワークが用意されています。このフレームワークでは、構成固有のアプリリソース(画面サイズごとに異なる XML レイアウトなど)を静的ファイルで提供できます。次に、Android は現在のデバイス構成に基づいて適切なリソースを読み込みます。アプリの設計と追加のアプリリソースを考慮して、単一のアプリケーション パッケージ(APK)を公開し、さまざまなデバイスでのユーザー エクスペリエンスを最適化できます。
必要に応じて、アプリの機能要件を指定したり、Google Play ストアからアプリをインストールできるデバイスの種類を制御したりできます。このドキュメントでは、アプリにアクセスできるデバイスを制御する方法と、アプリが適切なユーザーにリーチできるように準備する方法について説明します。
「適合性」とは
Android 開発には、デバイスの互換性とアプリの互換性の 2 種類の互換性があります。
Android はオープンソース プロジェクトであるため、ハードウェア メーカーは Android オペレーティング システムを搭載したデバイスをビルドできます。ただし、デバイスが「Android 互換」となるのは、Android 実行環境用に作成されたアプリを正しく実行できる場合のみです。Android 実行環境の詳細は、Android 互換性プログラムで定義されています。互換性があると見なされるには、各デバイスが互換性テストスイート(CTS)に合格している必要があります。
Google Play ストアが含まれるのは Android 互換デバイスのみであるため、アプリ デベロッパーはデバイスが 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 でのフィルタのドキュメントをご覧ください。
プラットフォームのバージョン
デバイスによって、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 と互換性を持たせることができます。
ただし、最新のプラットフォーム バージョンで追加された 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 つの汎用サイズ: Small、normal、large、xlarge
- 汎用密度の種類には mdpi(中)、hdpi(高)、xhdpi(超高)、xxhdpi(超超高)など
デフォルトでは、各画面で必要に応じて UI レイアウトと画像リソースがシステムによって調整されるため、アプリはすべての画面サイズと画面密度に対応しています。一般的な画面密度に合わせて最適化されたビットマップ画像を提供する。
可能な限り柔軟なレイアウトを使用して、ユーザー エクスペリエンスを最適化してください。 縦向きと横向き、または大きいウィンドウ サイズと小さいウィンドウ サイズなど、構成の大幅な変更に対応したレイアウトがある場合は、構成の小さな変更に柔軟に対応できる代替レイアウトの提供を検討してください。これにより、タブレット、スマートフォン、折りたたみ式デバイスなどのフォーム ファクタでのユーザー エクスペリエンスが向上します。また、マルチウィンドウ モードでウィンドウのサイズが変更される場合にも有用です。
画面ごとに代替リソースを作成する方法や、必要に応じてアプリを特定の画面サイズに制限する方法については、画面互換性の概要と大画面アプリの品質に関するガイドラインをご覧ください。
ビジネス上の理由でアプリを利用できるかどうかを管理する
デバイスの特性に基づいてアプリの利用を制限するだけでなく、業務上または法律上の理由により、アプリの利用を制限しなければならない場合もあります。このような状況に対応するために、Google Play ストアの Google Play Console にはフィルタリング オプションが用意されています。このオプションを使用すると、ユーザーの言語 / 地域や携帯通信会社など、技術面以外の理由でアプリを利用可能にするかどうかを制御できます。
必要なハードウェア コンポーネントなどの技術的な互換性のフィルタリングは、常に APK または AAB ファイル内に含まれる情報に基づいて行われます。ただし、地域などの技術的理由によるフィルタリングは、常に Google Play Console で処理されます。
参考情報:
- アプリリソースの概要
- 特定のデバイス構成に対して代替リソースを提供する方法など、Android アプリがアプリのリソースをアプリコードから分離する構造に関する情報。
- Google Play でのフィルタ
- Google Play ストアで、別のデバイスへのアプリのインストールを防ぐさまざまな方法についての情報。
- Android での権限
- アプリが特定の API を使用する際にユーザーの同意を必要とする権限システムを使用して、特定の API へのアプリのアクセスを Android で制限する仕組み。