Google Play は、アプリ マニフェストで宣言されている <uses-feature> 要素を使用して、ハードウェアおよびソフトウェアの機能要件を満たしていないデバイスからアプリを除外します。

アプリが必要とする機能を指定すると、Google Play に、すべてのユーザーに対してはなく、アプリの機能要件を満たすデバイスのユーザーのみにアプリを表示させることが可能になります。

Google Play がフィルタリングの基準として機能を使用する、その仕組みについての重要な情報は、Google Play と機能ベースのフィルタリングのセクションをご覧ください。

構文:
<uses-feature
  android:name="string"
  android:required=["true" | "false"]
  android:glEsVersion="integer" />
上位の要素:
<manifest>
説明:

アプリが使用するハードウェア機能またはソフトウェア機能を 1 つ宣言します。

<uses-feature> 宣言の目的は、アプリが依存するハードウェア機能とソフトウェア機能のセットをすべての外部エンティティに通知することです。この要素には required 属性があります。この属性により、「宣言された機能が必須で、その機能なしではアプリは動作しない」または「その機能がある方が望ましいが、その機能なしでもアプリは動作する」のいずれかを指定できます。

機能のサポートは Android デバイスによって異なる可能性があるため、アプリが使用するデバイス変数の機能を説明できるようにするうえで、<uses-feature> 要素は重要な役割を果たします。

アプリが宣言する使用可能な機能のセットは、Android PackageManager が使用可能にした機能定数のセットに対応しています。機能定数のリストは、このドキュメントの機能リファレンスのセクションに掲載されています。

各機能を個別の <uses-feature> 要素で指定する必要があるため、アプリが複数の機能を必要とする場合は、複数の <uses-feature> 要素を宣言します。たとえば、デバイスで Bluetooth 機能とカメラ機能の両方を必要とするアプリでは、次の 2 つの要素を宣言します。

<uses-feature android:name="android.hardware.bluetooth" android:required="true" />
<uses-feature android:name="android.hardware.camera.any" android:required="true" />

一般的には、アプリが必要とするすべての機能に対して、常に <uses-feature> 要素を宣言します。

宣言された <uses-feature> 要素は情報のみです。つまり、アプリのインストール前に、これと一致する機能がデバイスでサポートされているかどうかを Android システム自体がチェックすることはありません。

しかし、他のサービス(Google Play など)やアプリは、アプリの処理や操作の一環として、そのアプリの <uses-feature> 宣言をチェックすることがあります。そのため、アプリが使用する機能をすべて宣言することは非常に重要です。

機能によっては、使用する Open GL のバージョン(glEsVersion で宣言)など、機能のバージョンを定義できる特定の属性が存在する場合があります。カメラなど、デバイス用に存在するかしないかの機能は name 属性を使用して宣言されています。

<uses-feature> 要素は API レベル 4 以上を搭載したデバイスでのみアクティブになりますが、minSdkVersion が「3」以下であっても、すべてのアプリにこの要素を追加してください。古いバージョンのプラットフォームを搭載したデバイスは、この要素を無視します。

注: 機能を宣言する場合、必要に応じて権限をリクエストする必要もあることを忘れないでください。たとえば、アプリが Camera API にアクセスするには、CAMERA 権限をリクエストする必要があります。権限をリクエストすることで、アプリは適切なハードウェアとソフトウェアへのアクセス権を取得できます。アプリで使用する機能を宣言することで、デバイスの適切な互換性を確保できるのです。

属性:
android:name
アプリが使用する 1 つのハードウェア機能またはソフトウェア機能を、記述子文字列として指定します。有効な属性値のリストは、ハードウェア機能セクションとソフトウェア機能セクションにあります。属性値では、大文字と小文字が区別されます。
android:required
android:name で指定された機能がアプリにとって必須かどうかを示すブール値。
  • 機能に対して android:required="true" を宣言することは、指定された機能がデバイスに存在しない場合、アプリが機能しない、または機能するように設計されていないことを示します。
  • 機能に対して android:required="false" を宣言することは、アプリは、デバイスにその機能が存在すれば使用するが、指定された機能がなくとも必要に応じて作動するよう設計されていることを示します。

android:required のデフォルト値は "true" です。

android:glEsVersion
アプリが必要とする OpenGL ES バージョン。上位 16 ビットはメジャー番号を表し、下位 16 ビットはマイナー番号を表します。たとえば、OpenGL ES バージョン 2.0 を指定するには、値を「0x00020000」に設定します。また、OpenGL ES 3.2 を指定するには、値を「0x00030002」に設定します。

アプリのマニフェストに指定できる android:glEsVersion 属性は最大で 1 つです。複数の値を指定すると、数値が最も大きい android:glEsVersion が使用され、他の値は無視されます。

android:glEsVersion 属性を指定していないアプリは、すべての Android 搭載デバイスでサポートされる OpenGL ES 1.0 のみを必要とするものと見なされます。

プラットフォームが特定の OpenGL ES バージョンをサポートしているアプリの場合は、それより下位の OpenGL ES バージョンもすべてサポートしていると想定できます。したがって、OpenGL ES 1.0 と OpenGL ES 2.0 の両方を必要とするアプリに対しては、OpenGL ES 2.0 が必須であることを指定します。

複数の OpenGL ES バージョンで動作可能なアプリは、必要とする OpenGL ES のバージョンで最も数値の低いものだけを指定します。(それより上位の OpenGL ES が使用可能かどうかは、実行時にチェックできます)。

