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

構文:
<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" />
<uses-feature android:name="android.hardware.camera" />

一般に、アプリで必要なすべての機能について <uses-feature> 要素を必ず宣言する必要があります。

宣言された <uses-feature> 要素は情報提供のみを目的としています。つまり、Android システム自体は、アプリをインストールする前に端末のサポート機能と一致しているかどうかは確認しません。 ただし、その他のサービス(Google Play など)やアプリが、アプリの処理やアプリとのやり取りの中で、アプリの <uses-feature> 宣言を確認する場合はあります。 このため、アプリで使用するすべての機能(以下のリストを参照)を宣言することが非常に重要です。

一部の機能には、使用する Open GL のバージョン(glEsVersion で宣言)など、機能のバージョンを定義できる専用の属性が存在します。 カメラなど、端末に存在する / しないのいずれかであるその他の機能については、name 属性を使用して宣言します。

<uses-feature> 要素は API レベル 4 以上を実行している端末でのみアクティベートされますが、minSdkVersion が "3" 以下でも、すべてのアプリにこれらの要素を含めることをお勧めします。 以前のバージョンのプラットフォームを実行している端末は、この要素を単純に無視します。

注: 機能を宣言するときは、必要に応じてパーミッションもリクエストする必要がある点に注意してください。 たとえば、カメラ 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" を設定します。

アプリはマニフェスト内で 1 つ以上の android:glEsVersion 属性を指定する必要があります。 複数指定すると、数値的に最大値を指定した 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 レベル 4
関連ドキュメント

Google Play と機能ベースのフィルタリング

Google Play は、ユーザーが自分の端末と互換性のあるアプリのみを参照してダウンロードできるように、ユーザーに表示するアプリをフィルタリングします。 アプリをフィルタリングする方法の 1 つとして、機能の互換性を指定する方法があります。

任意のユーザーの端末に対してアプリの機能の互換性を判断するため、Google Play は以下の 2 つを比較します。

  • アプリで必要な機能。アプリのマニフェストの <uses-feature> 要素で機能を宣言します。
    vs.
  • 端末で使用できるハードウェアまたはソフトウェアの機能。端末は読み取り専用のシステム プロパティで、サポートしている機能を報告します。

機能を正確に比較できるように、Android Package Manager では機能を示す共通の定数のセットを提供しています。アプリと端末の両方でこの定数を使用して、機能の要件とサポートを宣言することができます。 使用可能な機能の定数のリストについては、このドキュメントの最後にある機能リファレンスのセクションと、PackageManager のクラスのドキュメントをご覧ください。

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

Google Play Developer Console にアプリをアップロードするたびに、Google Play はアプリのマニフェスト ファイルをスキャンします。 そのとき <uses-feature> 要素を探し、状況に応じて <uses-sdk> 要素や <uses-permission> 要素など、他の要素と組み合わせて評価します。 アプリに必要な機能のセットを作成したら、そのリストをアプリの .apk およびアプリのバージョンと関連付けたメタデータとして内部に保存します。

ユーザーが Google Play アプリを使用してアプリを検索または参照するとき、サービスはユーザーの端末で使用できる機能と、各アプリに必要な機能を比較します。 アプリに必要な機能がすべて端末に存在する場合は、Google Play はユーザーにアプリを表示し、場合によってはダウンロードできるようにします。 必要な機能が端末でサポートされていない場合は、Google Play はアプリをフィルタリングしてユーザーには表示せず、ダウンロードできないようにします。

<uses-feature> で宣言した機能は Google Play によるアプリのフィルタリングに直接影響するため、Google Play がアプリのマニフェストを評価し、必要な機能のセットを作成している仕組みを理解しておくことが重要です。 詳細については、以下のセクションをご覧ください。

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

