<uses-feature>

Google Play verwendet die <uses-feature>-Elemente, die in Ihrem App-Manifest deklariert sind, um Ihre App von Geräten zu filtern, die die Anforderungen an Hardware- und Softwarefunktionen nicht erfüllen.

Wenn Sie die für Ihre App erforderlichen Funktionen angeben, kann Google Play Ihre App nur Nutzern präsentieren, deren Geräte die Funktionsanforderungen der App erfüllen, anstatt sie allen Nutzern anzuzeigen.

Wichtige Informationen dazu, wie Google Play Funktionen als Grundlage für die Filterung verwendet, finden Sie im Abschnitt Google Play und funktionsbasierte Filterung.

syntax:
<uses-feature
  android:name="string"
  android:required=["true" | "false"]
  android:glEsVersion="integer" />
enthalten in:
<manifest>
description:

Hier wird eine einzelne Hardware- oder Softwarefunktion deklariert, die von der Anwendung verwendet wird.

Der Zweck einer <uses-feature>-Erklärung besteht darin, externe Entitäten über die Hardware- und Softwarefunktionen zu informieren, von denen Ihre Anwendung abhängt. Das Element bietet das Attribut required, mit dem Sie angeben können, ob Ihre Anwendung die deklarierte Funktion benötigt und ohne sie nicht funktioniert oder ob die Funktion zwar bevorzugt, aber nicht unbedingt erforderlich ist.

Da die Funktionsunterstützung je nach Android-Gerät variieren kann, spielt das Element <uses-feature> eine wichtige Rolle, da es einer App ermöglicht, die von ihr verwendeten geräteabhängigen Funktionen zu beschreiben.

Die von Ihrer Anwendung deklarierten verfügbaren Funktionen entsprechen den Funktionskonstanten, die von der Android-PackageManager zur Verfügung gestellt werden. Die Funktionskonstanten finden Sie in diesem Dokument im Abschnitt Referenz zu Funktionen.

Sie müssen jedes Element in einem separaten <uses-feature>-Element angeben. Wenn Ihre Anwendung also mehrere Elemente erfordert, werden mehrere <uses-feature>-Elemente deklariert. Eine Anwendung, für die sowohl Bluetooth- als auch Kamerafunktionen auf dem Gerät erforderlich sind, deklariert beispielsweise diese beiden Elemente:

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

Deklarieren Sie im Allgemeinen immer <uses-feature>-Elemente für alle Funktionen, die Ihre Anwendung benötigt.

Deklarierte <uses-feature>-Elemente dienen nur zu Informationszwecken. Das Android-System selbst prüft also nicht vor der Installation einer Anwendung, ob die entsprechende Funktion auf dem Gerät unterstützt wird.

Andere Dienste wie Google Play und andere Apps können jedoch die <uses-feature>-Erklärungen Ihrer App im Rahmen der Verarbeitung oder Interaktion mit Ihrer App prüfen. Daher ist es sehr wichtig, dass Sie alle Funktionen angeben, die in Ihrer Anwendung verwendet werden.

Für einige Funktionen gibt es möglicherweise ein bestimmtes Attribut, mit dem Sie eine Version der Funktion definieren können, z. B. die verwendete Open-GL-Version (deklariert mit glEsVersion). Andere Funktionen, die für ein Gerät vorhanden sind oder nicht, z. B. eine Kamera, werden mit dem Attribut name deklariert.

Das <uses-feature>-Element ist zwar nur für Geräte mit API-Level 4 oder höher aktiviert, Sie sollten es aber für alle Apps angeben, auch wenn minSdkVersion 3 oder niedriger ist. Auf Geräten mit älteren Versionen der Plattform wird das Element ignoriert.

Hinweis:Wenn Sie eine Funktion deklarieren, müssen Sie gegebenenfalls auch Berechtigungen anfordern. Sie müssen beispielsweise die Berechtigung CAMERA anfordern, bevor Ihre Anwendung auf die Kamera API zugreifen kann. Wenn Sie die Berechtigung anfordern, erhält Ihre Anwendung Zugriff auf die entsprechende Hardware und Software. Wenn Sie die von Ihrer App verwendeten Funktionen deklarieren, können Sie die Gerätekompatibilität verbessern.

attributes:
android:name
Gibt eine einzelne Hardware- oder Softwarefunktion an, die von der Anwendung als Descriptor-String verwendet wird. Gültige Attributwerte sind in den Abschnitten Hardwarefunktionen und Softwarefunktionen aufgeführt. Bei diesen Attributwerten wird die Groß- und Kleinschreibung beachtet.
android:required
Boolescher Wert, der angibt, ob für die Anwendung die in android:name angegebene Funktion erforderlich ist.
  • Wenn Sie android:required="true" für eine Funktion deklarieren, bedeutet das, dass die Anwendung nicht funktioniert oder nicht dafür vorgesehen ist, wenn die angegebene Funktion nicht auf dem Gerät vorhanden ist.
  • Wenn Sie android:required="false" für eine Funktion deklarieren, bedeutet das, dass die Anwendung die Funktion verwendet, sofern sie auf dem Gerät vorhanden ist, aber bei Bedarf auch ohne die angegebene Funktion funktioniert.

Der Standardwert für android:required ist "true".

android:glEsVersion
Die von der Anwendung erforderliche OpenGL ES-Version. Die oberen 16 Bit stellen die Major-Nummer dar und die unteren 16 Bit die Minor-Nummer. Wenn Sie beispielsweise OpenGL ES 2.0 angeben möchten, legen Sie den Wert auf „0x00020000“ fest. Für OpenGL ES 3.2 lautet der Wert „0x00030002“.

Eine Anwendung gibt in ihrem Manifest höchstens ein android:glEsVersion-Attribut an. Wenn mehrere Werte angegeben sind, wird der android:glEsVersion mit dem numerisch höchsten Wert verwendet und alle anderen Werte werden ignoriert.

Wenn für eine Anwendung kein android:glEsVersion-Attribut angegeben ist, wird davon ausgegangen, dass für die Anwendung nur OpenGL ES 1.0 erforderlich ist, das von allen Android-Geräten unterstützt wird.

Eine Anwendung kann davon ausgehen, dass eine Plattform, die eine bestimmte OpenGL ES-Version unterstützt, auch alle numerisch niedrigeren OpenGL ES-Versionen unterstützt. Geben Sie daher für eine Anwendung, für die sowohl OpenGL ES 1.0 als auch OpenGL ES 2.0 erforderlich sind, an, dass OpenGL ES 2.0 erforderlich ist.

Geben Sie für eine Anwendung, die mit mehreren OpenGL ES-Versionen funktioniert, nur die numerisch niedrigste erforderliche OpenGL ES-Version an. Es kann zur Laufzeit geprüft werden, ob eine höhere OpenGL ES-Version verfügbar ist.

Weitere Informationen zur Verwendung von OpenGL ES, einschließlich der Möglichkeit, die unterstützte OpenGL ES-Version zur Laufzeit zu prüfen, finden Sie im OpenGL ES API-Leitfaden.