サポートされている OpenGL ES バージョンを実行時にチェックする方法など、OpenGL ES の詳細な使用方法については、OpenGL ES API ガイドをご覧ください。

導入時の API レベル:
API レベル 4
関連項目:

Google Play と機能に基づくフィルタリング

Google Play は、ユーザーに表示するアプリをフィルタします。これによりユーザーは、自分のデバイスと互換性があるアプリのみを確認してダウンロードできます。Google Play がアプリをフィルタする方法の一つに、機能の互換性によるフィルタリングがあります。

Google Play は、アプリの機能と特定ユーザーのデバイスとの互換性を判断するために、以下の 2 つを比較します。

  • アプリのマニフェストの <uses-feature> 要素で宣言されている、アプリが必要とする機能。
  • 読み取り専用のシステム プロパティを使用して報告される、ハードウェアまたはソフトウェアで利用可能なデバイス機能。

機能を正確に比較するため、Android Package Manager は機能定数の共有セットを提供します。これらは、アプリとデバイスの両方で機能の要件とサポートの宣言に使用できます。使用可能な機能定数のリストは、このドキュメントの機能リファレンスのセクションと、PackageManager のクラス ドキュメントに掲載されています。

ユーザーが Google Play を起動すると、アプリは getSystemAvailableFeatures() を呼び出して、デバイスで使用できる機能のリストを Package Manager に問い合わせます。そうするとストアアプリは、ユーザーのセッションを確立する際に機能リストを Google Play に渡します。

デベロッパーが Google Play Console にアプリをアップロードすると、そのたびに Google Play はアプリのマニフェスト ファイルをスキャンします。Google Play は <uses-feature> 要素を検索し、他の要素(場合によっては <uses-sdk> 要素や <uses-permission> 要素など)と組み合わせて評価します。アプリに必須となる機能のセットを確立したら、そのリストを APK アプリやアプリのバージョンに関連付けられたメタデータとして、内部的に保存します。

ユーザーが Google Play でアプリを検索または閲覧すると、Google Play は、各アプリが必要とする機能と、ユーザーのデバイスで使用できる機能とを照合します。アプリが必要とする機能がすべてデバイスに存在する場合、Google Play は、ユーザーがアプリを確認して必要であればダウンロードできるようにします。

必要な機能がデバイスでサポートされていない場合、Google Play はアプリを除外して、ユーザーが閲覧やダウンロードをできないようにします。

<uses-feature> 要素で宣言した機能は、Google Play によるアプリのフィルタリングに直接影響します。したがって、Google Play がアプリのマニフェストを評価して必須機能のセットを確立する仕組みを理解することが重要です。以降のセクションでは、この点について詳しく説明します。

明示的に宣言された機能に基づくフィルタリング

明示的に宣言された機能とは、アプリが <uses-feature> 要素で宣言している機能です。API レベル 5 以上に対してコンパイルする場合、機能宣言に android:required=["true" | "false"] 属性を含めることができます。

これにより、アプリがその機能を必要とし、それ("true")なしでは正しく機能しないのか、あるいは、利用可能であればその機能を使用するが、それ("false")なしでも動作するように設計されているかを指定できます。

Google Play は、明示的に宣言された機能を次のように処理します。

  • 次の例に示すように、機能が必須であると明示的に宣言されている場合、Google Play はその機能をアプリの必須機能リストに追加します。次に、その機能を備えていないデバイスを使用しているユーザーに対しては、そのアプリを除外します。
    <uses-feature android:name="android.hardware.camera.any" android:required="true" />
    
  • 次の例に示すように、機能が必須ではないと明示的に宣言されている場合、Google Play はその機能を必須機能リストに追加しません。したがって、必須ではないと明示的に宣言されている機能は、アプリを除外する際に考慮されません。宣言された機能をデバイスが備えていなくても、Google Play はアプリがデバイスと互換性があると判断し、他のフィルタリング ルールが適用されない限り、そのアプリをユーザーに表示します。
    <uses-feature android:name="android.hardware.camera" android:required="false" />
    
  • 機能が明示的に宣言されているが android:required 属性が指定されていない場合、Google Play はその機能を必須と見なして、その機能に基づくフィルタリングを設定します。

一般的に、アプリが Android 1.6 以前で動作するように設計されている場合、android:required 属性は API で使用できないため、Google Play はすべての <uses-feature> 宣言が必須であると見なします。

注: 機能を明示的に宣言して android:required="false" 属性を設定すると、指定した機能に対する Google Play のフィルタリングをすべて無効にできます。

暗黙的な機能に基づくフィルタ

「暗黙的」な機能とは、アプリが適切に動作するために必須であるが、マニフェスト ファイルの <uses-feature> 要素で宣言されていない機能です。厳密に言えば、すべてのアプリは、使用または必要とするすべての機能を常に宣言することが最善であり、アプリが使用する機能を宣言しなければエラーと見なされる場合もあります。

ただし、ユーザーやデベロッパーを保護するための措置として、Google Play は、明示的に宣言された機能と同様に各アプリの暗黙的な機能を検索して、それらの機能に基づくフィルタを設定します。

アプリは、ある機能が必須でありながらも、次のような理由で機能を宣言しない場合があります。

  • <uses-feature> 要素が利用できない古いバージョンの Android ライブラリ(Android 1.5 以前)に対して、アプリがコンパイルされた。
  • その機能はすべてのデバイスに存在するので宣言は必要ないと、デベロッパーが勘違いしている。
  • デベロッパーが誤って機能の宣言を省略した。
  • デベロッパーが明示的に機能を宣言しているが、宣言が有効ではない。たとえば、<uses-feature> 要素名のスペルが間違っている場合や、android:name 属性の値が認識できない文字列である場合、機能の宣言は無効になります。