明示的に宣言された機能とは、アプリが <uses-feature> 要素で宣言した機能です。 機能の宣言には、android:required=["true" | "false"] 属性(API レベル 5 以上でコンパイルする場合)を含めることができます。この属性を使用して、アプリにはその機能が絶対に必要で、使用できなければ正常に動作しない("true")、または、その機能を使用できる場合は優先的に使用するが、なくても実行できる("false")、のいずれかを指定できます。

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

  • 必要な機能が明示的に宣言されている場合、Google Play はその機能をアプリの必須機能リストに追加します。 その機能を使用できない端末のユーザーには、アプリをフィルタリングします。次に例を示します。
    <uses-feature android:name="android.hardware.camera" android:required="true" />
  • 機能が「必須ではない」と明示的に宣言されている場合、Google Play はその機能を必須機能リストに追加しません。 このため、必須ではないと明示的に宣言された機能は、アプリのフィルタリング時に考慮されることはありません。 宣言した機能を端末で使用できなくても Google Play はアプリと端末の互換性を検討し、他に適用するフィルタリング ルールがない場合はアプリをユーザーに表示します。 次に例を示します。
    <uses-feature android:name="android.hardware.camera" android:required="false" />
  • 機能が明示的に宣言され、android:required 属性がない場合、Google Play はその機能を必須と見なしてフィルタリングを設定します。

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

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

暗黙的に指定された機能に基づくフィルタリング

暗黙的に指定された機能は、アプリが適切に動作するために必要ですがマニフェスト ファイルの <uses-feature> 要素で宣言されていません。 厳密には、すべてのアプリは必ず、使用する機能または必要とする機能をすべて宣言する必要があります。したがってアプリで使用する機能が宣言されていないのは誤りと考えられます。 しかし、ユーザーやデベロッパーを保護するため、Google Play は各アプリの暗黙的に指定された機能を探して、明示的に宣言された機能と同様にそれらの機能についてフィルタを設定します。

アプリが必要な機能を宣言していない理由:

  • アプリが以前のバージョンの Android ライブラリ(Android 1.5 以前)でコンパイルされ、<uses-feature> 要素は使用できなかった。
  • デベロッパーが、すべての端末にその機能が存在するので宣言は不要と勘違いした。
  • デベロッパーが誤って機能の宣言を削除した。
  • デベロッパーが明示的に機能を宣言しているが、宣言が無効だった。 たとえば、<uses-feature> 要素名のスペルミス、android:name 属性に認識できない文字列値などが含まれていると、機能の宣言が無効になります。

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

アプリがハードウェア関連のパーミッションを要求している場合、それに対応する <uses-feature> 宣言が存在しなくても、Google Play はその基盤となるハードウェア機能をアプリが使用するものと見なします。 このようなパーミッションに対して、Google Play は基盤となるハードウェア機能をメタデータ(アプリ用に保存)に追加し、ハードウェア機能のフィルタを設定します。

たとえば、アプリが CAMERA パーミッションを要求しているのに <uses-feature> 要素で android.hardware.camera を宣言していない場合、Google Play はこのアプリにはカメラが必要で、カメラを搭載していない端末にはこのアプリを表示してはいけない、と判断します。

暗黙的に指定された特定の機能に基づいて Google Play がフィルタリングすることを望まない場合は、この動作を無効化できます。 そのためには、<uses-feature> 要素で機能を明示的に宣言し、android:required="false" 属性を指定します。 たとえば、CAMERA パーミッションから派生したフィルタリングを無効にするには、以下のように機能を宣言します。

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

<uses-permission> 要素で要求したパーミッションは、Google Play でアプリをフィルタリングする動作に直接影響を与えることを必ず理解するようにしてください。 リファレンス セクションの機能要件を伴うパーミッションに、機能要件を暗黙的に示し、フィルタリングをトリガーするパーミッションのリストが掲載されています。

Bluetooth 機能の特殊な処理

Google Play は、Bluetooth のフィルタリングを判断するときは、上記の説明とやや異なるルールを適用します。

アプリが <uses-permission> 要素で Bluetooth パーミッションを宣言し、<uses-feature> 要素で Bluetooth 機能を明示的に宣言していない場合、Google Play はアプリが実行できるよう設計された Android プラットフォームのバージョン(<uses-sdk> 要素で指定)を確認します。

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

表 1. アプリが Bluetooth パーミッションを要求し、<uses-feature> 要素で Bluetooth 機能を宣言していない場合に、Google Play で Bluetooth 機能要件を判断する方法

minSdkVersion の値 または targetSdkVersion の値 結果
<=4(または uses-sdk が宣言されていない)<=4Google Play は、報告された android.hardware.bluetooth 機能のサポートに基づき、どの端末に対してもアプリをフィルタリング「しない」。
<=4>=5Google Play は、android.hardware.bluetooth 機能をサポートしていない端末に対してアプリをフィルタリングする(以前のリリースを含む)。
>=5>=5

以下の例は、Google Play による Bluetooth 機能の処理方法に応じて、フィルタリングの効果が異なることを示しています。