eingeführt in:
API-Level 4
Weitere Informationen:

Google Play und funktionsbasierte Filter

Google Play filtert die für Nutzer sichtbaren Apps, damit Nutzer nur Apps sehen und herunterladen können, die mit ihrem Gerät kompatibel sind. Unter anderem werden Apps nach Funktionskompatibilität gefiltert.

Um die Funktionskompatibilität einer Anwendung mit dem Gerät eines bestimmten Nutzers zu ermitteln, vergleicht Google Play Folgendes:

  • Von der Anwendung benötigte Funktionen, wie in den <uses-feature>-Elementen im Manifest der Anwendung deklariert.
  • Auf dem Gerät verfügbare Funktionen, in Hardware oder Software, wie sie über schreibgeschützte Systemeigenschaften gemeldet werden.

Für einen genauen Vergleich von Funktionen bietet der Android-Paketmanager eine gemeinsame Reihe von Funktionskonstanten, mit denen sowohl Anwendungen als auch Geräte Funktionsanforderungen und ‑unterstützung angeben können. Die verfügbaren Funktionskonstanten sind in diesem Dokument im Abschnitt Referenz zu Funktionen und in der Klassendokumentation für PackageManager aufgeführt.

Wenn der Nutzer Google Play startet, fragt die Anwendung den Paketmanager über getSystemAvailableFeatures() nach der Liste der auf dem Gerät verfügbaren Funktionen ab. Die Store-Anwendung übergibt die Liste der Funktionen dann an Google Play, wenn die Sitzung für den Nutzer eingerichtet wird.

Jedes Mal, wenn Sie eine Anwendung in die Google Play Console hochladen, wird die Manifestdatei der Anwendung von Google Play gescannt. Es sucht nach <uses-feature>-Elementen und bewertet sie in Kombination mit anderen Elementen, z. B. <uses-sdk>- und <uses-permission>-Elementen. Nachdem die erforderlichen Funktionen der Anwendung festgelegt wurden, wird diese Liste intern als Metadaten gespeichert, die mit dem APK der Anwendung und der Anwendungsversion verknüpft sind.

Wenn ein Nutzer über die Google Play App nach Apps sucht oder diese durchsucht, vergleicht der Dienst die von den einzelnen Apps benötigten Funktionen mit den auf dem Gerät des Nutzers verfügbaren Funktionen. Wenn alle erforderlichen Funktionen einer App auf dem Gerät vorhanden sind, kann der Nutzer die App bei Google Play sehen und gegebenenfalls herunterladen.

Wenn eine erforderliche Funktion vom Gerät nicht unterstützt wird, filtert Google Play die Anwendung so, dass sie für den Nutzer nicht sichtbar ist oder nicht zum Download verfügbar ist.

Da die in <uses-feature>-Elementen deklarierten Funktionen direkt darauf einwirken, wie Google Play Ihre App filtert, ist es wichtig zu verstehen, wie Google Play das Manifest der App bewertet und die erforderlichen Funktionen festlegt. Weitere Informationen finden Sie in den folgenden Abschnitten.

Filtern nach explizit erklärten Funktionen

Eine explizit deklarierte Funktion ist eine Funktion, die in Ihrer Anwendung in einem <uses-feature>-Element deklariert wird. Die Funktionsdeklaration kann ein android:required=["true" | "false"]-Attribut enthalten, wenn Sie mit API-Level 5 oder höher kompilieren.

So können Sie angeben, ob die Funktion für die App erforderlich ist und sie ohne sie nicht richtig funktioniert ("true") oder ob die Funktion bei Verfügbarkeit verwendet wird, die App aber auch ohne sie funktioniert ("false").

Google Play behandelt explizit deklarierte Funktionen so:

  • Wenn eine Funktion explizit als erforderlich deklariert wird, wie im folgenden Beispiel, wird sie von Google Play der Liste der erforderlichen Funktionen für die Anwendung hinzugefügt. Die Anwendung wird dann für Nutzer auf Geräten gefiltert, die diese Funktion nicht bieten.
    <uses-feature android:name="android.hardware.camera.any" android:required="true" />
  • Wenn eine Funktion wie im folgenden Beispiel ausdrücklich als nicht erforderlich deklariert wird, wird sie von Google Play nicht der Liste der erforderlichen Funktionen hinzugefügt. Aus diesem Grund wird eine explizit als nicht erforderlich deklarierte Funktion beim Filtern der Anwendung nie berücksichtigt. Auch wenn das Gerät die angegebene Funktion nicht bietet, betrachtet Google Play die Anwendung als mit dem Gerät kompatibel und zeigt sie dem Nutzer an, sofern keine anderen Filterregeln gelten.
    <uses-feature android:name="android.hardware.camera" android:required="false" />
  • Wenn eine Funktion explizit deklariert, aber ohne ein android:required-Attribut deklariert wird, geht Google Play davon aus, dass die Funktion erforderlich ist, und richtet eine Filterung dafür ein.

Wenn Ihre Anwendung für Android 1.6 und niedriger entwickelt wurde, ist das android:required-Attribut in der API in der Regel nicht verfügbar. Google Play geht dann davon aus, dass alle android:required-Deklarationen erforderlich sind.<uses-feature>

Hinweis:Wenn Sie eine Funktion explizit deklarieren und ein android:required="false"-Attribut angeben, können Sie die gesamte Filterung bei Google Play für die angegebene Funktion effektiv deaktivieren.

Nach impliziten Funktionen filtern

Eine implizite Funktion ist eine Funktion, die für die ordnungsgemäße Funktion einer Anwendung erforderlich ist, aber nicht in einem <uses-feature>-Element in der Manifestdatei deklariert ist. Streng genommen sollten für jede Anwendung immer alle Funktionen deklariert werden, die sie verwendet oder benötigt. Das Fehlen einer Deklaration für eine von einer Anwendung verwendete Funktion kann als Fehler betrachtet werden.

Als Schutzmaßnahme für Nutzer und Entwickler sucht Google Play jedoch in jeder Anwendung nach impliziten Funktionen und richtet Filter für diese Funktionen ein, genau wie für explizit deklarierte Funktionen.

Eine Anwendung kann eine Funktion erfordern, sie aber aus folgenden Gründen nicht deklarieren:

  • Die Anwendung wurde mit einer älteren Version der Android-Bibliothek (Android 1.5 oder älter) kompiliert, für die das Element <uses-feature> nicht verfügbar ist.
  • Der Entwickler geht fälschlicherweise davon aus, dass die Funktion auf allen Geräten vorhanden ist und eine Erklärung nicht erforderlich ist.
  • Der Entwickler hat die Funktionserklärung versehentlich weggelassen.
  • Der Entwickler erklärt die Funktion explizit, die Erklärung ist jedoch ungültig. Beispielsweise führt ein Rechtschreibfehler im Namen des <uses-feature>-Elements oder ein nicht erkannter Stringwert für das android:name-Attribut dazu, dass die Featuredeklaration ungültig wird.

