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 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(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 レベルが低すぎる場合は、対応する機能のグレースフル デグラデーションを行います。この場合は、アプリの主要な機能として 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 へのアクセスを制限する方法。