1 つ目の例では、以前の 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 がアプリをどうフィルタリングするのかを調べることができます。 そのためには、dump badging コマンドで aapt を実行します。これにより、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 以上を使用している場合は、<SDK>/platform-tools/ ディレクトリに aapt があります。

    注: 最新の Platform-Tools コンポーネント向けに提供されたバージョンの aapt を使用する必要があります。 最新の Platform-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" で始まる)を宣言します。 ハードウェア機能を宣言するときはそれぞれ、個別の <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 無線通信機能を使用します。

カメラのハードウェア機能

android.hardware.camera
アプリは端末の背面カメラを使用します。前面カメラのみを搭載した端末はこの機能がリストに入っていません。したがって、カメラの向きに関係なくアプリがカメラと通信できる場合は、代わりに android.hardware.camera.any 機能を使用します。
android.hardware.camera.any
アプリは端末のいずれかのカメラを使用するか、ユーザーが端末に接続した外部カメラを使用します。 アプリが背面カメラを必要としない場合は、android.hardware.camera ではなくこの値を使用します。
android.hardware.camera.autofocus

アプリは端末のカメラがサポートしているオートフォーカス機能を使用します。

この機能を使用することで、アプリは android.hardware.camera 機能の使用も暗黙的に要求します(この親機能が android:required="false" として宣言されている場合を除く)。

android.hardware.camera.capability.manual_post_processing

アプリは端末のカメラがサポートしている MANUAL_POST_PROCESSING 機能を使用します。

この機能により、アプリはカメラの自動ホワイト バランス機能をオーバーライドできます。 android.colorCorrection.transformandroid.colorCorrection.gains、および TRANSFORM_MATRIXandroid.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.external
アプリはユーザーが端末に接続した外部カメラと通信します。 ただし、この機能は外部カメラがアプリで使用できることを保証するものではありません。
android.hardware.camera.flash

アプリは端末のカメラがサポートするフラッシュ機能を使用します。

この機能を使用することで、アプリは android.hardware.camera 機能の使用も暗黙的に要求します(この親機能が android:required="false" として宣言されている場合を除く)。

android.hardware.camera.front

アプリは端末の前面カメラを使用します。

この機能を使用することで、アプリは android.hardware.camera 機能の使用も暗黙的に要求します(この親機能が android:required="false" として宣言されている場合を除く)。

android.hardware.camera.level.full
アプリは端末のカメラが提供する FULL レベルのイメージ キャプチャのサポートを 1 つ以上使用します。 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
アプリは端末の歩数計を使用します。たとえば、フィットネス アプリで、ユーザーが毎日の目標歩数を達成するために必要な歩数を報告する場合があります。
android.hardware.sensor.stepdetector
アプリは端末の歩行検出機能を使用します。たとえば、フィットネス アプリで歩行のペースを使用して、ユーザーのエクササイズの種類を推測する場合があります。

画面のハードウェア機能

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

アプリは端末を縦向きまたは横向きで使用する必要があります。 アプリが両方の向きをサポートしている場合、どちらの機能も宣言する必要はありません。

たとえば、アプリを縦向きで使用する必要がある場合、次の機能を宣言し、縦向きをサポートする端末(常時またはユーザーが選択)のみでアプリを実行できるようにします。

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

デフォルトでは、どちらの向きも必須ではないと見なされ、アプリは 1 つまたは両方の向きをサポートする端末にインストールできます。 ただし、なんらかのアクティビティを特定の向きで実行する必要がある場合は、android:screenOrientation 属性を使用します。この宣言は、アプリでその向きが必要であることを暗黙的に示します。 たとえば、android:screenOrientation を宣言して "landscape""reverseLandscape"、または "sensorLandscape" を指定すると、アプリは横向きをサポートする端末でのみ使用できます。

ベスト プラクティスとして、<uses-feature> 要素を使用してこの向きの要件を宣言する必要があります。 android:screenOrientation を使用してアクティビティの向きを宣言し、実際には必須ではない場合、<uses-feature> 要素で向きを宣言して android:required="false" と記述すれば、この要件を無効にすることができます。

下位互換性のため、Android 3.1(API レベル 12)以下を実行する端末は、横向きと縦向きの両方をサポートしています。

電話のハードウェア機能

android.hardware.telephony
アプリは、データ通信サービスを備えた無線通信など、端末のハードウェア機能を使用します。
android.hardware.telephony.cdma