Um diese Fälle zu berücksichtigen, versucht Google Play, die impliziten Funktionsanforderungen einer App zu ermitteln, indem andere Elemente in der Manifestdatei geprüft werden, insbesondere <uses-permission>-Elemente.

Wenn eine Anwendung hardwarebezogene Berechtigungen anfordert, geht Google Play davon aus, dass die Anwendung die zugrunde liegenden Hardwarefunktionen verwendet und diese Funktionen daher benötigt, auch wenn es keine entsprechenden <uses-feature>-Erklärungen gibt. Für solche Berechtigungen fügt Google Play die zugrunde liegenden Hardwarefunktionen den Metadaten hinzu, die für die Anwendung gespeichert werden, und richtet Filter dafür ein.

Wenn eine App beispielsweise die Berechtigung CAMERA anfordert, geht Google Play davon aus, dass für die App eine Rückkamera (nach außen gerichtete Kamera) erforderlich ist, auch wenn die App kein <uses-feature>-Element für android.hardware.camera deklariert. Daher werden bei Google Play Geräte herausgefiltert, die keine Rückkamera haben.

Wenn Sie nicht möchten, dass Google Play anhand einer bestimmten impliziten Funktion filtert, deklarieren Sie die Funktion explizit in einem <uses-feature>-Element und fügen Sie das android:required="false"-Attribut hinzu. Wenn Sie beispielsweise das Filtern deaktivieren möchten, das durch die Berechtigung CAMERA impliziert wird, deklarieren Sie die folgenden Funktionen:

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

Achtung:Berechtigungen, die Sie in <uses-permission>-Elementen anfordern, können sich direkt darauf auswirken, wie Google Play Ihre App filtert. Im Abschnitt Berechtigungen, die Funktionsanforderungen implizieren sind alle Berechtigungen aufgeführt, die Funktionsanforderungen implizieren und daher eine Filterung auslösen.

Besondere Verarbeitungsvorgänge bei der Bluetooth-Funktion

Google Play wendet bei der Bestimmung der Filterung für Bluetooth leicht andere Regeln als im vorherigen Beispiel an.

Wenn eine App eine Bluetooth-Berechtigung in einem <uses-permission>-Element deklariert, die Bluetooth-Funktion aber nicht explizit in einem <uses-feature>-Element deklariert, prüft Google Play die Versionen der Android-Plattform, auf der die App ausgeführt werden soll, wie im <uses-sdk>-Element angegeben.

Wie in der folgenden Tabelle dargestellt, ermöglicht Google Play die Filterung für die Bluetooth-Funktion nur, wenn die Anwendung Android 2.0 (API-Level 5) oder höher als niedrigste oder Zielplattform angibt. Beachten Sie jedoch, dass Google Play die normalen Filterregeln anwendet, wenn die Bluetooth-Funktion in der Anwendung explizit in einem <uses-feature>-Element deklariert wird.

Tabelle 1 So ermittelt Google Play die Bluetooth-Funktionsanforderung für eine Anwendung, die eine Bluetooth-Berechtigung anfordert, die Bluetooth-Funktion aber nicht in einem <uses-feature>-Element deklariert.

Wenn minSdkVersion und targetSdkVersion ist Ergebnis
<=4 oder <uses-sdk> ist nicht deklariert <=4 Google Play filtert die Anwendung nicht auf Geräten heraus, die die android.hardware.bluetooth-Funktion angeblich unterstützen.
<=4 >=5 Google Play filtert die Anwendung von allen Geräten heraus, die die android.hardware.bluetooth-Funktion nicht unterstützen (einschließlich älterer Releases).
>=5 >=5

Die folgenden Beispiele veranschaulichen die verschiedenen Filtereffekte, die sich aus der Art und Weise ergeben, wie Google Play mit der Bluetooth-Funktion umgeht.

Im ersten Beispiel deklariert eine Anwendung, die für ältere API-Levels entwickelt wurde, eine Bluetooth-Berechtigung, aber nicht die Bluetooth-Funktion in einem <uses-feature>-Element.
Ergebnis:Google Play filtert die Anwendung nicht von einem Gerät.
<manifest ...>
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" />
    ...
</manifest>
Im zweiten Beispiel deklariert dieselbe Anwendung auch eine Ziel-API-Ebene von „5“.
Ergebnis:Google Play geht jetzt davon aus, dass die Funktion erforderlich ist, und filtert die Anwendung von allen Geräten heraus, auf denen keine Bluetooth-Unterstützung gemeldet wird, einschließlich Geräten mit älteren Versionen der Plattform.
<manifest ...>
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>
Hier wird in derselben Anwendung jetzt die Bluetooth-Funktion deklariert.
Ergebnis: Wie im vorherigen Beispiel wird ein Filter angewendet.
<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>
Im folgenden Fall fügt dieselbe Anwendung ein android:required="false"-Attribut hinzu.
Ergebnis:Google Play deaktiviert die Filterung basierend auf der Unterstützung von Bluetooth-Funktionen für alle Geräte.
<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>

Für die App erforderliche Funktionen testen

Mit dem im Android SDK enthaltenen Tool aapt2 können Sie ermitteln, wie Google Play Ihre Anwendung basierend auf den angegebenen Funktionen und Berechtigungen filtert. Führen Sie dazu aapt2 mit dem Befehl dump badging aus. Dadurch wird das Manifest Ihrer Anwendung von aapt2 geparst und dieselben Regeln angewendet, die auch von Google Play verwendet werden, um die für Ihre Anwendung erforderlichen Funktionen zu ermitteln.

So verwenden Sie das Tool:

  1. Erstellen und exportieren Sie Ihre Anwendung als nicht signiertes APK. Wenn Sie in Android Studio entwickeln, erstellen Sie Ihre Anwendung mit Gradle. Gehen Sie dazu so vor:
    1. Öffnen Sie das Projekt und wählen Sie Ausführen > Konfigurationen bearbeiten aus.
    2. Klicken Sie im Fenster Ausführungs-/Fehlerbehebungskonfigurationen oben links auf das Pluszeichen.
    3. Wählen Sie Gradle aus.
    4. Geben Sie unter Name „Unsigned APK“ ein.
    5. Wählen Sie im Bereich Gradle-Projekt Ihr Modul aus.
    6. Geben Sie unter Aufgaben „assemble“ ein.
    7. Wählen Sie OK aus, um die neue Konfiguration abzuschließen.
    8. Achten Sie darauf, dass in der Symbolleiste die Ausführungskonfiguration Unsigned APK ausgewählt ist, und wählen Sie dann Ausführen > Unsigned APK ausführen aus.
    Sie finden das signaturlose APK im Verzeichnis <ProjectName>/app/build/outputs/apk/.
  2. Suchen Sie das aapt2-Tool, falls es noch nicht in Ihrem PATH enthalten ist. Wenn Sie SDK Tools r8 oder höher verwenden, finden Sie aapt2 im Verzeichnis <SDK>/build-tools/<tools version number>.

    Hinweis:Sie müssen die Version von aapt2 verwenden, die für die neueste verfügbare Build-Tools-Komponente bereitgestellt wird. Wenn Sie die neueste Build-Tools-Komponente nicht haben, laden Sie sie mit dem Android SDK Manager herunter.

  3. Führen Sie aapt2 mit der folgenden Syntax aus:
