lightbulb_outline Help shape the future of the Google Play Console, Android Studio, and Firebase. Start survey

Google Play 上のフィルタ

ユーザーが Google Play でダウンロードするアプリを検索したりブラウジングしたりすると、その結果はアプリと互換性のあるデバイスに基づいてフィルタリングされます。たとえば、アプリがカメラを必要とする場合、このアプリはカメラを搭載していないデバイスには表示されません。 このフィルタリング機能により、デベロッパーはアプリの配布を管理し、ユーザーに可能な限り最善のエクスペリエンスを保証できます。

Google Play でのフィルタリングは、複数のタイプのアプリ メタデータと設定を基準にしています。これには、マニフェストの宣言、必須ライブラリ、構造の依存関係、および対象地域や価格設定といった、Google Play デベロッパー コンソールで設定される一連のディストリビューション管理などが含まれます。

Google Play のフィルタリングは、一部をマニフェスト宣言と Android フレームワークの他の局面を基準にしていますが、実際のフィルタリング動作はこのフレームワークとは異なり、特定の API レベルに関係するものではありません。 このドキュメントでは、Google Play が使用する現行のフィルタリング ルールを指定します。

Google Play でのフィルタリングの仕組み

Google Play は以下に説明するフィルタ制限を使用して、Google Play アプリでアプリをブラウジングしたり、検索したりしているユーザーにアプリを表示するかどうかを決定します。

Google Play は、アプリを表示するかどうかを決定する際に、デバイスのハードウェア要件とソフトウェア要件を確認し、同時に携帯通信会社、ロケーション、他の特性も確認します。 次にこれらをアプリのマニフェスト ファイル、および公開の詳細で指定されている制限事項と依存関係に対して比較します。

フィルタルールに準じてアプリがデバイスと互換性があれば、Google Play からそのアプリがユーザーに表示されます。 互換性がなければ、Google Play は検索結果とカテゴリ ブラウジングでアプリを表示しません。Google Play 内でそのアプリの ID を直接示す詳細リンクをクリックしてアプリを明確に要求しても、表示されることはありません。

アプリで選択可能なフィルタを自由に組み合わせて使用できます。たとえば、アプリで minSdkVersion 要件の "4" を設定し、smallScreens="false" に設定して、そのアプリを Google Play にアップロードして、ヨーロッパ諸国(携帯通信会社)のみをターゲットにできます。 このように、Google Play のフィルタは 3 つの要件すべてに適合しないとデバイスでアプリが使用できないようにします。

すべてのフィルタリングの制限事項はアプリのバージョンと関連付けられており、バージョン間で変えることができます。 たとえば、あるユーザーがアプリをインストール済みであり、そのアプリをユーザーに表示しないアップデートを公開すると、ユーザーにはアップデートが利用可能であることがわかりません。

Google Play ウェブサイトでのフィルタリング

ユーザーが Google Play ウェブサイトをブラウジングする際には公開されているすべてのアプリが表示されます。 Google Play ウェブサイトでは、ユーザーが登録しているデバイスごとにアプリと互換性があるかどうかアプリの要件を比較し、デバイスと互換性のあるアプリだけを インストールできるようにします。

アプリのマニフェストに基づくフィルタリング

フィルタの多くはアプリのマニフェスト ファイル AndroidManifest.xml 内の要素によってトリガーされます(このマニフェスト ファイル内のすべてがフィルタリングをトリガーするわけではありません)。表 1 では、フィルタリングをトリガーために使用する必要のあるマニフェスト要素を示し、各要素のフィルタリングの仕組みについて説明しています。

表 1. Google Play 上でのフィルタリングに使用されるマニフェスト要素

マニフェスト要素 フィルタ名 フィルタの仕組み
<supports-screens> 画面サイズ

アプリは、<supports-screens> 要素の属性を設定することでサポート可能な画面サイズを示します。 アプリが公開されると、Google Play はこれらの属性を使用して、デバイスの画面サイズに基づき、アプリをユーザーに表示するかどうかを決定します。

一般的なルールとして、Google Play は、デバイスのプラットフォームが小さいレイアウトを大きな画面に表示できる一方で、大きなレイアウトを小さな画面に表示できるような調整はできないと想定しています。 そのため、アプリが「通常の」画面サイズのみのサポートを宣言している場合、Google Play は通常画面サイズのデバイスと大きい画面サイズのデバイスの両方でアプリを使用できるようにしますが、小さい画面サイズのデバイスでアプリを使用できないようにフィルタリングします。