Google Play は、上記のようなケースに対処するため、マニフェスト ファイルで宣言されている他の要素(特に <uses-permission> 要素)を調べて、アプリの暗黙的な機能要件を発見しようと試みます。

アプリがハードウェアに関連する権限をリクエストしている場合、それに対応する <uses-feature> 宣言がなくても、Google Play は、アプリがその権限に関わるハードウェア機能を使用しており、それゆえその機能は必須であると見なします。このような権限がある場合、Google Play は、関連するハードウェア機能をアプリ用に保存するメタデータに追加して、その機能に基づくフィルタを設定します。

たとえば、アプリが CAMERA 権限をリクエストしている場合は、アプリが android.hardware.camera に対し <uses-feature> 要素を宣言していなくても、アプリに背面(ワールド フェイシング)カメラが必要であると見なされます。そのため、Google Play は、背面カメラを搭載していないデバイスを除外します。

暗黙的に示唆される特定の機能に基づくフィルタリングが Google Play で行われないようにする場合は、<uses-feature> 要素で機能を明示的に宣言し、android:required="false" 属性を追加します。たとえば、CAMERA 権限で暗黙的に示唆されるフィルタリングを無効にするには、次の機能を宣言します。

<uses-feature android:name="android.hardware.camera" android:required="false" />
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />

注意: <uses-permission> 要素でリクエストした権限は、Google Play によるアプリのフィルタリングに直接影響する可能性があります。機能要件を暗黙的に示唆する権限セクションには、機能要件を暗示してフィルタリングをトリガーする権限一式がリストされています。

Bluetooth 機能向けの特別な処理

Bluetooth に対するフィルタリングを決定する際、Google Play は上記の例とは若干異なるルールを適用します。

アプリが <uses-permission> 要素で Bluetooth 権限を宣言しているが、<uses-feature> 要素では Bluetooth 機能を明示的に宣言していない場合、Google Play は、アプリが動作するように設計されている Android プラットフォームのバージョン(<uses-sdk> 要素で指定される)をチェックします。

次の表に示すように、Google Play は、アプリが最小バージョンのプラットフォームまたはターゲット プラットフォームを Android 2.0(API レベル 5)以上として宣言している場合にのみ、Bluetooth 機能のフィルタリングを有効にします。ただし、アプリが <uses-feature> 要素で Bluetooth 機能を明示的に宣言している場合、Google Play はフィルタリングに通常のルールを適用します。

表 1.Bluetooth 権限をリクエストしているが <uses-feature> 要素で Bluetooth 機能を宣言していないアプリに対して、Google Play が Bluetooth 機能要件を決定する仕組み。

minSdkVersion が下記の場合 かつ targetSdkVersion 結果
4 以下、または <uses-sdk> が宣言されていない <=4 Google Play は、報告された android.hardware.bluetooth 機能のサポートに基づくデバイスからアプリを除外することはありません
<=4 >=5 Google Play は、android.hardware.bluetooth 機能をサポートしていないデバイス(古いリリースも含む)からはアプリを除外します。
>=5 >=5

次の例は、Google Play が Bluetooth 機能を処理する方法に応じた、さまざまなフィルタリング効果を示しています。

最初の例では、古い API レベルで動作するように設計されているアプリが Bluetooth 権限を宣言していますが、<uses-feature> 要素では Bluetooth 権限を宣言していません。
結果: Google Play はいかなるデバイスからもアプリを除外しません。
<manifest ...>
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" />
    ...
</manifest>
2 番目の例では、同じアプリで対象 API レベルが「5」であることも宣言しています。
結果: Google Play はこの機能が必須であると見なし、Bluetooth のサポートを報告していないすべてのデバイス(古いバージョンのプラットフォームを実行しているデバイスを含む)からアプリを除外します。
<manifest ...>
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>
下記の例では、同じアプリが Bluetooth 機能を明示的に宣言しています。
結果: 前の例と同じです(フィルタリングが適用されます)。
<manifest ...>
    <uses-feature android:name="android.hardware.bluetooth" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>
最終的に、次のケースでは、同じアプリが android:required="false" 属性を追加しています。
結果: Google Play は、すべてのデバイスに対して、Bluetooth 機能のサポートに基づくフィルタリングを無効にします。
<manifest ...>
    <uses-feature android:name="android.hardware.bluetooth" android:required="false" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>

アプリの必須機能をテストする

Android SDK に含まれる aapt ツールを使用すると、宣言されている機能と権限に基づいて Google Play がアプリをどのように除外するかを決定できます。これを行うには、aaptdump badging コマンドで実行します。そうすると、aapt によってアプリのマニフェストが解析され、アプリの必須機能を決定するために Google Play が使用するのと同じルールが適用されます。