$ aapt2 dump badging <path_to_exported_.apk>

Hier ein Beispiel für die Befehlsausgabe für das zweite Bluetooth-Beispiel oben:

$ ./aapt2 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'

Referenz zu Funktionen

In den folgenden Abschnitten finden Sie Referenzinformationen zu Hardware- und Softwarefunktionen sowie Berechtigungsgruppen, die bestimmte Funktionsanforderungen implizieren.

Hardware-Funktionen

In diesem Abschnitt werden die Hardwarefunktionen aufgeführt, die von der aktuellen Plattformversion unterstützt werden. Wenn Ihre App eine Hardwarefunktion verwendet oder benötigt, geben Sie den entsprechenden Wert, der mit "android.hardware" beginnt, in einem android:name-Attribut an. Verwenden Sie jedes Mal, wenn Sie eine Hardwarefunktion deklarieren, ein separates <uses-feature>-Element.

Audiohardwarefunktionen

android.hardware.audio.low_latency
Die App nutzt die Audiopipeline mit niedriger Latenz des Geräts, wodurch Verzögerungen bei der Verarbeitung von Audioeingabe oder -ausgabe reduziert werden.
android.hardware.audio.output
Die App überträgt Audio über die Lautsprecher, den Audioanschluss, die Bluetooth-Streamingfunktionen oder einen ähnlichen Mechanismus des Geräts.
android.hardware.audio.pro
Die App nutzt die High-End-Audiofunktionen und die Leistung des Geräts.
android.hardware.microphone
Die App nimmt Audio über das Mikrofon des Geräts auf.

Bluetooth-Hardwarefunktionen

android.hardware.bluetooth
Die App nutzt die Bluetooth-Funktionen des Geräts, in der Regel, um mit anderen Bluetooth-fähigen Geräten zu kommunizieren.
android.hardware.bluetooth_le
Die App nutzt die Bluetooth Low Energy-Funkfunktionen des Geräts.

Kamera-Hardwarefunktionen

Hinweis:Um eine unnötige Filterung Ihrer App durch Google Play zu vermeiden, fügen Sie allen Kamerafunktionen, die Ihre App nicht benötigt, android:required="false" hinzu. Andernfalls geht Google Play davon aus, dass die Funktion erforderlich ist, und verhindert, dass Geräte, die die Funktion nicht unterstützen, auf Ihre App zugreifen.

Unterstützung für große Displays

Einige Geräte mit großem Bildschirm unterstützen nicht alle Kamerafunktionen. Chromebooks haben in der Regel keine Rückkameras, keinen Autofokus und keinen Blitz. Chromebooks haben jedoch eine Frontkamera und sind oft mit externen Kameras verbunden.

Wenn Sie grundlegenden Kamerasupport anbieten und Ihre App für möglichst viele Geräte verfügbar machen möchten, fügen Sie Ihrem App-Manifest die folgenden Einstellungen für Kamerafunktionen hinzu:

<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" />

Passen Sie die Funktionseinstellungen an die Anwendungsfälle Ihrer App an. Damit Ihre App jedoch für möglichst viele Geräte verfügbar ist, sollten Sie immer das required-Attribut angeben, um ausdrücklich anzugeben, ob eine Funktion ein Muss ist.

Funktionsliste
android.hardware.camera.any

Die App verwendet eine der Kameras des Geräts oder eine externe Kamera, die mit dem Gerät verbunden ist. Verwenden Sie diese Funktion anstelle von android.hardware.camera oder android.hardware.camera.front, wenn in Ihrer App die Kamera nicht auf die Umgebung oder auf den Nutzer gerichtet sein muss.

Die Berechtigung CAMERA impliziert, dass Ihre App auch android.hardware.camera verwendet. Eine Rückkamera ist erforderlich, es sei denn, android.hardware.camera wird mit android:required="false" deklariert.

android.hardware.camera

Die App verwendet die Rückkamera des Geräts.

Achtung:Geräte wie Chromebooks, die nur eine Frontkamera haben, unterstützen diese Funktion nicht. Verwenden Sie android.hardware.camera.any, wenn Ihre App jede Kamera verwenden kann, unabhängig von der Ausrichtung der Kamera.

Hinweis:Die Berechtigung CAMERA setzt voraus, dass eine Rückkamera vorhanden ist. Damit bei Google Play eine ordnungsgemäße Filterung erfolgt, wenn Ihr App-Manifest die Berechtigung CAMERA enthält, geben Sie ausdrücklich an, dass Ihre App die Funktion camera verwendet, und geben Sie an, ob sie erforderlich ist. Beispiel:
<uses-feature android:name="android.hardware.camera" android:required="false" />

android.hardware.camera.front

Die App verwendet die Frontkamera des Geräts.

Die Berechtigung CAMERA impliziert, dass Ihre App auch android.hardware.camera verwendet. Eine Rückkamera ist erforderlich, es sei denn, android.hardware.camera ist mit android:required="false" deklariert.

Achtung:Wenn Ihre App android.hardware.camera.front verwendet, aber android.hardware.camera nicht explizit mit android.required="false" deklariert, werden Geräte ohne Rückkamera (z. B. Chromebooks) von Google Play herausgefiltert. Wenn Ihre App nur Geräte mit Frontkameras unterstützt, deklarieren Sie android.hardware.camera mit android.required="false", um unnötiges Filtern zu vermeiden.

android.hardware.camera.external

Die App kommuniziert mit einer externen Kamera, die der Nutzer mit dem Gerät verbindet. Diese Funktion ist keine Garantie dafür, dass eine externe Kamera für Ihre App verfügbar ist.

Die Berechtigung CAMERA impliziert, dass Ihre App auch android.hardware.camera verwendet. Eine Rückkamera ist erforderlich, es sei denn, android.hardware.camera ist mit android:required="false" deklariert.

android.hardware.camera.autofocus

Die App verwendet die Autofokusfunktion, die von der Kamera des Geräts unterstützt wird.

Hinweis:Die Berechtigung CAMERA setzt voraus, dass der Autofokus eine erforderliche Funktion ist. Damit bei Google Play eine ordnungsgemäße Filterung erfolgen kann, wenn Ihr App-Manifest die Berechtigung CAMERA enthält, geben Sie ausdrücklich an, dass Ihre App die Autofokusfunktion verwendet, und geben Sie an, ob sie erforderlich ist oder nicht. Beispiel:
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />.

android.hardware.camera.flash

Die App verwendet die Blitzfunktion, die von der Kamera des Geräts unterstützt wird.

android.hardware.camera.capability.manual_post_processing

Die App verwendet die MANUAL_POST_PROCESSING-Funktion, die von der Kamera des Geräts unterstützt wird.