アプリは Code Division Multiple Access(CDMA)無線通信システムを使用します。

この機能を使用することで、アプリは android.hardware.telephony 機能の使用も暗黙的に要求します(この親機能が android:required="false" として宣言されている場合を除く)。

android.hardware.telephony.gsm

アプリは Global System for Mobile Communications(GSM)無線通信システムを使用します。

この機能を使用することで、アプリは android.hardware.telephony 機能の使用も暗黙的に要求します(この親機能が android:required="false" として宣言されている場合を除く)。

タッチスクリーンのハードウェア機能

android.hardware.faketouch

アプリはタップやドラッグなど、基本的なタップ操作イベントを使用します。

この機能を必要に応じて宣言すると、アプリがタッチスクリーンをエミュレートする(「疑似タップ」インターフェース)端末か、実際にタッチスクリーンを備えている端末のみと互換性があることを示します。

疑似タップ インターフェースを備えた端末は、特定のタッチスクリーン機能をエミュレートするユーザー入力システムを提供します。 たとえば、マウスやリモコンで画面上のカーソルを操作できます。 アプリが基本的なポイント操作やクリック操作を必要とする(つまり D-pad コントローラだけでは機能しない)場合、この機能を宣言する必要があります。 これは最低限のタップ操作であるため、より複雑なタップ インターフェースを備えた端末で、この機能を宣言するアプリを使用することもできます。

注: デフォルトで、アプリは android.hardware.touchscreen 機能を必要とします。 疑似タップ インターフェースを備えた端末でアプリを使用できるようにしたい場合は、次のように、タッチスクリーンが必須ではないことを明示的に宣言する必要もあります。

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

アプリは疑似タップ インターフェースで個別に認識される 2 本以上の「指」をトラッキングします。 これは android.hardware.faketouch 機能のスーパーセットです。 この機能を必要に応じて宣言すると、アプリは、2 本以上の個別に認識される指のトラッキングをエミュレートする端末か、実際にタッチスクリーンを備えている端末のみと互換性があることを示します。

android.hardware.touchscreen.multitouch.distinct で定義された個別に認識されるマルチタップとは異なり、疑似タップ インターフェースを備え、個別に認識されるマルチタップをサポートする入力端末が、すべての 2 本指の操作をサポートしているわけではありません。その理由は、入力が画面上のカーソルの動きに変換されるためです。 つまり、このような端末では 1 本指の操作でカーソルが動き、2 本指のスワイプで 1 本指のタップイベントが発生し、その他の 2 本指の操作で対応する 2 本指のタップイベントをトリガーします。

トラックパッドを 2 本指でタップしてカーソルを移動可能な端末は、この機能をサポートしています。

android.hardware.faketouch.multitouch.jazzhand

アプリは疑似タップ インターフェースで 5 本以上の個別に認識される「指」をトラッキングします。 これは android.hardware.faketouch 機能のスーパーセットです。 この機能を必要に応じて宣言すると、アプリは、5 本以上の個別に認識される指のトラッキングをエミュレートする端末か、実際にタッチスクリーンを備えている端末のみと互換性があることを示します。

android.hardware.touchscreen.multitouch.jazzhand で定義された個別に認識されるマルチタップとは異なり、疑似タップ インターフェースを備え、jazzhand マルチタップをサポートする入力端末が、すべての 5 本指の操作をサポートしているわけではありません。その理由は、入力が画面上のカーソルの動きに変換されるためです。 つまり、このような端末ではマルチフィンガー操作でカーソルが動き、マルチフィンガー スワイプで 1 本指のタップイベントが発生し、その他のマルチフィンガー操作で対応するマルチフィンガーのタップイベントをトリガーします。

トラックパッドを 5 本指でタップしてカーソルを移動可能な端末は、この機能をサポートしています。

android.hardware.touchscreen

アプリは、フリング動作など、基本的なタップイベントよりもインタラクティブな操作に対応した端末のタッチスクリーン機能を使用します。 これは android.hardware.faketouch 機能のスーパーセットです。