このツールを使用する手順は次のとおりです。

  1. アプリを未署名の APK としてビルドし、エクスポートします。Android Studio で開発している場合は、次のように Gradle でアプリをビルドします。
    1. プロジェクトを開いて、[Run] > [Edit Configurations] を選択します。
    2. [Run/Debug Configurations] ウィンドウの左上隅にあるプラス記号を選択します。
    3. [Gradle] を選択します。
    4. [Name] に「Unsigned APK」と入力します。
    5. [Gradle project] セクションでモジュールを選択します。
    6. [Tasks] に「assemble」と入力します。
    7. [OK] を選択して、新しい構成を完了します。
    8. ツールバーで [Unsigned APK] 実行構成が選択されていることを確認して、[Run] > [Run 'Unsigned APK'] を選択します。
    <ProjectName>/app/build/outputs/apk/ ディレクトリに未署名の APK があります。
  2. まだ PATH にない場合は、aapt ツールを検索します。SDK Tools r8 以上を使用している場合、aapt<SDK>/build-tools/<tools version number> ディレクトリにあります。

    注: 使用可能な最新の Build-Tools コンポーネント向けに提供されている aapt のバージョンを使用する必要があります。最新の Build-Tools コンポーネントがない場合は、Android SDK Manager を使用してダウンロードします。

  3. 次の構文を使用して aapt を実行します。
$ aapt dump badging <path_to_exported_.apk>

前に示した 2 つ目の Bluetooth 例に対し、コマンド出力例を次に示します。

$ ./aapt dump badging BTExample.apk
package: name='com.example.android.btexample' versionCode='' versionName=''
uses-permission:'android.permission.BLUETOOTH_ADMIN'
uses-feature:'android.hardware.bluetooth'
sdkVersion:'3'
targetSdkVersion:'5'
application: label='BT Example' icon='res/drawable/app_bt_ex.png'
launchable activity name='com.example.android.btexample.MyActivity'label='' icon=''
uses-feature:'android.hardware.touchscreen'
main
supports-screens: 'small' 'normal' 'large'
locales: '--_--'
densities: '160'

機能リファレンス

以降のセクションでは、ハードウェア機能、ソフトウェア機能、特定の機能要件を暗黙的に示唆する権限のセットのリファレンス情報を示します。

ハードウェア機能

このセクションでは、現在提供されているほとんどのプラットフォーム リリースでサポートされているハードウェア機能を示します。アプリがハードウェア機能を使用または必要とすることを示すには、android:name 属性でそれに対応する値("android.hardware" で始まります)を宣言します。ハードウェア機能を 1 つ宣言するたびに、個別の <uses-feature> 要素を使用します。

オーディオ ハードウェア機能

android.hardware.audio.low_latency
アプリは、デバイスの低レイテンシのオーディオ パイプラインを使用し、それによって音声入出力を処理する際のタイムラグと遅延を短縮します。
android.hardware.audio.output
アプリは、デバイスのスピーカー、オーディオ ジャック、Bluetooth ストリーミング機能、または類似のメカニズムを使用して音声を送信します。
android.hardware.audio.pro
アプリは、デバイスのハイエンド オーディオ機能とパフォーマンス機能を使用します。
android.hardware.microphone
アプリは、デバイスのマイクを使用して音声を録音します。

Bluetooth ハードウェア機能

android.hardware.bluetooth
アプリは、デバイスの Bluetooth 機能を使用し、通常は他の Bluetooth 対応デバイスと通信します。
android.hardware.bluetooth_le
アプリは、デバイスの Bluetooth Low Energy 無線機能を使用します。

カメラ ハードウェア機能

注: Google Play によるアプリの不要なフィルタリングを防ぐため、アプリの動作に必要ないすべてのカメラ機能に android:required="false" を追加してください。この要素を追加しないと、その機能は必要であると見なされ、その機能をサポートしていないデバイスはアプリにアクセスできなくなります。

大画面のサポート

大画面のデバイスによっては、一部のカメラ機能がサポートされていないことがあります。一般に、Chromebook には背面(ワールド フェイシング)カメラ、オートフォーカス、フラッシュは搭載されていませんが、前面(ユーザー フェイシング)カメラは搭載され、通常は外部カメラに接続されます。

基本的なカメラサポートを提供し、できるだけ多くのデバイスでアプリを使用できるようにするには、アプリ マニフェストに次のカメラ機能の設定を追加します。

<uses-feature android:name="android.hardware.camera.any" android:required="false" />
<uses-feature android:name="android.hardware.camera" android:required="false" />
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />
<uses-feature android:name="android.hardware.camera.flash" android:required="false" />

アプリのユースケースに対応するように機能の設定を調整します。なお、多くのデバイスでアプリを使用できるようにするには、必ず required 属性を追加し、機能が必須かどうかを明示的に指定します。

機能リスト
android.hardware.camera.any

アプリは、デバイスのカメラ、またはデバイスに接続されている外部カメラを使用します。カメラがそれぞれ背面(ワールド フェイシング)であるか、前面(ユーザー フェイシング)であるかを求めないアプリでは、android.hardware.cameraandroid.hardware.camera.front の代わりにこの機能を使用します。

CAMERA 権限は、アプリが android.hardware.camera も使用することを暗黙的に示唆しています。android.hardware.cameraandroid:required="false" とともに宣言されている場合を除き、背面カメラは必須機能です。

android.hardware.camera

アプリは、デバイスの背面(ワールド フェイシング)カメラを使用します。

注意: 前面(ユーザー フェイシング)カメラのみが搭載されている Chromebook などのデバイスは、この機能をサポートしていません。カメラがどちらの面に搭載されているかにかかわらず、アプリがカメラを使用できる場合は、android.hardware.camera.any を使います。

注: CAMERA 権限により、背面カメラが必須機能であることが暗黙的に示唆されています。アプリ マニフェストに CAMERA 権限が含まれている場合に Google Play で適切にフィルタリングが行われるようにするには、以下
のようにアプリが camera 機能を使用することを明示的に指定して、この機能が必要かどうかを示します。 <uses-feature android:name="android.hardware.camera" android:required="false" />