Mit dieser Funktion kann Ihre App die automatische Weißabgleichfunktion der Kamera überschreiben. Verwenden Sie android.colorCorrection.transform, android.colorCorrection.gains und eine android.colorCorrection.mode von TRANSFORM_MATRIX.

android.hardware.camera.capability.manual_sensor

Die App verwendet die MANUAL_SENSOR-Funktion, die von der Kamera des Geräts unterstützt wird.

Diese Funktion setzt die Unterstützung der automatischen Belichtungssperre (android.control.aeLock) voraus, mit der die Belichtungszeit und Empfindlichkeit der Kamera auf bestimmte Werte festgelegt werden können.

android.hardware.camera.capability.raw

Die App verwendet die RAW-Funktion, die von der Kamera des Geräts unterstützt wird.

Diese Funktion setzt voraus, dass das Gerät DNG-Dateien (Raw) speichern kann. Die Kamera des Geräts liefert die DNG-bezogenen Metadaten, die für die direkte Verarbeitung der Rohbilder in Ihrer App erforderlich sind.

android.hardware.camera.level.full
Die App verwendet die FULL-Ebene der Bildaufnahme, die von mindestens einer der Kameras des Geräts unterstützt wird. FULL umfasst Funktionen für Serienaufnahmen, eine Frame-für-Frame-Steuerung und eine manuelle Nachbearbeitung. Weitere Informationen finden Sie unter INFO_SUPPORTED_HARDWARE_LEVEL_FULL.

Hardwarefunktionen der Geräte-UI

android.hardware.type.automotive

Die App ist so konzipiert, dass die Benutzeroberfläche auf mehreren Bildschirmen in einem Fahrzeug angezeigt wird. Die Nutzer interagieren mit der App über physische Tasten, Touchbedienung, Drehregler und mausähnliche Oberflächen. Die Bildschirme des Fahrzeugs befinden sich normalerweise in der Mittelkonsole oder im Kombiinstrument.

Hinweis : Weitere Informationen zur Verwendung dieser Funktion und Anleitungen zum Erstellen von Apps für Autos finden Sie unter In Autos bereitstellen.

android.hardware.type.television

(Verworfen, verwenden Sie stattdessen android.software.leanback.)

Die App ist für die Darstellung auf einem Fernseher konzipiert. Bei dieser Funktion wird „Fernsehen“ als typisches Fernseherlebnis im Wohnzimmer definiert: Die App wird auf einem großen Bildschirm angezeigt, der Nutzer sitzt weit entfernt und die vorherrschende Eingabeform ist ein D-Pad, keine Maus, kein Zeiger oder Touchgerät.

android.hardware.type.watch
Die App ist für die Darstellung auf einer Smartwatch konzipiert. Eine Uhr wird am Körper getragen, z. B. am Handgelenk. Der Nutzer ist sehr nah am Gerät, während er damit interagiert.
android.hardware.type.pc

Die App ist für die Darstellung der Benutzeroberfläche auf Chromebooks konzipiert. Diese Funktion deaktiviert die Eingabe-Emulation für Maus und Touchpad, da Chromebooks Maus- und Touchpad-Hardware verwenden. Weitere Informationen finden Sie unter Mausinput.

Hinweis:Legen Sie für dieses Element required="false" fest. Andernfalls ist Ihre App im Google Play Store für andere Geräte als Chromebooks nicht verfügbar.

Funktionen der Fingerabdruckhardware

android.hardware.fingerprint
Die App liest Fingerabdrücke mit der biometrischen Hardware des Geräts.

Hardwarefunktionen des Gamepads

android.hardware.gamepad
Die App erfasst die Eingaben des Gamepads, entweder vom Gerät selbst oder von einem verbundenen Gamepad.

Infrarot-Hardwarefunktionen

android.hardware.consumerir
Die App nutzt die Infrarotfunktionen (IR) des Geräts, in der Regel, um mit anderen Infrarot-Geräten zu kommunizieren.

Hardwarefunktionen für die Standortermittlung

android.hardware.location
Die App verwendet eine oder mehrere Funktionen auf dem Gerät zur Standortbestimmung, z. B. den GPS-Standort, den Netzwerkstandort oder den Mobilfunkstandort.
android.hardware.location.gps

Die App verwendet genaue Standortkoordinaten, die von einem GPS-Empfänger (Global Positioning System) auf dem Gerät erfasst werden.

Wenn eine App diese Funktion verwendet, impliziert sie, dass sie auch die Funktion android.hardware.location verwendet, es sei denn, diese übergeordnete Funktion ist mit dem Attribut android:required="false" deklariert.

android.hardware.location.network

Die App verwendet ungefähre Standortkoordinaten, die von einem netzwerkbasierten Geolocation-System stammen, das auf dem Gerät unterstützt wird.

Wenn eine App diese Funktion verwendet, impliziert sie, dass sie auch die Funktion android.hardware.location verwendet, es sei denn, diese übergeordnete Funktion ist mit dem Attribut android:required="false" deklariert.

NFC-Hardwarefunktionen

android.hardware.nfc
Die App nutzt die NFC-Funkfunktionen des Geräts.
android.hardware.nfc.hce

Die App verwendet die NFC-Kartenemulation, die auf dem Gerät gehostet wird.

OpenGL ES-Hardwarefunktionen

android.hardware.opengles.aep
Die App verwendet das OpenGL ES Android Extension Pack, das auf dem Gerät installiert ist.

Sensorhardwarefunktionen