アプリが <supports-screens> の属性を宣言していないと、Google Play はこの属性の規定値を使用します。規定値は API レベルによって異なります。 特に次の点に注意が必要です。

  • android: minSdkVersion または android: targetSdkVersion が 3 以下に設定されているアプリの場合、<supports-screens> 要素自体が未定義となり、どの属性も使用できません。 この場合、Google Play はアプリが通常の画面サイズ向けに設計されていると想定し、通常サイズ以上の画面のデバイスにアプリを表示します。

  • android: minSdkVersion または android: targetSdkVersion が 4 以上に設定されているアプリの場合、すべての属性のデフォルトは "true" となります。この場合、アプリはデフォルトですべての画面サイズをサポートするとみなされます。

例 1
マニフェストが <uses-sdk android:minSdkVersion="3"> を宣言し、<supports-screens> 要素を含んでいません。 結果:Google Play は、他のフィルタが適用されない限り、小さい画面サイズのデバイスのユーザーにはアプリを表示しませんが、通常の画面サイズと大きい画面サイズのデバイスのユーザーには表示します。

例 2
マニフェストが <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"> を宣言し、<supports-screens> 要素を含んでいません。 結果:Google Play は、他のフィルタが適用されない限り、すべてのデバイスのユーザーにアプリを表示します。

例 3
マニフェストが <uses-sdk android:minSdkVersion="4"> を宣言し、<supports-screens> 要素を含んでいません。 結果:Google Play は、他のフィルタが適用されない限り、すべてのユーザーにアプリを表示します。

アプリの画面サイズのサポートを宣言する方法については、<supports-screens>複数画面をサポートするを参照してください。

<uses-configuration> 端末構成:
キーボード、ナビゲーション、タッチスクリーン

アプリは特定のハードウェア機能を要求することがあり、Google Play は要求されたハードウェアを備えたデバイスにのみアプリを表示します。

例 1
マニフェストが <uses-configuration android:reqFiveWayNav="true" /> を含み、ユーザーが 5 方向ナビゲーション コントロールを備えていないデバイスでアプリを検索しています。結果:Google Play はユーザーにアプリを表示しません。

例 2
マニフェストが <uses-configuration> 要素を含んでいません。結果:Google Play は、他のフィルタが適用されない限り、すべてのユーザーにアプリを表示します。

詳細については、<uses-configuration> をご覧ください。

<uses-feature> 端末機能
name

アプリをデバイスに表示するために、特定のデバイス機能を要求できます。 この機能は Android 2.0(API レベル 5)で導入されました。

例 1
マニフェストに <uses-feature android:name="android.hardware.sensor.light" /> が含まれていて、ユーザーが光センサーを備えていないデバイスでアプリを検索しています。結果: Google Play はユーザーにアプリを表示しません。

例 2
マニフェストが <uses-feature> 要素を含んでいません。 結果:Google Play は、他のフィルタが適用されない限り、すべてのユーザーにアプリを表示します。

詳細については <uses-feature> を参照してください。

暗黙的な機能に基づいたフィルタリング:場合によっては、Google Play は <uses-permission> 要素から要求されたパーミッションを、<uses-feature> 要素で宣言されたものと同等の機能要件として解釈します。 以下の <uses-permission> を参照してください。

OpenGL-ES バージョン
openGlEsVersion

アプリは、<uses-feature android:openGlEsVersion="int"> 属性を使用して、デバイスが特定の OpenGL-ES バージョンをサポートすることを要求できます。

例 1
アプリは、マニフェストで openGlEsVersion を複数回指定して複数の OpenGL-ES バージョンを要求しています。 結果:Google Play は、示されたバージョンの中で最も新しいものをアプリが要求していると想定します。

例 2
アプリは OpenGL-ES バージョン 1.1 を要求し、ユーザーは OpenGL-ES バージョン 2.0 をサポートする端末でアプリを検索しています。結果: Google Play は、他のフィルタが適用されない限り、ユーザーにアプリを表示します。デバイスが OpenGL-ES バージョン X をサポートすることを通知すると、Google Play は X よりも前のバージョンもデバイスがサポートすると想定します。

例 3
ユーザーが OpenGL-ES のバージョンを通知しないデバイス(Android 1.5 以下を実行しているデバイスなど)でアプリを検索しています。 結果:Google Play は、OpenGL-ES 1.0 だけをサポートする端末だと認識します。Google Play は、openGlEsVersion を指定しないユーザーアプリ、またはOpenGL-ES バージョン 1.0 より新しいバージョンを指定しないアプリだけを表示します。