android.hardware.camera.front

アプリは、デバイスの前面(ユーザー フェイシング)カメラを使用します。

CAMERA 権限は、アプリが android.hardware.camera も使用することを暗黙的に示唆しています。android.hardware.cameraandroid:required="false" とともに宣言されている場合を除き、背面カメラは必須機能です。

注意: アプリで android.hardware.camera.front を使用しているが、android.hardware.camera を明示的に android.required="false" で宣言していない場合、背面カメラのないデバイス(Chromebook など)は Google Play で除外されます。アプリが前面カメラのみのデバイスをサポートしている場合は、android.required="false"android.hardware.camera を宣言し、不要なフィルタリングを防ぎます。

android.hardware.camera.external

アプリは、ユーザーがデバイスに接続する外部カメラと通信します。この機能は、アプリが外部カメラを使用できることを保証するものではありません。

CAMERA 権限は、アプリが android.hardware.camera も使用することを暗黙的に示唆しています。android.hardware.cameraandroid:required="false" とともに宣言されている場合を除き、背面カメラは必須機能です。

android.hardware.camera.autofocus

アプリは、デバイスのカメラがサポートするオートフォーカス機能を使用します。

注: CAMERA 権限は、オートフォーカスが必須機能であることを暗黙的に示唆しています。アプリ マニフェストに CAMERA 権限が含まれている場合に Google Play で適切にフィルタリングが行われるようにするには、以下
のように、アプリがオートフォーカス機能を使用することを明示的に指定して、この機能が必要かどうかを示します。 <uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />

android.hardware.camera.flash

アプリは、デバイスのカメラがサポートするフラッシュ機能を使用します。

android.hardware.camera.capability.manual_post_processing

アプリは、デバイスのカメラがサポートする MANUAL_POST_PROCESSING 機能を使用します。

この機能により、アプリはカメラの自動ホワイト バランス機能をオーバーライドできます。TRANSFORM_MATRIXandroid.colorCorrection.transformandroid.colorCorrection.gainsandroid.colorCorrection.mode を使用します。

android.hardware.camera.capability.manual_sensor

アプリは、デバイスのカメラがサポートする MANUAL_SENSOR 機能を使用します。

この機能は、自動露出ロック(android.control.aeLock)のサポートを暗黙的に示唆します。これは、カメラの露出時間と感度を特定の値に固定できる機能です。

android.hardware.camera.capability.raw

アプリは、デバイスのカメラがサポートする RAW 機能を使用します。

この機能は、デバイスが DNG(RAW)ファイルを保存できることを暗黙的に示唆します。デバイスのカメラが、アプリで RAW 画像を直接処理するために必要な DNG 関連のメタデータを提供します。

android.hardware.camera.level.full
アプリは、デバイスのカメラの少なくとも 1 つから提供される FULL レベルの画像キャプチャ サポートを使用します。FULL のサポートには、バースト撮影機能、フレーム単位の制御、手動の後処理制御が含まれます。詳しくは、INFO_SUPPORTED_HARDWARE_LEVEL_FULL をご覧ください。

デバイス UI ハードウェア機能

android.hardware.type.automotive

アプリは、自動車内の画面のセットに UI を表示するように設計されています。 ユーザーは、ハードボタン、タッチデバイス、ロータリー コントローラ、マウス状のインターフェースを使用してアプリを操作します。一般的に、自動車の画面は自動車のセンター コンソールまたは計器クラスタに表示されます。通常、これらの画面のサイズと解像度には制限があります。

注: ユーザーはこの型のアプリ UI を使用しながら運転するので、アプリはドライバの気を散らすものを最小限に抑える必要があります。

android.hardware.type.television

(非推奨ですので、代わりに android.software.leanback を使用してください。)

アプリは、テレビに UI を表示するように設計されています。この機能は、「テレビ」を一般的なリビングルーム向けのテレビ エクスペリエンスとして定義します。つまり、大画面にアプリが表示され、ユーザーは離れた場所に座り、入力はマウスやポインタ、タッチデバイスではなく D-pad のようなものが主流になるのです。

android.hardware.type.watch
アプリは、スマートウォッチに UI を表示するように設計されています。スマートウォッチは身体(手首など)に装着します。ユーザーは、デバイスを操作する際、デバイスのすぐ近くにいます。

指紋認証ハードウェア機能

android.hardware.fingerprint
アプリは、デバイスの生体認証ハードウェアを使用して指紋を読み取ります。

ゲームパッド ハードウェア機能

android.hardware.gamepad
アプリは、デバイス自体または接続されたゲームパッドから、ゲーム コントローラ入力をキャプチャします。

赤外線ハードウェア機能

android.hardware.consumerir
アプリは、デバイスの赤外線(IR)機能を使用し、通常は他の消費者向け IR デバイスと通信します。

位置情報ハードウェア機能

android.hardware.location
アプリは、GPS の位置情報、ネットワークの位置情報、基地局の位置情報などを確認するために、デバイスの 1 つまたは複数の機能を使用します。
android.hardware.location.gps

アプリは、デバイスのグローバル ポジショニング システム(GPS)レシーバーから取得した正確な位置情報座標を使用します。

アプリがこの機能を使用する場合は、android.hardware.location 機能も使用することが暗黙的に示唆されます(ただし、この親機能が android:required="false" 属性とともに宣言されている場合を除きます)。

android.hardware.location.network