android.hardware.sensor.accelerometer
Die App verwendet Bewegungsmessungen des Beschleunigungsmessers des Geräts, um die aktuelle Ausrichtung des Geräts zu erkennen. So kann eine App beispielsweise Beschleunigungsmesserdaten verwenden, um zu bestimmen, wann zwischen Hoch- und Querformat gewechselt werden soll.
android.hardware.sensor.ambient_temperature
Die App verwendet den Umgebungstemperatursensor des Geräts. So kann eine Wetter-App beispielsweise die Innen- oder Außentemperatur melden.
android.hardware.sensor.barometer
Die App verwendet das Barometer des Geräts. Eine Wetter-App kann beispielsweise den Luftdruck melden.
android.hardware.sensor.compass
Die App verwendet das Magnetometer (Kompass) des Geräts. Eine Navigations-App könnte beispielsweise die aktuelle Richtung anzeigen, in die sich ein Nutzer befindet.
android.hardware.sensor.gyroscope
Die App verwendet das Gyroskop des Geräts, um Drehungen und Verdrehungen zu erkennen und ein sechsachsiges Ausrichtungssystem zu erstellen. Mit diesem Sensor kann eine App reibungsloser erkennen, wann zwischen Hoch- und Querformat gewechselt werden muss.
android.hardware.sensor.hifi_sensors
Die App verwendet die Hi-Fi-Sensoren (High Fidelity) des Geräts. So kann beispielsweise eine Gaming-App die Bewegungen des Nutzers mit hoher Präzision erkennen.
android.hardware.sensor.heartrate
Die App verwendet den Herzfrequenzsensor des Geräts. Eine Fitness-App kann beispielsweise Trends bei der Herzfrequenz eines Nutzers im Zeitverlauf melden.
android.hardware.sensor.heartrate.ecg
Die App verwendet den EKG-Herzfrequenzsensor des Geräts. Eine Fitness-App kann beispielsweise detailliertere Informationen zur Herzfrequenz eines Nutzers melden.
android.hardware.sensor.light
Die App verwendet den Lichtsensor des Geräts. So kann eine App beispielsweise je nach Umgebungslicht eines von zwei Farbschemata anzeigen.
android.hardware.sensor.proximity
Die App verwendet den Näherungssensor des Geräts. So kann eine Telefon-App beispielsweise den Bildschirm des Geräts ausschalten, wenn die App erkennt, dass der Nutzer das Gerät nah am Körper hält.
android.hardware.sensor.relative_humidity
Die App verwendet den Sensor für die relative Luftfeuchtigkeit des Geräts. So kann beispielsweise in einer Wetter-App die Luftfeuchtigkeit verwendet werden, um den aktuellen Taupunkt zu berechnen und anzugeben.
android.hardware.sensor.stepcounter
Die App verwendet den Schrittzähler des Geräts. Eine Fitness-App könnte beispielsweise die Anzahl der Schritte melden, die ein Nutzer gehen muss, um sein Tagesziel zu erreichen.
android.hardware.sensor.stepdetector
Die App verwendet den Schrittzähler des Geräts. Eine Fitness-App kann beispielsweise anhand des Zeitintervalls zwischen den Schritten die Art der Aktivität des Nutzers ableiten.

Bildschirm-Hardwarefunktionen

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

Für die App muss das Gerät im Hoch- oder Querformat gehalten werden. Wenn Ihre App beide Ausrichtungen unterstützt, müssen Sie keine der beiden Funktionen deklarieren.

Wenn für Ihre App beispielsweise die Hochformatausrichtung erforderlich ist, deklarieren Sie die folgende Funktion, damit Ihre App nur auf Geräten ausgeführt werden kann, die die Hochformatausrichtung immer oder auf Nutzerwunsch unterstützen:

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

Es wird davon ausgegangen, dass beide Ausrichtungen standardmäßig nicht erforderlich sind. Ihre App kann also auf Geräten installiert werden, die eine oder beide Ausrichtungen unterstützen. Wenn jedoch für eine Ihrer Aktivitäten die Ausführung in einer bestimmten Ausrichtung angefordert wird, indem das Attribut android:screenOrientation verwendet wird, bedeutet diese Erklärung, dass Ihre App diese Ausrichtung erfordert.

Wenn Sie beispielsweise android:screenOrientation mit "landscape", "reverseLandscape" oder "sensorLandscape" deklarieren, ist Ihre App nur auf Geräten verfügbar, die die Querformatausrichtung unterstützen.

Es hat sich bewährt, die Anforderung für diese Ausrichtung mit einem <uses-feature>-Element anzugeben. Wenn Sie eine Ausrichtung für Ihre Aktivität mit android:screenOrientation angeben, diese aber nicht erforderlich ist, können Sie die Anforderung deaktivieren, indem Sie die Ausrichtung mit einem <uses-feature>-Element angeben und android:required="false" einschließen.

Aus Gründen der Abwärtskompatibilität unterstützen alle Geräte mit Android 3.1 (API-Level 12) oder niedriger sowohl die Quer- als auch die Hochformatausrichtung.

Hardwarefunktionen für die Telefonie

android.hardware.telephony
Die App nutzt die Telefonfunktionen des Geräts, z. B. das Telefonfunknetz mit Datenkommunikationsdiensten.
android.hardware.telephony.cdma

Die App verwendet das CDMA-Telefonfunksystem (Code Division Multiple Access).

Wenn eine App diese Funktion verwendet, bedeutet das, dass sie auch die android.hardware.telephony-Funktion verwendet, es sei denn, diese übergeordnete Funktion ist mit android:required="false" deklariert.

android.hardware.telephony.gsm

Die App verwendet das GSM-Funksystem (Global System for Mobile Communications).

Wenn eine App diese Funktion verwendet, bedeutet das, dass sie auch die android.hardware.telephony-Funktion verwendet, es sei denn, diese übergeordnete Funktion ist mit android:required="false" deklariert.

Touchscreen-Hardwarefunktionen

android.hardware.faketouch

Die App verwendet grundlegende Touch-Interaktionsereignisse wie Tippen und Ziehen.

Wenn diese Funktion als erforderlich deklariert ist, ist die App nur mit Geräten kompatibel, die einen emulierten „Fake Touch“-Touchscreen oder einen echten Touchscreen haben.

Ein Gerät mit einer gefälschten Touch-Oberfläche bietet ein Nutzereingabesystem, das einen Teil der Funktionen eines Touchscreens emuliert. So kann beispielsweise eine Maus oder eine Fernbedienung einen Cursor auf dem Bildschirm steuern.

Wenn Ihre App eine grundlegende Interaktion per Mausklick erfordert und nicht nur mit einem Steuerkreuz funktioniert, müssen Sie diese Funktion deklarieren. Da dies die Mindestanforderung für die Touchbedienung ist, können Sie auch eine App verwenden, die diese Funktion auf Geräten deklariert, die komplexere Touchbedienungen bieten.

Für Apps ist standardmäßig die Funktion android.hardware.faketouch erforderlich. Wenn Sie Ihre App auf Geräte mit Touchscreen beschränken möchten, müssen Sie dies explizit deklarieren. Gehen Sie dazu so vor:

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

Alle Apps, für die android.hardware.touchscreen nicht ausdrücklich erforderlich ist, wie im folgenden Beispiel gezeigt, funktionieren auch auf Geräten mit android.hardware.faketouch.

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

Die App erfasst zwei oder mehr unterschiedliche „Finger“ auf einer gefälschten Touchbedienung. Diese Funktion ist eine Supermenge der Funktion android.hardware.faketouch. Wenn diese Funktion als erforderlich deklariert ist, ist die App nur mit Geräten kompatibel, die das eindeutige Tracking von zwei oder mehr Fingern emulieren oder einen Touchscreen haben.

Im Gegensatz zu der von android.hardware.touchscreen.multitouch.distinct definierten Multitouch-Eingabe unterstützen Eingabegeräte, die eine solche Eingabeoberfläche haben, nicht alle Touch-Gesten mit zwei Fingern, da die Eingabe in eine Cursorbewegung auf dem Bildschirm umgewandelt wird. Das bedeutet, dass bei solchen Geräten Touch-Gesten mit nur einem Finger den Cursor bewegen, Wischbewegungen mit zwei Fingern Touch-Ereignisse mit nur einem Finger auslösen und andere Touch-Gesten mit zwei Fingern die entsprechenden Touch-Ereignisse mit zwei Fingern auslösen.