例 4
マニフェストが openGlEsVersion を指定していません。結果:Google Play は、他のフィルタが適用されない限り、すべてのユーザーにアプリを表示します。

詳細については、<uses-feature> をご覧ください。

<uses-library>ソフトウェア ライブラリ

アプリは、デバイスで動作するために特定の共有ライブラリを要求できます。

例 1
アプリが com.google.android.maps ライブラリを必要とし、ユーザーが com.google.android.maps ライブラリを持たないデバイスでアプリを検索しています。結果:Google Play はユーザーにアプリを表示しません。

例 2
マニフェストが <uses-library> 要素を含んでいません。結果:Google Play は、他のフィルタが適用されない限り、すべてのユーザーにアプリを表示します。

詳細については、<uses-library> をご覧ください。

<uses-permission> 厳密に言えば、Google Play は <uses-permission> 要素に基づいたフィルタリングを行いません。 ただし、要素を読み込んで、アプリに <uses-feature> 要素で正しく宣言されていない可能性のあるハードウェア機能の要件を備えているかどうか判断します。 たとえば、アプリが CAMERA パーミッションを要求しながら android.hardware.camera<uses-feature> 要素を宣言していないと、Google Play はアプリでカメラが必要であるとみなし、カメラが搭載されていないデバイスのユーザーにアプリを表示しません。

一般的には、アプリがハードウェア関連のパーミッションを要求する場合、Google Play は <uses-feature> 宣言に対応するものがない場合でも、基本的なハードウェア機能を必要としていると想定します。 次に、Google Play は、<uses-feature> 宣言で暗黙指定される機能に基づき、フィルタリングを設定します。

ハードウェア機能を暗黙指定するパーミッションの一覧については、<uses-feature> 要素のドキュメントを参照してください。