アプリは、デバイスでサポートされているネットワーク ベースの位置情報システムから取得したおおよその位置情報座標を使用します。

アプリがこの機能を使用する場合は、android.hardware.location 機能も使用することが暗黙的に示唆されます(ただし、この親機能が android:required="false" 属性とともに宣言されている場合を除きます)。

NFC ハードウェア機能

android.hardware.nfc
アプリは、デバイスの近距離無線通信(NFC)無線機能を使用します。
android.hardware.nfc.hce

アプリは、デバイスでホストされている NFC カード エミュレーションを使用します。

OpenGL ES ハードウェア機能

android.hardware.opengles.aep
アプリは、デバイスにインストールされている OpenGL ES Android 拡張機能パックを使用します。

センサー ハードウェア機能

android.hardware.sensor.accelerometer
アプリは、デバイスの現在の向きを検出するために、デバイスの加速度計のモーション測定値を使用します。たとえば、アプリは加速度計の測定値を使用して、縦向きと横向きを切り替えるタイミングを決定できます。
android.hardware.sensor.ambient_temperature
アプリは、デバイスの周辺(環境)温度センサーを使用します。たとえば、天気アプリは屋内外の温度を報告できます。
android.hardware.sensor.barometer
アプリはデバイスの気圧計を使用します。たとえば、天気アプリは気圧を報告します。
android.hardware.sensor.compass
アプリはデバイスの磁力計(コンパス)を使用します。たとえば、ナビゲーション アプリは、ユーザーが現在向いている方向を表示します。
android.hardware.sensor.gyroscope
アプリは、回転とねじれを検出して 6 軸方向システムを作成するために、デバイスのジャイロスコープを使用します。このセンサーを使用すると、アプリは、縦向きと横向きの切り替えが必要なタイミングをよりスムーズに検出できます。
android.hardware.sensor.hifi_sensors
アプリはデバイスの高忠実度(Hi-Fi)センサーを使用します。たとえば、ゲームアプリはユーザーの高精細な動きを検出します。
android.hardware.sensor.heartrate
アプリはデバイスの心拍数モニターを使用します。たとえば、フィットネス アプリは、時間経過に伴うユーザーの心拍数の傾向を報告します。
android.hardware.sensor.heartrate.ecg
アプリは、デバイスの心電図(ECG)心拍数センサーを使用します。たとえば、フィットネス アプリは、ユーザーの心拍数について、より詳しい情報を報告します。
android.hardware.sensor.light
アプリはデバイスの光センサーを使用します。たとえば、アプリは周囲の明るさの状況に基づいて、2 種類のカラーパターンのいずれかを表示します。
android.hardware.sensor.proximity
アプリはデバイスの近接センサーを使用します。たとえば、電話アプリは、ユーザーが身体の近くでデバイスを持っていることを検出すると、デバイスの画面をオフします。
android.hardware.sensor.relative_humidity
アプリはデバイスの相対湿度センサーを使用します。たとえば、天気アプリは湿度から現在の露点温度を計算して報告します。
android.hardware.sensor.stepcounter
アプリはデバイスの歩数計を使用します。たとえば、フィットネス アプリは、ユーザーが 1 日の歩数目標を達成するために必要な歩数を報告します。
android.hardware.sensor.stepdetector
アプリはデバイスの歩行検出機能を使用します。たとえば、フィットネス アプリは、歩行の時間間隔を使用して、ユーザーがしている運動の種類を推測します。

画面ハードウェア機能

android.hardware.screen.landscape
android.hardware.screen.portrait

デバイスを縦向きまたは横向きにしてアプリを実行する必要があることを示します。アプリが両方の向きをサポートしている場合、どちらの機能も宣言する必要はありません。

たとえば、縦向きで実行する必要があるアプリは(常に、またはユーザーの選択に応じて)縦向きをサポートするデバイスのみでアプリを実行できるように、次の機能を宣言します。

<uses-feature android:name="android.hardware.screen.portrait" />

デフォルトではどちらの向きも必須ではないと見なされるため、アプリは、一方または両方の向きをサポートするデバイスにインストールできます。ただし、android:screenOrientation 属性を使用して、なんらかのアクティビティが特定方向での実行をリクエストしている場合、この宣言により、アプリにはその向きが必須であると暗黙的に示唆されます。

たとえば、"landscape""reverseLandscape" あるいは "sensorLandscape" のいずれかで android:screenOrientation を宣言すると、アプリは横向きをサポートするデバイスでのみ使用可能になります。

<uses-feature> 要素を使用して、この向きの要件を宣言することをおすすめします。android:screenOrientation but don't actually require it, you can disable the requirement by declaring the orientation with a <uses-feature> element and include android:required="false". を使用してアクティビティの向きを宣言する場合

For backward compatibility, any device running Android 3.1 (API level 12) or lower supports both landscape and portrait orientations.

Telephony hardware features

android.hardware.telephony
The app uses the device's telephony features, such as telephony radio with data communication services.
android.hardware.telephony.cdma

The app uses the Code Division Multiple Access (CDMA) telephony radio system.

By using this feature, an app implies that it also uses the android.hardware.telephony feature, unless this parent feature is declared with android:required="false".

android.hardware.telephony.gsm

The app uses the Global System for Mobile Communications (GSM) telephony radio system.

By using this feature, an app implies that it also uses the android.hardware.telephony feature, unless this parent feature is declared with android:required="false".

Touchscreen hardware features

android.hardware.faketouch

The app uses basic touch interaction events, such as tapping and dragging.