デフォルトでは、アプリはこの機能が必要です。したがってデフォルトでは、エミュレートしたタップ インターフェース(「疑似タップ インターフェース」)のみを提供する端末では、アプリは使用できません。 疑似タップ インターフェースを提供する端末(さらに D-pad コントローラのみを提供する端末)でもアプリを使用できるようにしたい場合は、android.hardware.touchscreenandroid:required="false" と宣言することで、タッチスクリーンが必須ではないことを明示的に宣言する必要があります。 アプリで実際のタッチスクリーン インターフェースを使用し、ただしこの機能が必須ではない場合は、この宣言を追加してください。

アプリが実際にタッチスクリーン インターフェースを必要とする場合(フリングなど高度なタップ操作を実行するため)、タップ インターフェース機能はデフォルトで必要になっているため、宣言する必要はありません。 ただし、アプリが使用するすべての機能を明示的に宣言するのが最善です。

マルチフィンガー操作など、より複雑なタップ操作が必要な場合は、アプリが高度なタッチスクリーン機能を使用することを宣言する必要があります。

android.hardware.touchscreen.multitouch

アプリはピンチ操作など、端末の基本的な 2 点マルチタップ機能を使用します。ただし、アプリはタップを個別にトラックする必要はありません。 これは android.hardware.touchscreen 機能のスーパーセットです。

この機能を使用することで、アプリは android.hardware.touchscreen 機能の使用も暗黙的に要求します(この親機能が android:required="false" として宣言されている場合を除く)。

android.hardware.touchscreen.multitouch.distinct

アプリは 2 点以上を個別にトラッキングするため、端末の高度なマルチタップ機能を使用します。 この機能は android.hardware.touchscreen.multitouch 機能のスーパーセットです。

この機能を使用することで、アプリは android.hardware.touchscreen.multitouch 機能の使用も暗黙的に要求します(この親機能が android:required="false" として宣言されている場合を除く)。

android.hardware.touchscreen.multitouch.jazzhand

アプリは 5 点以上を個別にトラッキングするため、端末の高度なマルチタップ機能を使用します。 この機能は android.hardware.touchscreen.multitouch 機能のスーパーセットです。

この機能を使用することで、アプリは android.hardware.touchscreen.multitouch 機能の使用も暗黙的に要求します(この親機能が android:required="false" として宣言されている場合を除く)。

USB ハードウェア機能

android.hardware.usb.accessory
アプリは USB 端末として動作し、USB ホストに接続します。
android.hardware.usb.host
アプリは端末に接続された USB アクセサリを使用します。端末は USB ホストとして機能します。

Wi-Fi ハードウェア機能

android.hardware.wifi
アプリは端末の 802.11 ネットワーク(Wi-Fi)機能を使用します。
android.hardware.wifi.direct
アプリは端末の Wi-Fi Direct ネットワーク機能を使用します。

ソフトウェア機能

このセクションでは、最新のプラットフォーム リリースでサポートされているソフトウェア機能について説明します。 アプリがソフトウェア機能を使用または要求することを示すには、android:name 属性で、対応する値("android.software" で始まる)を宣言します。 ソフトウェア機能を宣言するときはそれぞれ、個別の <uses-feature> 要素を使用します。

通信ソフトウェア機能

android.software.sip
アプリはセッション開始プロトコル(SIP)サービスを使用します。SIP を使用すると、アプリはビデオ会議やインスタントメッセージなど、インターネット電話の操作をサポートできます。
android.software.sip.voip

アプリは SIP に基づいたボイス オーバー IP(VoIP)サービスを使用します。VoIP を使用すると、アプリは双方向のビデオ会議など、リアルタイムのインターネット電話の操作をサポートできます。

この機能を使用することで、アプリは android.software.sip 機能の使用も暗黙的に要求します(この親機能が android:required="false" として宣言されている場合を除く)。

android.software.webview
アプリはインターネットから取得したコンテンツを表示します。

カスタム入力ソフトウェア機能

android.software.input_methods
アプリは、デベロッパーが InputMethodService で定義する新しい入力方式を使用します。

端末管理ソフトウェア機能

android.software.backup
アプリにはバックアップおよび復元操作を処理するロジックが含まれています。
android.software.device_admin
アプリは端末管理者を使用して端末のポリシーを適用します。
android.software.managed_users
アプリはセカンダリ ユーザーと管理対象プロファイルをサポートします。
android.software.securely_removes_users
アプリはユーザーとユーザーに関連するデータを永続的に削除できます。
android.software.verified_boot
アプリには端末のセキュアブート機能の結果を処理するロジックが含まれており、再起動操作中に端末の構成が変更されたかどうかを検出します。

メディア ソフトウェア機能