<uses-sdk>最小フレームワーク バージョン(minSdkVersion

アプリは最小 API レベルを要求できます。

例 1
マニフェストには <uses-sdk android:minSdkVersion="3"> があり、アプリは API レベル 3 で導入された API を使います。ユーザーは API レベル 2 の端末でアプリを検索しています。 結果:Google Play はユーザーにアプリを表示しません。

例 2
マニフェストには minSdkVersion がなく、アプリは API レベル 3 で導入された API を使います。ユーザーは API レベル 2 の端末でアプリを検索しています。 結果:Google Play は minSdkVersion が「1」で、アプリがすべてのバージョンの Android と互換性があると想定します。Google Play はユーザーにアプリを表示し、ユーザーがアプリをダウンロードできるようにします。アプリは実行時にクラッシュします。

2 番目のシナリオが発生しないようにするため、minSdkVersion を常に宣言することをお勧めします。詳細については、android:minSdkVersion を参照してください。

最大フレームワーク バージョン(maxSdkVersion

廃止されました。Android 2.1 以降は maxSdkVersion 属性の確認または適用を行わず、maxSdkVersion がアプリのマニフェストに設定されていても SDK はコンパイルしません。 maxSdkVersion がコンパイルされているデバイスの場合、Google Play はこれを遵守し、フィルタリングに使用します。

maxSdkVersion の宣言は推奨されません。詳細については、android:maxSdkVersion を参照してください。

拡張マニフェスト フィルタ

Google Play では、表 1 のマニフェスト要素の他に、表 2 の拡張マニフェスト要素に基づいたアプリのフィルタリングも実行できます。

これらのマニフェスト要素と、これらの要素がトリガーするフィルタリングは例外的なユースケースのみに対応します。 これらの要素は、アプリのディストリビューションに厳密なコントロールが必要な特定のタイプの高性能ゲームと、同様のアプリ向けに設計されています。 大半のアプリは、このフィルタを使用すべきではありません

表 2. Google Play フィルタリング用の拡張マニフェスト要素

マニフェスト要素 まとめ
<compatible-screens>

Google Play は端末画面サイズと密度が <compatible-screens> 要素の画面設定(<screen> 要素で宣言)のいずれにも適合しない場合、アプリをフィルタリングします。

警告: 通常は、このマニフェスト要素を使用すべきではありません。 この要素を使用すると、指定していない画面サイズと密度のすべての組み合わせが除外されることになり、アプリの潜在的なユーザー ベースが大幅に減少する可能性があります。 代わりに <supports-screens> マニフェスト要素(表 1 に記載)を使用して、考慮に入れていない画面設定に対して、代替リソースを使用した画面の互換性モードを有効にすることをお勧めします。

<supports-gl-texture>

Google Play はアプリでサポートされる 1 つ以上の GL テクスチャ圧縮フォーマットがデバイスで同様にサポートされない場合、アプリをフィルタリングします。

その他のフィルタ

次の表で説明しているように、Google Play はその他のアプリ特性を使用して、所定のデバイスを使用している特定のユーザーについて、アプリの表示 / 非表示を判断します。

表 3. Google Play でのフィルタリングに影響するアプリと公開の特性

フィルタ名 フィルタの仕組み
公開状況

公開されているアプリのみが Google Play 内での検索とブラウジングに表示されます。

アプリの公開が取り消されても、ユーザーの [Downloads] 領域で、購入したアプリ、インストールしたアプリ、または最近アンインストールしたアプリに表示されている場合、インストールが可能です。

アプリが保留状態の場合、ユーザーの [Download] 領域に表示されていても、ユーザーは再インストールしたりアップデートしたりできません。

価格設定状況

すべてのユーザーに有料アプリが表示されるわけではありません。有料アプリが表示されるためには、デバイスに SIM カードが搭載されていて、Android 1.1 以降を実行している必要があります。また、デバイスが有料アプリを使用できる国にある(SIM キャリアで判別)必要があります。

対象国の指定

アプリを Google Play にアップロードすると、[Pricing and Distribution] でアプリを配布する国を選択できます。 これで、アプリは選択した国でのみ入手可能となります。

CPU アーキテクチャ(ABI)

特定の CPU アーキテクチャ(ARM EABI v7 または x86 など)をターゲットとするネイティブ ライブラリを含むアプリは、そのアーキテクチャをサポートするデバイスのみに表示されます。 NDK とネイティブ ライブラリの使用について詳しくは、Andorid NDK についてを参照してください。

コピー保護されたアプリ

Google Play はデベロッパー コンソールのコピー保護機能をサポートしなくなりました。また、この機能に基づくアプリのフィルタリングも実行しません。 アプリを安全に保護するには、代わりにアプリのライセンス付与を使用してください。 詳細については、コピー保護の置き換え(Replacement for Copy Protection)を参照してください。

異なるフィルタを使用した複数の APK の公開

一部の特定の Google Play フィルタにより、異なるデバイス構成に別の APK を提供するため、同じアプリの複数の APK を公開できるようになっています。 たとえば、高品質のグラフィック アセットを使用するビデオ ゲームを作成している場合、別々のテクスチャ圧縮フォーマットをサポートする 2 つの APK を作成できます。 この方法で、デバイスごとの設定に必要なテクスチャーのみを含めることで、APK ファイルのサイズを小さくすることができます。 テクスチャ圧縮フォーマットに対する各デバイスのサポート状況に応じて、Google Play は各デバイスに対して、そのデバイスのサポートを宣言した APK を配布します。

現時点では、Google Play では各 APK が次の設定に基づいて別々のフィルタを提供する際にのみ、同じアプリの複数の APK を公開できます。

  • OpenGL テクスチャ圧縮フォーマット

    <supports-gl-texture> 要素を使用。

  • 画面サイズ(画面密度も指定可能)

    <supports-screens> 要素または <compatible-screens> 要素を使用。

  • API レベル

    <uses-sdk> 要素を使用。

  • CPU アーキテクチャ(ABI)

    特定の CPU アーキテクチャ(ARM EABI v7 または x86 など)を対象とする Android NDK で構築されたネイティブ ライブラリの組み込みによる。

他のすべてのフィルタも通常通り機能しますが、ある APK を Google Play の同じアプリのリスト内の別の APK と区別できるのはこの 4 つのフィルタだけです。 たとえば、デバイスにカメラが搭載されているかどうかのみを基準として異なる APK が存在する場合、同じアプリに複数の APK を公開することはできません。

警告: 同じアプリに複数の APK を公開することは拡張機能とみなされます。大部分のアプリは、広範囲のデバイス設定をサポートする APK を 1 つだけ公開すべきです。 複数の APK を公開する場合、フィルタ固有のルールに従う必要があります。また、設定ごとに適切なアップデート パスを確保するため、各 APK のバージョン コードに特別な注意を払う必要があります。

Google Play で複数の APK を公開する方法について詳しくは、複数の APK サポートをご覧ください。