When declared as required, this feature indicates that the app is compatible with a device only if that device has an emulated "fake touch" touchscreen or has an actual touchscreen.

A device that offers a fake touch interface provides a user input system that emulates a subset of a touchscreen's capabilities. For example, a mouse or remote control might drive an on-screen cursor.

If your app requires basic point and click interaction and doesn't work with only a D-pad controller, declare this feature. Because this is the minimum level of touch interaction, you can also use an app that declares this feature on devices that offer more complex touch interfaces.

Apps require the android.hardware.faketouch feature by default. If you want your app to be limited to devices that only have a touchscreen, you must explicitly declare that touchscreen is required as follows:

<uses-feature android:name="android.hardware.touchscreen"
    android:required="true" />

All apps that don't explicitly require android.hardware.touchscreen, as shown in the following example, also work on devices with android.hardware.faketouch.

<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
android.hardware.faketouch.multitouch.distinct

The app tracks two or more distinct "fingers" on a fake touch interface. This is a superset of the android.hardware.faketouch feature. When declared as required, this feature indicates that the app is compatible with a device only if that device emulates distinct tracking of two or more fingers or has an actual touchscreen.

Unlike the distinct multitouch defined by android.hardware.touchscreen.multitouch.distinct, input devices that support distinct multitouch with a fake touch interface don't support all two-finger gestures, because the input is transformed to cursor movement on the screen. That is, single-finger gestures on such a device move a cursor, two-finger swipes cause single-finger touch events to occur, and other two-finger gestures trigger the corresponding two-finger touch events.

A device that provides a two-finger touch trackpad for cursor movement can support this feature.

android.hardware.faketouch.multitouch.jazzhand

The app tracks five or more distinct "fingers" on a fake touch interface. This is a superset of the android.hardware.faketouch feature. When declared as required, this feature indicates that the app is compatible with a device only if that device emulates distinct tracking of five or more fingers or has an actual touchscreen.

Unlike the distinct multitouch defined by android.hardware.touchscreen.multitouch.jazzhand, input devices that support jazzhand multitouch with a fake touch interface don't support all five-finger gestures, because the input is transformed to cursor movement on the screen. That is, single-finger gestures on such a device move a cursor, multi-finger gestures cause single-finger touch events to occur, and other multi-finger gestures trigger the corresponding multi-finger touch events.

A device that provides a five-finger touch trackpad for cursor movement can support this feature.

android.hardware.touchscreen

The app uses the device's touchscreen capabilities for gestures that are more interactive than basic touch events, such as a fling. This is a superset of the android.hardware.faketouch feature.

By default, all apps require this feature and therefore aren't available to devices that provide only an emulated "fake touch" interface. You can make your app available on devices that provide a fake touch interface, or even on devices that provide only a D-pad controller, by explicitly declaring that a touchscreen is not required using android.hardware.touchscreen with android:required="false". Add this declaration if your app uses, but doesn't require, a real touchscreen interface. All apps that don't explicitly require android.hardware.touchscreen also work on devices with android.hardware.faketouch.

If your app in fact requires a touch interface, such as to perform more advanced touch gestures like flings, then you don't need to declare any touch interface features, because they're required by default. However, it's best if you explicitly declare all features that your app uses.

If you require more complex touch interaction, such as multi-finger gestures, declare that your app uses advanced touchscreen features.

android.hardware.touchscreen.multitouch

The app uses the device's basic two-point multitouch capabilities, such as for pinch gestures, but the app doesn't need to track touches independently. This is a superset of the android.hardware.touchscreen feature.

By using this feature, an app implies that it also uses the android.hardware.touchscreen feature, unless this parent feature is declared with android:required="false".

android.hardware.touchscreen.multitouch.distinct

The app uses the device's advanced multitouch capabilities for tracking two or more points independently. This feature is a superset of the android.hardware.touchscreen.multitouch feature.

By using this feature, an app implies that it also uses the android.hardware.touchscreen.multitouch feature, unless this parent feature is declared with android:required="false".

android.hardware.touchscreen.multitouch.jazzhand

The app uses the device's advanced multitouch capabilities for tracking five or more points independently. This feature is a superset of the android.hardware.touchscreen.multitouch feature.

By using this feature, an app implies that it also uses the android.hardware.touchscreen.multitouch feature, unless this parent feature is declared with android:required="false".

USB hardware features

android.hardware.usb.accessory
The app behaves as a USB device and connects to USB hosts.
android.hardware.usb.host
The app uses the USB accessories that are connected to the device. The device serves as the USB host.

Vulkan hardware features

android.hardware.vulkan.compute
The app uses Vulkan compute features. This feature indicates that the app requires the hardware-accelerated Vulkan implementation. The feature version indicates which level of optional compute features the app requires beyond the Vulkan 1.0 requirements. For example, if your app requires Vulkan compute level 0 support, declare the following feature:
<uses-feature
    android:name="android.hardware.vulkan.compute"
    android:version="0"
    android:required="true" />
For more details about the feature version, see FEATURE_VULKAN_HARDWARE_COMPUTE.
android.hardware.vulkan.level
The app uses Vulkan level features. This feature indicates that the app requires the hardware-accelerated Vulkan implementation. The feature version indicates which level of optional hardware features the app requires. For example, if your app requires Vulkan hardware level 0 support, declare the following feature:
<uses-feature
    android:name="android.hardware.vulkan.level"
    android:version="0"
    android:required="true" />