Diese Funktion kann von einem Gerät unterstützt werden, das ein Touchpad mit Zweifinger-Touchbedienung für die Cursorbewegung hat.

android.hardware.faketouch.multitouch.jazzhand

Die App erfasst fünf oder mehr verschiedene „Finger“ auf einer gefälschten Touchbedienungsoberfläche. Diese Funktion ist eine Supermenge der Funktion android.hardware.faketouch. Wenn diese Funktion als erforderlich deklariert ist, ist die App nur mit Geräten kompatibel, die das eindeutige Tracking von fünf oder mehr Fingern emulieren oder einen Touchscreen haben.

Im Gegensatz zu der von android.hardware.touchscreen.multitouch.jazzhand definierten Multitouch-Technologie unterstützen Eingabegeräte, die Jazzhand-Multitouch mit einer Fake-Touch-Oberfläche unterstützen, nicht alle Fünffinger-Gesten, da die Eingabe in eine Cursorbewegung auf dem Bildschirm umgewandelt wird. Das bedeutet, dass bei solchen Geräten mit Einzelfinger-Touch-Gesten ein Cursor bewegt wird, Mehrfinger-Touch-Gesten Einzelfinger-Touch-Ereignisse auslösen und andere Mehrfinger-Touch-Gesten die entsprechenden Mehrfinger-Touch-Ereignisse auslösen.

Diese Funktion kann von einem Gerät unterstützt werden, das ein Touchpad mit fünf Fingern für die Cursorbewegung hat.

android.hardware.touchscreen

Die App nutzt die Touchscreen-Funktionen des Geräts für Touch-Gesten, die interaktiver sind als grundlegende Touch-Ereignisse wie ein Wisch. Diese Funktion ist eine Supermenge der Funktion android.hardware.faketouch.

Standardmäßig ist diese Funktion für alle Apps erforderlich und sie sind daher auf Geräten, die nur eine emulierte „Fake Touch“-Oberfläche bieten, nicht verfügbar. Sie können Ihre App auf Geräten mit einer simulierten Touchbedienung oder sogar auf Geräten mit nur einem Steuerkreuz verfügbar machen, indem Sie mit android.hardware.touchscreen und android:required="false" explizit angeben, dass kein Touchscreen erforderlich ist. Fügen Sie diese Erklärung hinzu, wenn Ihre App eine Touchscreen-Oberfläche verwendet, diese aber nicht erfordert. Alle Apps, für die android.hardware.touchscreen nicht ausdrücklich erforderlich ist, funktionieren auch auf Geräten mit android.hardware.faketouch.

Wenn Ihre App tatsächlich eine Touchbedienung erfordert, z. B. um erweiterte Touch-Gesten wie Wischbewegungen auszuführen, müssen Sie keine Touchbedienungsfunktionen deklarieren, da diese standardmäßig erforderlich sind. Es ist jedoch am besten, wenn Sie alle Funktionen, die in Ihrer App verwendet werden, ausdrücklich angeben.

Wenn Sie eine komplexere Touch-Interaktion benötigen, z. B. Touch-Gesten mit mehreren Fingern, erklären Sie, dass Ihre App erweiterte Touchscreen-Funktionen verwendet.

android.hardware.touchscreen.multitouch

Die App nutzt die grundlegenden Funktionen des zweipunktigen Multitouch-Touchscreens des Geräts, z. B. für Pinch-Gesten. Die App muss Berührungen jedoch nicht unabhängig voneinander erfassen. Diese Funktion ist eine Erweiterung der Funktion android.hardware.touchscreen.

Wenn eine App diese Funktion verwendet, bedeutet das, dass sie auch die android.hardware.touchscreen-Funktion verwendet, es sei denn, diese übergeordnete Funktion ist mit android:required="false" deklariert.

android.hardware.touchscreen.multitouch.distinct

Die App nutzt die erweiterten Multitouch-Funktionen des Geräts, um zwei oder mehr Punkte unabhängig voneinander zu verfolgen. Diese Funktion ist eine Erweiterung der Funktion android.hardware.touchscreen.multitouch.

Wenn eine App diese Funktion verwendet, bedeutet das, dass sie auch die android.hardware.touchscreen.multitouch-Funktion verwendet, es sei denn, diese übergeordnete Funktion ist mit android:required="false" deklariert.

android.hardware.touchscreen.multitouch.jazzhand

Die App nutzt die erweiterten Multitouch-Funktionen des Geräts, um unabhängig fünf oder mehr Punkte zu erfassen. Diese Funktion ist eine Erweiterung der Funktion android.hardware.touchscreen.multitouch.

Wenn eine App diese Funktion verwendet, bedeutet das, dass sie auch die android.hardware.touchscreen.multitouch-Funktion verwendet, es sei denn, diese übergeordnete Funktion ist mit android:required="false" deklariert.

USB-Hardwarefunktionen

android.hardware.usb.accessory
Die App verhält sich wie ein USB-Gerät und stellt eine Verbindung zu USB-Hosts her.
android.hardware.usb.host
Die App verwendet das USB-Zubehör, das mit dem Gerät verbunden ist. Das Gerät dient als USB-Host.

Vulkan-Hardwarefunktionen

android.hardware.vulkan.compute
Die App verwendet Vulkan-Rechenfunktionen. Diese Funktion gibt an, dass die App die hardwarebeschleunigte Vulkan-Implementierung erfordert. Die Funktionsversion gibt an, welche zusätzlichen optionalen Rechenfunktionen die App über die Vulkan 1.0-Anforderungen hinaus benötigt. Wenn Ihre App beispielsweise die Unterstützung von Vulkan Compute Level 0 erfordert, deklarieren Sie die folgende Funktion:
<uses-feature
    android:name="android.hardware.vulkan.compute"
    android:version="0"
    android:required="true" />
Weitere Informationen zur Funktionsversion finden Sie unter FEATURE_VULKAN_HARDWARE_COMPUTE.
android.hardware.vulkan.level
Die App verwendet Funktionen auf Vulkan-Ebene. Diese Funktion gibt an, dass die App die hardwarebeschleunigte Vulkan-Implementierung erfordert. Die Funktionsversion gibt an, welche optionalen Hardwarefunktionen für die App erforderlich sind. Wenn Ihre App beispielsweise die Unterstützung der Vulkan-Hardwareebene 0 erfordert, deklarieren Sie die folgende Funktion:
<uses-feature
    android:name="android.hardware.vulkan.level"
    android:version="0"
    android:required="true" />
Weitere Informationen zur Featureversion finden Sie unter FEATURE_VULKAN_HARDWARE_LEVEL.
android.hardware.vulkan.version
Die App verwendet Vulkan. Diese Funktion gibt an, dass die App die hardwarebeschleunigte Vulkan-Implementierung erfordert. Die Funktionsversion gibt die Mindestversion der Vulkan API-Unterstützung an, die für die App erforderlich ist. Wenn Ihre App beispielsweise Vulkan 1.0 erfordert, deklarieren Sie die folgende Funktion:
<uses-feature
    android:name="android.hardware.vulkan.version"
    android:version="0x400003"
    android:required="true" />