android.software.midi
アプリは楽器に接続するか、Musical Instrument Digital Interface(MIDI)プロトコルを使用してサウンドを出力します。
android.software.print
アプリには、端末に表示されたドキュメントを印刷するためのコマンドが含まれています。
android.software.leanback
アプリは、テレビなどの大画面に表示するよう設計された UI を表示します。
android.software.live_tv
アプリは生放送のテレビ番組をストリーミングします。

画面インターフェースのソフトウェア機能

android.software.app_widgets
アプリはアプリ ウィジェットを使用または提供し、ユーザーがアプリ ウィジェットを配置できるホーム画面や同様の場所がある端末にのみインストールされるようにする必要があります。
android.software.home_screen
アプリは端末のホーム画面の代替機能として動作します。
android.software.live_wallpaper
アプリはアニメーションを含む壁紙を使用または提供します。

機能要件を伴うパーミッション

一部のハードウェアおよびソフトウェアの機能の定数は、対応する API よりも後に使用できるようになりました。たとえば、android.hardware.bluetooth 機能は Android 2.2(API レベル 8)で追加されましたが、この機能で参照する Bluetooth API は Android 2.0(API レベル 5)で追加されました。 このため、一部のアプリは、<uses-feature> システムを使用してこの API がアプリに必要であることを宣言できるようになる前に、この API を使用することができました。

このようにアプリが意図せずに使用可能になるのを防ぐため、Google Play はデフォルトで、特定のハードウェア関連のパーミッションにより、その基盤となるハードウェア機能が必要であることが示されていると見なします。 たとえば、Bluetooth を使用するアプリは <uses-permission> 要素で BLUETOOTH パーミッションを要求する必要があります。古いアプリについては、Google Play はパーミッションの宣言によって基盤となる android.hardware.bluetooth 機能がアプリに必要とされていると見なし、この機能に基づいてフィルタリングを設定します。 表 2 には、<uses-feature> 要素で宣言される機能要件と、同等の機能要件を暗黙的に示すパーミッションをまとめています。

<uses-feature> 宣言は、宣言された android:required 属性も含めて、表 2 のパーミッションによって暗黙的に示された機能よりも常に優先されます。これらのパーミッションに対して、<uses-feature> 要素で android:required="false" 属性を指定し、暗黙的に必要とされる機能を明示的に宣言することで、暗黙的に指定された機能に基づくフィルタリングを無効にすることができます。 たとえば、CAMERA パーミッションに基づくすべてのフィルタリングを無効にするには、マニフェスト ファイルにこの <uses-feature> 宣言を追加します。

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

表 2. 端末のハードウェアの使用を伴う端末のパーミッション

カテゴリ パーミッション 暗黙的な機能要件
BluetoothBLUETOOTHandroid.hardware.bluetooth

(詳細については、Bluetooth 機能の特殊な処理に関する記事をご覧ください)

BLUETOOTH_ADMINandroid.hardware.bluetooth
カメラCAMERAandroid.hardware.camera および
android.hardware.camera.autofocus
場所ACCESS_MOCK_LOCATIONandroid.hardware.location
ACCESS_LOCATION_EXTRA_COMMANDSandroid.hardware.location
INSTALL_LOCATION_PROVIDERandroid.hardware.location
ACCESS_COARSE_LOCATIONandroid.hardware.location.network および
android.hardware.location
ACCESS_FINE_LOCATIONandroid.hardware.location.gps および
android.hardware.location
マイクRECORD_AUDIOandroid.hardware.microphone
電話CALL_PHONEandroid.hardware.telephony
CALL_PRIVILEGEDandroid.hardware.telephony
MODIFY_PHONE_STATEandroid.hardware.telephony
PROCESS_OUTGOING_CALLSandroid.hardware.telephony
READ_SMSandroid.hardware.telephony
RECEIVE_SMSandroid.hardware.telephony
RECEIVE_MMSandroid.hardware.telephony
RECEIVE_WAP_PUSHandroid.hardware.telephony
SEND_SMSandroid.hardware.telephony
WRITE_APN_SETTINGSandroid.hardware.telephony
WRITE_SMSandroid.hardware.telephony
Wi-FiACCESS_WIFI_STATEandroid.hardware.wifi
CHANGE_WIFI_STATEandroid.hardware.wifi
CHANGE_WIFI_MULTICAST_STATEandroid.hardware.wifi