For more information about the feature version, see FEATURE_VULKAN_HARDWARE_LEVEL.
android.hardware.vulkan.version
The app uses Vulkan. This feature indicates that the app requires the hardware-accelerated Vulkan implementation. The feature version indicates the minimum version of Vulkan API support the app requires. For example, if your app requires Vulkan 1.0 support, declare the following feature:
<uses-feature
    android:name="android.hardware.vulkan.version"
    android:version="0x400003"
    android:required="true" />
For more details about the feature version, see FEATURE_VULKAN_HARDWARE_VERSION.

Wi-Fi hardware features

android.hardware.wifi
The app uses 802.11 networking (Wi-Fi) features on the device.
android.hardware.wifi.direct
The app uses the Wi-Fi Direct networking features on the device.

Software features

This section presents the software features supported by the most current platform release. To indicate that your app uses or requires a software feature, declare the corresponding value, beginning with "android.software", in an android:name attribute. Each time you declare a software feature, use a separate <uses-feature> element.

Communication software features

android.software.sip
The app uses Session Initiation Protocol (SIP) services. By using SIP, the app can support internet telephony operations, such as video conferencing and instant messaging.
android.software.sip.voip

The app uses SIP-based Voice Over Internet Protocol (VoIP) services. By using VoIP, the app can support real-time internet telephony operations, such as two-way video conferencing.

By using this feature, an app implies that it also uses the android.software.sip feature, unless this parent feature is declared with android:required="false".

android.software.webview
The app displays content from the internet.

Custom input software features

android.software.input_methods
The app uses a new input method, which the developer defines in an InputMethodService.

Device management software features

android.software.backup
The app includes logic to handle a backup and restore operation.
android.software.device_admin
The app uses device administrators to enforce a device policy.
android.software.managed_users
The app supports secondary users and managed profiles.
android.software.securely_removes_users
The app can permanently remove users and their associated data.
android.software.verified_boot
The app includes logic to handle results from the device's verified boot feature, which detects whether the device's configuration changes during a restart operation.

Media software features

android.software.midi
The app connects to musical instruments or outputs sound using the Musical Instrument Digital Interface (MIDI) protocol.
android.software.print
The app includes commands for printing documents displayed on the device.
android.software.leanback
The app is designed to run on Android TV devices.
android.software.live_tv
The app streams live television programs.

Screen interface software features

android.software.app_widgets
The app uses or provides App Widgets and is intended only for devices that include a Home screen or similar location where users can embed App Widgets.
android.software.home_screen
The app behaves as a replacement to the device's Home screen.
android.software.live_wallpaper
The app uses or provides wallpapers that include animation.

Permissions that imply feature requirements

Some hardware and software feature constants are made available to applications after the corresponding API. Because of this, some apps might use the API before they can declare that they require the API using the <uses-feature> system.

To prevent those apps from being made available unintentionally, Google Play assumes that certain hardware-related permissions indicate that the underlying hardware features are required by default. For instance, applications that use Bluetooth must request the BLUETOOTH permission in a <uses-permission> element.

For legacy apps, Google Play assumes that the permission declaration means that the underlying android.hardware.bluetooth feature is required by the application and sets up filtering based on that feature. Table 2 lists permissions that imply feature requirements equivalent to those declared in <uses-feature> elements.

<uses-feature> declarations, including any declared android:required attribute, always take precedence over features implied by the permissions in table 2. For any of these permissions, you can disable filtering based on the implied feature by explicitly declaring the feature in a <uses-feature> element with the required attribute set to false.

For example, to disable filtering based on the CAMERA permission, add the following <uses-feature> declarations to the manifest file:

<uses-feature android:name="android.hardware.camera" android:required="false" />
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />

Caution: If your app targets Android 5.0 (API level 21) or higher and uses the ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION permission to receive location updates from the network or a GPS, respectively, you must also explicitly declare that your app uses the android.hardware.location.network or android.hardware.location.gps hardware features.

Table 2. Device permissions that imply device hardware use.

Category Permission Implied feature requirement
Bluetooth BLUETOOTH android.hardware.bluetooth

See Special handling for Bluetooth feature for details.

BLUETOOTH_ADMIN android.hardware.bluetooth
Camera CAMERA android.hardware.camera
android.hardware.camera.autofocus
Location ACCESS_MOCK_LOCATION android.hardware.location
ACCESS_LOCATION_EXTRA_COMMANDS android.hardware.location
INSTALL_LOCATION_PROVIDER android.hardware.location
ACCESS_COARSE_LOCATION

android.hardware.location

android.hardware.location.network (Only when target API level is 20 or lower.)

ACCESS_FINE_LOCATION

android.hardware.location

android.hardware.location.gps (Only when target API level is 20 or lower.)

Microphone RECORD_AUDIO android.hardware.microphone
Telephony CALL_PHONE android.hardware.telephony
CALL_PRIVILEGED android.hardware.telephony
MODIFY_PHONE_STATE android.hardware.telephony
PROCESS_OUTGOING_CALLS android.hardware.telephony
READ_SMS android.hardware.telephony
RECEIVE_SMS android.hardware.telephony
RECEIVE_MMS android.hardware.telephony
RECEIVE_WAP_PUSH android.hardware.telephony
SEND_SMS android.hardware.telephony
WRITE_APN_SETTINGS android.hardware.telephony
WRITE_SMS android.hardware.telephony
Wi-Fi ACCESS_WIFI_STATE android.hardware.wifi
CHANGE_WIFI_STATE android.hardware.wifi
CHANGE_WIFI_MULTICAST_STATE android.hardware.wifi