Weitere Informationen zur Funktionsversion finden Sie unter FEATURE_VULKAN_HARDWARE_VERSION.

Wi‑Fi-Hardwarefunktionen

android.hardware.wifi
Die App nutzt 802.11-Netzwerkfunktionen (WLAN) auf dem Gerät.
android.hardware.wifi.direct
Die App verwendet die Wi‑Fi Direct-Netzwerkfunktionen des Geräts.

Softwarefunktionen

In diesem Abschnitt werden die Softwarefunktionen aufgeführt, die von der aktuellen Plattformversion unterstützt werden. Wenn Sie angeben möchten, dass Ihre App eine Softwarefunktion verwendet oder benötigt, geben Sie den entsprechenden Wert, der mit "android.software" beginnt, in einem android:name-Attribut an. Verwenden Sie jedes Mal ein separates <uses-feature>-Element, wenn Sie eine Softwarefunktion deklarieren.

Funktionen von Kommunikationssoftware

android.software.sip
Die App verwendet SIP-Dienste (Session Initiation Protocol). Durch die Verwendung von SIP kann die App Internettelefoniefunktionen wie Videokonferenzen und Instant Messaging unterstützen.
android.software.sip.voip

Die App verwendet SIP-basierte Voice over Internet Protocol (VoIP)-Dienste. Durch die Verwendung von VoIP kann die App Echtzeit-Internettelefoniefunktionen wie Zwei-Wege-Videokonferenzen unterstützen.

Wenn eine App diese Funktion verwendet, bedeutet das, dass sie auch die android.software.sip-Funktion verwendet, es sei denn, diese übergeordnete Funktion ist mit android:required="false" deklariert.

android.software.webview
Die App zeigt Inhalte aus dem Internet an.

Funktionen der benutzerdefinierten Eingabesoftware

android.software.input_methods
Die App verwendet eine neue Eingabemethode, die der Entwickler in einer InputMethodService definiert.

Funktionen der Geräteverwaltungssoftware

android.software.backup
Die App enthält eine Logik zur Verarbeitung von Sicherungs- und Wiederherstellungsvorgängen.
android.software.device_admin
Die App verwendet Geräteadministratoren, um eine Geräterichtlinie durchzusetzen.
android.software.managed_users
Die App unterstützt sekundäre Nutzer und verwaltete Profile.
android.software.securely_removes_users
Die App kann Nutzer und die zugehörigen Daten endgültig entfernen.
android.software.verified_boot
Die App enthält eine Logik zum Umgang mit Ergebnissen der Funktion „Verifizierter Boot“ des Geräts, die erkennt, ob sich die Konfiguration des Geräts während eines Neustarts ändert.

Funktionen der Mediensoftware

android.software.midi
Die App stellt eine Verbindung zu Musikinstrumenten her oder gibt über das MIDI-Protokoll (Musical Instrument Digital Interface) Ton aus.
android.software.print
Die App enthält Befehle zum Drucken von Dokumenten, die auf dem Gerät angezeigt werden.
android.software.leanback
Die App ist für Android TV-Geräte konzipiert.
android.software.live_tv
Die App streamt Live-TV-Programme.

Softwarefunktionen der Bildschirmoberfläche

android.software.app_widgets
Die App verwendet oder stellt App-Widgets bereit und ist nur für Geräte gedacht, die einen Startbildschirm oder eine ähnliche Stelle haben, an der Nutzer App-Widgets einbetten können.
android.software.home_screen
Die App ersetzt den Startbildschirm des Geräts.
android.software.live_wallpaper
Die App verwendet oder bietet Hintergründe mit Animationen.

Berechtigungen, die Funktionsanforderungen implizieren

Einige Hardware- und Softwarefunktionen werden Anwendungen erst nach der entsprechenden API zur Verfügung gestellt. Daher kann es sein, dass einige Apps die API verwenden, bevor sie über das <uses-feature>-System angeben können, dass sie die API erforderlich haben.

Um zu verhindern, dass diese Apps versehentlich verfügbar gemacht werden, geht Google Play davon aus, dass bestimmte hardwarebezogene Berechtigungen darauf hinweisen, dass die zugrunde liegenden Hardwarefunktionen standardmäßig erforderlich sind. Anwendungen, die Bluetooth verwenden, müssen beispielsweise die Berechtigung BLUETOOTH in einem <uses-permission>-Element anfordern.

Bei älteren Apps geht Google Play davon aus, dass die Berechtigungserklärung bedeutet, dass die zugrunde liegende android.hardware.bluetooth-Funktion für die Anwendung erforderlich ist, und richtet einen Filter basierend auf dieser Funktion ein. In Tabelle 2 sind Berechtigungen aufgeführt, die Funktionsanforderungen implizieren, die denen in <uses-feature>-Elementen entsprechen.

<uses-feature>-Deklarationen, einschließlich aller deklarierten android:required-Attribute, haben immer Vorrang vor Funktionen, die durch die Berechtigungen in Tabelle 2 impliziert werden. Bei jeder dieser Berechtigungen können Sie das Filtern basierend auf der impliziten Funktion deaktivieren, indem Sie die Funktion in einem <uses-feature>-Element explizit deklarieren und das required-Attribut auf false festlegen.

Wenn Sie beispielsweise die Filterung basierend auf der Berechtigung CAMERA deaktivieren möchten, fügen Sie der Manifestdatei die folgenden <uses-feature>-Deklarationen hinzu:

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

Achtung:Wenn Ihre App auf Android 5.0 (API-Level 21) oder höher ausgerichtet ist und die Berechtigung ACCESS_COARSE_LOCATION oder ACCESS_FINE_LOCATION verwendet, um Standortaktualisierungen vom Netzwerk bzw. von einem GPS zu erhalten, müssen Sie auch ausdrücklich angeben, dass Ihre App die Hardwarefunktionen android.hardware.location.network oder android.hardware.location.gps verwendet.

Tabelle 2. Geräteberechtigungen, die die Nutzung der Gerätehardware implizieren.

Kategorie Berechtigung Stillschweigende Funktionsanforderung
Bluetooth BLUETOOTH android.hardware.bluetooth

Weitere Informationen finden Sie unter Spezielle Handhabung für die Bluetooth-Funktion.

BLUETOOTH_ADMIN android.hardware.bluetooth
Kamera CAMERA android.hardware.camera
android.hardware.camera.autofocus
Standort 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 (Nur wenn das Ziel-API-Level 20 oder niedriger ist.)

ACCESS_FINE_LOCATION

android.hardware.location

android.hardware.location.gps (Nur wenn das Ziel-API-Level 20 oder niedriger ist.)

Mikrofon RECORD_AUDIO android.hardware.microphone
Telefonie 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
WLAN ACCESS_WIFI_STATE android.hardware.wifi
CHANGE_WIFI_STATE android.hardware.wifi
CHANGE_WIFI_MULTICAST_STATE android.hardware.wifi