Diese Seite wurde von der Cloud Translation API übersetzt.

<uses-feature>

Google Play verwendet die in deinem App-Manifest deklarierten <uses-feature>-Elemente, um deine App nach Geräten zu filtern, die die Anforderungen an Hardware- und Softwarefunktionen nicht erfüllen.

Wenn du die Funktionen festlegst, die für deine App erforderlich sind, kann Google Play deine App nur Nutzern präsentieren, deren Geräte die Funktionsanforderungen der App erfüllen.

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

Syntax:

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

enthalten in:

<manifest>

description:

Deklariert ein einzelnes Hardware- oder Softwarefeature, das von der Anwendung verwendet wird.

Der Zweck einer <uses-feature>-Deklaration besteht darin, externe Entitäten über die Hardware- und Softwarefunktionen zu informieren, von denen Ihre Anwendung abhängt. Das Element bietet ein required-Attribut, mit dem Sie angeben können, ob Ihre Anwendung das deklarierte Feature erfordert und nicht verwenden kann oder ob es die Funktion bevorzugt verwenden möchte, aber ohne sie funktionieren kann.

Da die Funktionsunterstützung je nach Android-Gerät variieren kann, spielt das <uses-feature>-Element eine wichtige Rolle dabei, dass eine App die verwendeten gerätevariablen Funktionen beschreiben kann.

Die verfügbaren Funktionen, die deine App deklariert, entsprechen den Funktionskonstanten, die von der Android-PackageManager zur Verfügung gestellt werden. Featurekonstanten sind in diesem Dokument im Abschnitt Feature-Referenz aufgeführt.

Du musst jedes Element in einem separaten <uses-feature>-Element angeben. Wenn deine Anwendung also mehrere Elemente erfordert, werden mehrere <uses-feature>-Elemente deklariert. Für eine Anwendung, für die sowohl Bluetooth- als auch Kamerafunktionen auf dem Gerät erforderlich sind, werden beispielsweise die folgenden beiden Elemente deklariert:

<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 bedeutet, dass das Android-System selbst vor der Installation einer App nicht prüft, ob übereinstimmende Funktionen auf dem Gerät unterstützt werden.

Andere Dienste wie Google Play und Apps können jedoch die <uses-feature>-Deklarationen Ihrer App im Rahmen der Verarbeitung oder Interaktion mit Ihrer App prüfen. Aus diesem Grund ist es sehr wichtig, dass Sie alle Funktionen deklarieren, die Ihre Anwendung verwendet.

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 auf einem Gerät vorhanden sind, z. B. eine Kamera, werden mit dem Attribut name deklariert.

Obwohl das <uses-feature>-Element nur für Geräte aktiviert ist, auf denen API-Level 4 oder höher ausgeführt wird, schließen Sie es für alle Anwendungen ein, auch wenn minSdkVersion gleich 3 oder niedriger ist. Geräte, auf denen ältere Versionen der Plattform ausgeführt werden, ignorieren das Element.

Hinweis:Denken Sie beim Deklarieren einer Funktion daran, dass Sie gegebenenfalls auch Berechtigungen anfordern müssen. Sie müssen beispielsweise die Berechtigung CAMERA anfordern, bevor Ihre Anwendung auf die Camera API zugreifen kann. Wenn Sie die Berechtigung anfordern, wird Ihrer Anwendung Zugriff auf die entsprechende Hardware und Software gewährt. Durch das Deklarieren der von deiner App verwendeten Funktionen wird die ordnungsgemäße Gerätekompatibilität sichergestellt.

Attribute:

android:name

Gibt ein einzelnes Hardware- oder Softwarefeature an, das von der Anwendung als Deskriptorstring verwendet wird. Gültige Attributwerte sind in den Abschnitten Hardwarefunktionen und Softwarefunktionen aufgeführt. Bei diesen Attributwerten wird zwischen Groß- und Kleinschreibung unterschieden.

android:required

Boolescher Wert, der angibt, ob die Anwendung das in android:name angegebene Feature benötigt.

Wenn du android:required="true" für ein Feature angibst, bedeutet das, dass die App nicht funktioniert oder nicht dafür konzipiert ist, wenn die angegebene Funktion auf dem Gerät nicht vorhanden ist.
Wird android:required="false" für eine Funktion deklariert, bedeutet dies, dass die App die Funktion verwendet, falls sie auf dem Gerät vorhanden ist. Bei Bedarf soll sie aber auch ohne die angegebene Funktion funktionieren.

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

android:glEsVersion

Die von der App benötigte OpenGL ES-Version. Die höheren 16 Bit stellen die Major-Zahl und die niedrigeren 16 Bit die Nebenzahl dar. Wenn Sie beispielsweise OpenGL ES Version 2.0 festlegen möchten, legen Sie den Wert auf „0x00020000“ fest. Wenn Sie OpenGL ES 3.2 angeben, legen Sie den Wert auf „0x00030002“ fest.

In einer App ist in ihrem Manifest maximal ein android:glEsVersion-Attribut angegeben. Wenn mehr als ein Wert angegeben ist, wird der android:glEsVersion mit dem numerisch höchsten Wert verwendet und alle anderen Werte werden ignoriert.

Wenn für eine App kein android:glEsVersion-Attribut angegeben ist, wird davon ausgegangen, dass sie nur OpenGL ES 1.0 benötigt, 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. Legen Sie daher für eine Anwendung, die sowohl OpenGL ES 1.0 als auch OpenGL ES 2.0 erfordert, fest, dass OpenGL ES 2.0 verwendet wird.

Geben Sie für eine Anwendung, die mit jeder von mehreren OpenGL ES-Versionen funktioniert, nur die numerisch niedrigste Version von OpenGL ES an, die sie benötigt. Es kann während der Laufzeit prüfen, ob ein höheres Level von OpenGL ES verfügbar ist.

Weitere Informationen zur Verwendung von OpenGL ES und zum Prüfen der unterstützten OpenGL ES-Version zur Laufzeit finden Sie im Leitfaden zur OpenGL ES API.

eingeführt in:

API-Level 4

Siehe auch:

Google Play und funktionsbasierte Filter

Google Play filtert die für Nutzer sichtbaren Apps, sodass sie nur solche Apps sehen und herunterladen können, die mit ihrem Gerät kompatibel sind. Anwendungen werden unter anderem nach Featurekompatibilität gefiltert.

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

Für die App erforderliche Funktionen, wie in <uses-feature>-Elementen im Manifest der Anwendung deklariert.
Funktionen, die auf dem Gerät in Hardware oder Software verfügbar sind und über schreibgeschützte Systemeigenschaften gemeldet werden.

Um die Funktionen genau zu vergleichen, bietet der Android Package Manager eine gemeinsame Reihe von Funktionskonstanten, mit denen sowohl Anwendungen als auch Geräte Funktionsanforderungen und Support angeben. Die verfügbaren Featurekonstanten sind in diesem Dokument im Abschnitt Features-Referenz und in der Klassendokumentation für PackageManager aufgeführt.

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

Jedes Mal, wenn Sie eine App in die Google Play Console hochladen, prüft Google Play die Manifestdatei der App. Dabei wird nach <uses-feature>-Elementen gesucht und diese in Kombination mit anderen Elementen ausgewertet, beispielsweise mit <uses-sdk>- und <uses-permission>-Elementen. Nachdem die erforderlichen Funktionen für die App festgelegt wurden, speichert sie diese Liste intern als Metadaten, die mit dem App-APK und der App-Version verknüpft sind.

Wenn ein Nutzer mit der Google Play-App nach Apps sucht, vergleicht der Dienst die von der jeweiligen App benötigten Funktionen mit den auf dem Gerät des Nutzers verfügbaren Funktionen. Wenn alle für eine App erforderlichen Funktionen auf dem Gerät vorhanden sind, kann der Nutzer die App bei Google Play sehen und möglicherweise herunterladen.

Wenn eine erforderliche Funktion vom Gerät nicht unterstützt wird, filtert Google Play die App so, dass sie für den Nutzer nicht sichtbar ist und nicht heruntergeladen werden kann.

Die in <uses-feature>-Elementen deklarierten Funktionen wirken sich direkt darauf aus, wie Google Play deine App filtert. Daher ist es wichtig zu verstehen, wie Google Play das Manifest der App auswertet und die erforderlichen Funktionen festlegt. In den folgenden Abschnitten finden Sie weitere Informationen.

Basierend auf explizit deklarierten Features filtern

Ein explizit deklariertes Feature wird von Ihrer Anwendung in einem <uses-feature>-Element deklariert. Die Funktionsdeklaration kann ein android:required=["true" | "false"]-Attribut enthalten, wenn du für API-Level 5 oder höher kompilierst.

So können Sie angeben, ob die Anwendung das Feature benötigt und ohne es nicht ordnungsgemäß funktionieren kann ("true") oder das Feature verwenden soll, falls es verfügbar ist, aber so konzipiert ist, dass es ohne es ausgeführt wird ("false").

Google Play behandelt explizit deklarierte Funktionen folgendermaßen:

Wenn eine Funktion explizit als erforderlich deklariert wird, wie im folgenden Beispiel gezeigt, fügt Google Play die Funktion der Liste der erforderlichen Funktionen für die App hinzu. Anschließend wird die Anwendung nach Nutzern auf Geräten gefiltert, die diese Funktion nicht bieten.
```
<uses-feature android:name="android.hardware.camera.any" android:required="true" />
```
Wenn eine Funktion explizit als nicht erforderlich erklärt wird, wie im folgenden Beispiel gezeigt, wird die Funktion von Google Play nicht in die Liste der erforderlichen Funktionen aufgenommen. Aus diesem Grund wird ein explizit deklariertes nicht erforderliches Feature beim Filtern der Anwendung nie berücksichtigt. Selbst wenn das Gerät die deklarierte Funktion nicht bietet, betrachtet Google Play die App 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 ist, aber ohne das Attribut android:required, geht Google Play davon aus, dass die Funktion erforderlich ist, und richtet die Filterung dafür ein.

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

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

Basierend auf impliziten Features filtern

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

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

Für eine Anwendung kann aus den folgenden Gründen eine Funktion erforderlich sein, aber nicht deklariert werden:

Die App wurde mit einer älteren Version der Android-Bibliothek (Android 1.5 oder niedriger) kompiliert, für die das <uses-feature>-Element nicht verfügbar ist.
Der Entwickler geht fälschlicherweise davon aus, dass die Funktion auf allen Geräten vorhanden ist und keine Deklaration erforderlich ist.
Der Entwickler lässt die Funktionsdeklaration versehentlich weg.
Der Entwickler deklariert die Funktion explizit, aber die Deklaration ist ungültig. Beispielsweise wird die Featuredeklaration durch einen Rechtschreibfehler im Elementnamen <uses-feature> oder ein nicht erkannter Stringwert für das Attribut android:name ungültig.

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

Wenn eine App hardwarebezogene Berechtigungen anfordert, geht Google Play davon aus, dass die App die zugrunde liegenden Hardwarefunktionen verwendet. Daher sind diese Funktionen erforderlich, auch wenn keine entsprechenden <uses-feature>-Deklarationen vorhanden sind. Für solche Berechtigungen fügt Google Play den Metadaten, die für die App gespeichert sind, die zugrunde liegenden Hardwarefunktionen hinzu und richtet Filter für sie ein.

Wenn eine App beispielsweise die Berechtigung CAMERA anfordert, geht Google Play davon aus, dass die App eine Rückkamera erfordert, auch wenn die App kein <uses-feature>-Element für android.hardware.camera deklariert. Geräte ohne Rückkamera werden von Google Play herausgefiltert.

Wenn Sie nicht möchten, dass Google Play nach einem bestimmten implizierten Feature filtert, deklarieren Sie das Element explizit in einem <uses-feature>-Element und fügen Sie das Attribut android:required="false" ein. Wenn Sie beispielsweise die durch die Berechtigung CAMERA implizierte Filterung deaktivieren möchten, 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. Der Abschnitt Berechtigungen mit Anforderungen an Funktionen enthält alle Berechtigungen, die Funktionsanforderungen implizieren und daher die Filterung auslösen.

Besondere Handhabung der Bluetooth-Funktion

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

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

Wie in der folgenden Tabelle dargestellt, kann bei Google Play nur dann nach der Bluetooth-Funktion gefiltert werden, wenn die App als niedrigste oder Zielplattform Android 2.0 (API-Level 5) oder höher angibt. Beachten Sie jedoch, dass Google Play die normalen Filterregeln anwendet, wenn die App die Bluetooth-Funktion explizit in einem <uses-feature>-Element deklariert.

Tabelle 1 Wie Google Play ermittelt, welche Bluetooth-Funktion für eine App erforderlich ist, die eine Bluetooth-Berechtigung anfordert, aber die Bluetooth-Funktion nicht in einem <uses-feature>-Element deklariert.

Wenn `minSdkVersion` gleich ...	und `targetSdkVersion` ist	Ergebnis
<=4 oder `<uses-sdk>` ist nicht deklariert	<=4	Google Play filtert die App nicht aufgrund der gemeldeten Unterstützung der Funktion `android.hardware.bluetooth`.
<=4	≥ 5	Google Play filtert die App von allen Geräten heraus, die die Funktion `android.hardware.bluetooth` nicht unterstützen (auch ältere Releases).
≥ 5	≥ 5

Die folgenden Beispiele zeigen die verschiedenen Filtereffekte basierend darauf, wie Google Play mit der Bluetooth-Funktion umgeht.

Im ersten Beispiel deklariert eine Anwendung, die für ältere API-Ebenen ausgeführt werden soll, eine Bluetooth-Berechtigung, aber nicht die Bluetooth-Funktion in einem <uses-feature>-Element.

Ergebnis:Google Play filtert die App auf keinem Gerät.

<manifest ...>
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" />
    ...
</manifest>

Im zweiten Beispiel deklariert dieselbe Anwendung auch ein Ziel-API-Level von „5“.

Ergebnis:Google Play geht jetzt davon aus, dass die Funktion erforderlich ist, und filtert die App von allen Geräten, die keine Bluetooth-Unterstützung bieten, einschließlich Geräten, auf denen ältere Versionen der Plattform ausgeführt werden.

<manifest ...>
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>

Hier wird in dieser Anwendung jetzt speziell die Bluetooth-Funktion deklariert.

Ergebnis:Identisch mit dem vorherigen Beispiel: Filter wird 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>

Schließlich fügt dieselbe Anwendung im folgenden Fall ein android:required="false"-Attribut hinzu.

Ergebnis:Google Play deaktiviert die Filterung auf Grundlage 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 Ihre Anwendung erforderliche Funktionen testen

Mit dem aapt2-Tool, das im Android SDK enthalten ist, können Sie bestimmen, wie Google Play Ihre App anhand der deklarierten Funktionen und Berechtigungen filtert. Führen Sie dazu aapt2 mit dem Befehl dump badging aus. Dadurch parst aapt2 das Manifest deiner App und wendet dieselben Regeln an, anhand derer Google Play die für deine App erforderlichen Funktionen ermittelt.

So verwenden Sie das Tool:

Erstellen und exportieren Sie Ihre App als unsigniertes APK. Wenn Sie Apps in Android Studio entwickeln, erstellen Sie sie so mit Gradle:
1. Öffnen Sie das Projekt und wählen Sie Run > Edit Configurations (Ausführen > Konfigurationen bearbeiten) aus.
2. Wählen Sie das Pluszeichen links oben im Fenster Run/Debug Configurations aus.
3. Wählen Sie Gradle aus.
4. Geben Sie im Feld Name „Nicht signiertes APK“ ein.
5. Wählen Sie Ihr Modul im Abschnitt Gradle-Projekt aus.
6. Geben Sie im Feld Tasks „asse“ ein.
7. Wählen Sie OK aus, um die neue Konfiguration abzuschließen.
8. Achten Sie darauf, dass in der Symbolleiste die Ausführungskonfiguration Unsigniertes APK ausgewählt ist, und wählen Sie dann Ausführen > „Unsignierte APK-Datei ausführen“ aus.
Du findest dein nicht signiertes APK im Verzeichnis <ProjectName>/app/build/outputs/apk/.
Suchen Sie das aapt2-Tool, wenn es sich noch nicht in Ihrem PATH befindet. Wenn Sie SDK-Tools Version 8 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 du nicht die neueste Build-Tools-Komponente hast, kannst du sie mit dem Android SDK Manager herunterladen.
Führen Sie aapt2 mit dieser Syntax aus:

$ aapt2 dump badging <path_to_exported_.apk>

Hier ist ein Beispiel für die Befehlsausgabe für das zweite zuvor gezeigte Bluetooth-Beispiel:

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

Funktionsreferenz

Die folgenden Abschnitte enthalten Referenzinformationen zu Hardwarefunktionen, Softwarefunktionen und Berechtigungssätzen, die bestimmte Funktionsanforderungen implizieren.

Hardware-Funktionen

In diesem Abschnitt werden die Hardwarefunktionen beschrieben, die vom aktuellen Plattformrelease unterstützt werden. Deklariere den entsprechenden Wert, der mit "android.hardware" beginnt, in einem android:name-Attribut, um anzugeben, dass deine Anwendung eine Hardwarefunktion verwendet oder erfordert. Verwende jedes Mal, wenn du eine Hardwarefunktion deklarieren, ein separates <uses-feature>-Element.

Funktionen der Audiohardware

android.hardware.audio.low_latency: Die App nutzt die Audiopipeline mit niedriger Latenz, die Verzögerungen bei der Verarbeitung von Toneingaben oder -ausgaben reduziert.
android.hardware.audio.output: Die App überträgt Ton über die Lautsprecher, den Audioanschluss, die Bluetooth-Streaming-Funktion oder einen ähnlichen Mechanismus.
android.hardware.audio.pro: Die App nutzt die High-End-Audiofunktionen und die Leistungsfähigkeiten des Geräts.
android.hardware.microphone: Die App nimmt Audio über das Mikrofon des Geräts auf.

Funktionen der Bluetooth-Hardware

android.hardware.bluetooth: Die App nutzt die Bluetooth-Funktionen des Geräts, in der Regel für die Kommunikation mit anderen Bluetooth-fähigen Geräten.
android.hardware.bluetooth_le: Die App verwendet die Bluetooth Low Energy-Funkfunktionen des Geräts.

Funktionen der Kamerahardware

Hinweis:Damit Ihre App nicht unnötig nach Google Play gefiltert wird, fügen Sie android:required="false" allen Kamerafunktionen hinzu, ohne die Ihre App funktioniert. Andernfalls geht Google Play davon aus, dass die Funktion erforderlich ist, und hindert Geräte, die die Funktion nicht unterstützen, am Zugriff auf Ihre App.

Unterstützung für große Bildschirme

Einige Geräte mit großem Display unterstützen nicht alle Kamerafunktionen. Chromebooks haben normalerweise keine Rückkameras, Autofokus oder Blitz auf der Rückseite. Chromebooks haben jedoch Frontkameras (für den Nutzer sichtbare) und werden oft mit externen Kameras verbunden.

Wenn du grundlegenden Kamerasupport bieten und deine App für so viele Geräte wie möglich verfügbar machen möchtest, füge deinem 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" />

Passe die Funktionseinstellungen an die Anwendungsfälle deiner App an. Wenn du deine App jedoch für möglichst viele Geräte verfügbar machen möchtest, verwende immer das Attribut required. Damit lässt sich explizit angeben, ob eine Funktion ein Muss ist.

Funktionsliste

android.hardware.camera.any

Die App verwendet eine der Kameras des Geräts oder eine mit dem Gerät verbundene externe Kamera. Verwende diese Funktion anstelle von android.hardware.camera oder android.hardware.camera.front, wenn deine App nicht erfordert, dass die Kamera nach hinten (zur Welt) bzw. nach vorn (für den Nutzer) gerichtet ist.

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

android.hardware.camera

Die App verwendet die Kamera auf der Rückseite des Geräts.

Achtung:Geräte wie Chromebooks, die nur eine Frontkamera (für den Nutzer gerichtet) haben, unterstützen diese Funktion nicht. Verwende android.hardware.camera.any, wenn deine App jede Kamera unabhängig von der Kamerarichtung verwenden kann.

Hinweis:Die Berechtigung CAMERA impliziert, dass eine Rückkamera eine erforderliche Funktion ist. Damit bei Google Play richtig gefiltert werden kann, wenn dein App-Manifest die Berechtigung CAMERA enthält, musst du explizit angeben, dass deine App die Funktion camera verwendet, und ob dies 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 für den Nutzer sichtbar ist.

Achtung:Wenn deine App android.hardware.camera.front verwendet, aber android.hardware.camera nicht explizit mit android.required="false" deklariert ist, werden Geräte ohne Rückkamera (z. B. Chromebooks) von Google Play herausgefiltert. Wenn deine App Geräte nur mit Frontkameras unterstützt, deklariere 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 garantiert nicht, dass eine externe Kamera für Ihre App verfügbar ist.

android.hardware.camera.autofocus

Die App verwendet die Autofokus-Funktion der Gerätekamera.

Hinweis:Die Berechtigung CAMERA impliziert, dass der Autofokus eine erforderliche Funktion ist. Damit bei Google Play richtig gefiltert werden kann, wenn dein App-Manifest die Berechtigung CAMERA enthält, gib explizit an, dass deine App die Autofokus-Funktion verwendet. Gib außerdem an, ob dies erforderlich ist. Beispiel:
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />.

android.hardware.camera.flash

Die App verwendet die Blitzfunktion der Gerätekamera.

android.hardware.camera.capability.manual_post_processing

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

Mit dieser Funktion kann die App den automatischen Weißabgleich der Kamera überschreiben. Verwenden Sie android.colorCorrection.transform, android.colorCorrection.gains und TRANSFORM_MATRIX als android.colorCorrection.mode.

android.hardware.camera.capability.manual_sensor

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

Mit dieser Funktion wird die automatische Belichtungssperre (android.control.aeLock) unterstützt, die es ermöglicht, Belichtungszeit und Empfindlichkeit der Kamera auf bestimmten Werten zu fixieren.

android.hardware.camera.capability.raw

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

Diese Funktion impliziert, dass das Gerät DNG-Dateien (Rohdateien) speichern kann. Die Kamera des Geräts stellt die DNG-bezogenen Metadaten bereit, die Ihre App benötigt, um die Rohbilder direkt zu verarbeiten.

android.hardware.camera.level.full

Die App nutzt die FULL-Unterstützung für Bilderfassungen, die von mindestens einer Kamera des Geräts bereitgestellt wird. Die FULL-Unterstützung umfasst Burst-Capture-Funktionen, die Steuerung pro Frame und die manuelle Nachbearbeitung. Siehe INFO_SUPPORTED_HARDWARE_LEVEL_FULL.

Hardwarefunktionen der Geräte-UI

android.hardware.type.automotive

Die App ist so konzipiert, dass ihre Benutzeroberfläche auf einer Reihe von Bildschirmen in einem Fahrzeug angezeigt wird. Die Interaktion des Nutzers mit der App erfolgt über harte Tasten, Touchscreen, Drehregler und mausähnliche Oberflächen. Die Bildschirme des Fahrzeugs werden normalerweise in der Mittelkonsole oder dem Kombi-Instrument eines Fahrzeugs angezeigt. Diese Bildschirme haben in der Regel nur eine begrenzte Größe und Auflösung.

Hinweis : Da der Nutzer beim Fahren diese Art von App-UI verwendet, muss die App so wenig wie möglich vom Fahrer abgelenkt werden.

android.hardware.type.television

(Eingestellt. Verwenden Sie stattdessen android.software.leanback.)

Die App ist so konzipiert, dass die Benutzeroberfläche auf einem Fernseher angezeigt wird. Diese Funktion definiert „Fernsehen“ als typisches Fernseherlebnis im Wohnzimmer: Die App wird auf einem großen Bildschirm angezeigt, der Nutzer sitzt weit weg und die dominante Eingabe ist zum Beispiel ein Steuerkreuz und keine Maus, Zeiger oder Touchgerät.

android.hardware.type.watch

Die App wurde so entwickelt, dass sie die Benutzeroberfläche auf einer Smartwatch anzeigt. Eine Uhr wird am Körper getragen, beispielsweise am Handgelenk. Der Nutzer befindet sich während der Interaktion sehr nah am Gerät.

android.hardware.type.pc

Die App ist so konzipiert, dass die Benutzeroberfläche auf Chromebooks angezeigt wird. Mit dieser Funktion wird die Eingabeemulation für Maus und Touchpad deaktiviert, da Chromebooks Maus und Touchpad verwenden. Siehe Mauseingabe.

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

Fingerabdruckfunktionen

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

Gamepad-Hardwarefunktionen

android.hardware.gamepad: Die App erfasst Gamecontroller-Eingaben entweder vom Gerät selbst oder über ein verbundenes Gamepad.

Infrarot-Hardwarefunktionen

android.hardware.consumerir: Die App nutzt die Infrarotfunktionen des Geräts, um mit anderen IR-Geräten zu kommunizieren.

Funktionen der Standorthardware

android.hardware.location

Die App nutzt eine oder mehrere Gerätefunktionen zur Standortbestimmung, z. B. den GPS-, Netzwerk- oder Mobilfunkstandort.

android.hardware.location.gps

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

Durch die Verwendung dieser Funktion impliziert eine App, dass sie auch die Funktion android.hardware.location verwendet, sofern diese übergeordnete Funktion nicht mit dem Attribut android:required="false" deklariert wird.

android.hardware.location.network

Die App verwendet ungefähre Standortkoordinaten, die von einem netzwerkbasierten Standortbestimmungssystem auf dem Gerät unterstützt werden.

NFC-Hardwarefunktionen

android.hardware.nfc: Die App verwendet die NFC-Funktionen (Nahfeldkommunikation) des Geräts.
android.hardware.nfc.hce: Die App verwendet die auf dem Gerät gehostete NFC-Kartenemulation.

OpenGL ES-Hardwarefunktionen

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

Funktionen der Sensorhardware

android.hardware.sensor.accelerometer: Die App verwendet Bewegungsmessungen des Beschleunigungsmessers des Geräts, um die aktuelle Ausrichtung des Geräts zu erkennen. Eine App kann beispielsweise die Messwerte des Beschleunigungsmessers verwenden, um zu ermitteln, wann zwischen Hoch- und Querformat gewechselt werden soll.
android.hardware.sensor.ambient_temperature: Die App verwendet den Umgebungstemperatursensor des Geräts. Eine Wetter-App kann 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. Beispielsweise kann eine Navigations-App die aktuelle Richtung eines Nutzers anzeigen.
android.hardware.sensor.gyroscope: Die App nutzt das Gyroskop des Geräts, um Rotationen und Verdrehungen zu erkennen, und ergibt ein Ausrichtungssystem mit sechs Achsen. Mit diesem Sensor kann eine App reibungsloser erkennen, wann sie zwischen Hoch- und Querformat wechseln muss.
android.hardware.sensor.hifi_sensors: Die App verwendet die High-Fidelity-Sensoren (Hi-Fi-Sensoren) des Geräts. Beispielsweise könnte eine Spiele-App die Bewegungen des Nutzers mit hoher Präzision erkennen.
android.hardware.sensor.heartrate: Die App verwendet den Herzfrequenzmesser 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 (Elektrokardiogramm) 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. Beispielsweise kann eine App je nach Umgebungslichtverhältnisse eines von zwei Farbschemata anzeigen.
android.hardware.sensor.proximity: Die App verwendet den Näherungssensor des Geräts. Eine Telefonie-App kann beispielsweise den Bildschirm des Geräts ausschalten, wenn die App erkennt, dass der Nutzer das Gerät nah an seinen Körper hält.
android.hardware.sensor.relative_humidity: Die App verwendet den Sensor für die relative Luftfeuchtigkeit des Geräts. Eine Wetter-App könnte beispielsweise die Luftfeuchtigkeit verwenden, um den aktuellen Taupunkt zu berechnen und zu melden.
android.hardware.sensor.stepcounter: Die App verwendet den Schrittzähler des Geräts. Eine Fitness-App kann beispielsweise die Anzahl der Schritte melden, die ein Nutzer ausführen muss, um sein tägliches Schrittzahlziel zu erreichen.
android.hardware.sensor.stepdetector: Die App verwendet den Schrittdetektor des Geräts. Eine Fitness-App könnte beispielsweise das Zeitintervall zwischen den Schritten verwenden, um die Art der Übung abzuleiten, die der Nutzer ausführt.

Funktionen der Bildschirmhardware

android.hardware.screen.landscape

android.hardware.screen.portrait

Für die App muss auf dem Gerät Hoch- oder Querformat verwendet werden. Wenn deine App beide Ausrichtungen unterstützt, musst du keines der Funktionen deklarieren.

Wenn für Ihre App beispielsweise das Hochformat erforderlich ist, deklarieren Sie die folgende Funktion, damit die Anwendung nur auf Geräten ausgeführt werden kann, die das Hochformat unterstützen – immer oder nach Nutzerauswahl:

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

Es wird angenommen, dass beide Ausrichtungen nicht standardmäßig erforderlich sind, damit deine App auf Geräten installiert werden kann, die eine oder beide Ausrichtungen unterstützen. Wenn Sie jedoch für eine Ihrer Aktivitäten über das Attribut android:screenOrientation verlangen, dass sie in einer bestimmten Ausrichtung ausgeführt werden, impliziert diese Deklaration, dass Ihre App diese Ausrichtung erfordert.

Wenn du beispielsweise android:screenOrientation mit "landscape", "reverseLandscape" oder "sensorLandscape" deklarierst, ist deine App nur auf Geräten verfügbar, die das Querformat unterstützen.

Als Best Practice sollten Sie Ihre Anforderung für diese Ausrichtung mithilfe eines <uses-feature>-Elements angeben. Wenn du mit android:screenOrientation eine Ausrichtung für deine Aktivität angibst, sie aber nicht benötigst, kannst du diese Anforderung deaktivieren. Deklariere dazu die Ausrichtung mit einem <uses-feature>-Element und füge android:required="false" hinzu.

Aus Gründen der Abwärtskompatibilität unterstützt jedes Gerät mit Android 3.1 (API-Level 12) oder niedriger sowohl das Quer- als auch das Hochformat.

Hardwarefunktionen für Telefonie

android.hardware.telephony

Die App verwendet die Telefoniefunktionen des Geräts, z. B. Telefoniefunktionen mit Datenkommunikationsdiensten.

android.hardware.telephony.cdma

Die Anwendung verwendet das CDMA-Telefoniesystem (Code Division Multiple Access).

Durch die Verwendung dieser Funktion impliziert eine App, dass sie auch die Funktion android.hardware.telephony verwendet, sofern diese übergeordnete Funktion nicht mit android:required="false" deklariert wird.

android.hardware.telephony.gsm

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

Touchscreen-Hardwarefunktionen

android.hardware.faketouch

Die App verwendet grundlegende Interaktionsereignisse wie Tippen und Ziehen.

Wenn diese Funktion als erforderlich deklariert wird, zeigt sie nur dann an, dass die App mit einem Gerät kompatibel ist, wenn das Gerät über einen emulierten Touchscreen mit „Fake Touch“ oder einen echten Touchscreen verfügt.

Ein Gerät, das eine gefälschte Touch-Oberfläche bietet, verfügt über ein Nutzereingabesystem, das einen Teil der Funktionen eines Touchscreens emuliert. Beispielsweise kann eine Maus oder eine Fernbedienung einen Cursor auf dem Bildschirm darstellen.

Wenn für Ihre App eine einfache Point-and-Click-Interaktion erforderlich ist und nicht nur mit einem Steuerkreuz funktioniert, deklarieren Sie diese Funktion. Da dies die minimale Touch-Interaktion darstellt, kannst du auf Geräten mit komplexeren Touchoberflächen auch eine App verwenden, in der diese Funktion deklariert ist.

Für Anwendungen ist die Funktion android.hardware.faketouch standardmäßig erforderlich. Wenn du möchtest, dass deine App auf Geräte beschränkt ist, die nur einen Touchscreen haben, musst du explizit angeben, dass Touchscreen erforderlich ist. Das geht so:

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

Alle Apps, für die android.hardware.touchscreen nicht explizit 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 unechten Touch-Oberfläche. Dies ist eine Obermenge des Features android.hardware.faketouch. Wenn diese Funktion als erforderlich deklariert wird, weist sie nur dann darauf hin, dass die App mit einem Gerät kompatibel ist, wenn dieses Gerät das eindeutige Tracking von zwei oder mehr Fingern emuliert oder einen echten Touchscreen hat.

Im Gegensatz zum verschiedenen durch android.hardware.touchscreen.multitouch.distinct definierten Multi-Touch-Format unterstützen Eingabegeräte, die diese Art von Multi-Touch mit einer gefälschten Touch-Oberfläche unterstützen, nicht alle Zweifinger-Touch-Gesten, da die Eingabe in Cursorbewegungen auf dem Bildschirm umgewandelt wird. Das heißt, Touch-Gesten mit einem Finger auf einem solchen Gerät bewegen einen Cursor, Wischen mit zwei Fingern führen zu Touch-Ereignissen mit einem Finger und andere Touch-Gesten mit zwei Fingern lösen die entsprechenden Touch-Ereignisse mit zwei Fingern aus.

Ein Gerät mit einem Touch-Touchpad mit zwei Fingern für die Cursorbewegung kann diese Funktion unterstützen.

android.hardware.faketouch.multitouch.jazzhand

Die App erfasst fünf oder mehr verschiedene "Finger" auf einer vorgetäuschten Touch-Oberfläche. Dies ist eine Obermenge des Features android.hardware.faketouch. Wenn diese Funktion als erforderlich deklariert wird, weist sie nur dann darauf hin, dass die App mit einem Gerät kompatibel ist, wenn dieses Gerät eine eindeutige Verfolgung von fünf oder mehr Fingern emuliert oder einen echten Touchscreen hat.

Im Gegensatz zum unterschiedlichen, durch android.hardware.touchscreen.multitouch.jazzhand definierten Multi-Touch-Format unterstützen Eingabegeräte, die Jazzhand-Multitouch mit einer gefälschten Touch-Oberfläche unterstützen, nicht alle Fünf-Finger-Gesten, da die Eingabe in Cursorbewegungen auf dem Bildschirm umgewandelt wird. Das heißt, Touch-Gesten mit einem einzelnen Finger auf einem solchen Gerät bewegen einen Cursor, Mehrfinger-Touch-Gesten führen zu Touch-Ereignissen mit einem Finger und andere Mehrfinger-Touch-Gesten lösen die entsprechenden Touch-Ereignisse mit mehreren Fingern aus.

Ein Gerät mit einem Touchpad mit fünf Fingern für die Cursorbewegung kann diese Funktion unterstützen.

android.hardware.touchscreen

Die App nutzt die Touchscreen-Funktionen des Geräts für Gesten, die interaktiver sind als grundlegende Touch-Ereignisse, wie z. B. das Wischen. Dies ist eine Obermenge des Features android.hardware.faketouch.

Standardmäßig benötigen alle Apps diese Funktion und sind daher nicht für Geräte verfügbar, die lediglich eine emulierte „Fake Touch-Oberfläche“ bieten. Du kannst deine App auf Geräten mit einer gefälschten Touchoberfläche oder sogar auf Geräten, auf denen nur ein Steuerkreuz verfügbar ist, zur Verfügung stellen, indem du in android.hardware.touchscreen mit android:required="false" explizit darlegst, dass kein Touchscreen erforderlich ist. Füge diese Deklaration hinzu, wenn in deiner App eine echte Touchscreen-Oberfläche verwendet wird, dies aber nicht erforderlich ist. Alle Apps, für die android.hardware.touchscreen nicht explizit erforderlich ist, funktionieren auch auf Geräten mit android.hardware.faketouch.

Wenn für deine App eine Touchoberfläche erforderlich ist, z. B. um komplexere Touch-Gesten wie Flings auszuführen, musst du keine Funktionen für die Touchoberfläche angeben, da diese standardmäßig erforderlich sind. Es empfiehlt sich jedoch, alle von Ihrer Anwendung verwendeten Funktionen explizit zu deklarieren.

Wenn eine komplexere Touch-Interaktion erforderlich ist, z. B. Touch-Gesten mit mehreren Fingern, solltest du angeben, dass deine App erweiterte Touchscreen-Funktionen verwendet.

android.hardware.touchscreen.multitouch

Die App verwendet die grundlegenden 2-Punkt-Multi-Touch-Funktionen des Geräts, z. B. für Auseinander- und Zusammenziehen der Finger. Sie muss Berührungen jedoch nicht unabhängig voneinander erfassen. Dies ist eine Obermenge des Features android.hardware.touchscreen.

Durch die Verwendung dieser Funktion impliziert eine App, dass sie auch die Funktion android.hardware.touchscreen verwendet, sofern diese übergeordnete Funktion nicht mit android:required="false" deklariert wird.

android.hardware.touchscreen.multitouch.distinct

Die App nutzt die erweiterten Multi-Touch-Funktionen des Geräts, um zwei oder mehr Punkte unabhängig voneinander zu erfassen. Dieses Feature ist eine Obermenge des Features android.hardware.touchscreen.multitouch.

Bei Verwendung dieses Features impliziert eine App, dass sie auch das Feature android.hardware.touchscreen.multitouch verwendet, sofern dieses übergeordnete Feature nicht mit android:required="false" deklariert wird.

android.hardware.touchscreen.multitouch.jazzhand

Die App nutzt die erweiterten Multi-Touch-Funktionen des Geräts, um fünf oder mehr Punkte unabhängig voneinander zu erfassen. Dieses Feature ist eine Obermenge des Features android.hardware.touchscreen.multitouch.

Funktionen der USB-Hardware

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 mit dem Gerät verbundene USB-Zubehör. Das Gerät dient als USB-Host.

Vulkan-Hardwarefunktionen

android.hardware.vulkan.compute

Die App nutzt die Computing-Funktionen von Vulkan. Diese Funktion weist darauf hin, dass für die App die hardwarebeschleunigte Vulkan-Implementierung erforderlich ist. Die Featureversion gibt an, welche optionalen Computing-Funktionen die App über die Anforderungen von Vulkan 1.0 hinaus erfordert. Wenn für Ihre App beispielsweise die Unterstützung von Vulkan-Computing-Level 0 erforderlich ist, deklarieren Sie folgendes Feature:

<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 nutzt Funktionen des Vulkan-Levels. Diese Funktion weist darauf hin, dass für die App die hardwarebeschleunigte Vulkan-Implementierung erforderlich ist. Die Funktionsversion gibt an, welche Stufe an optionalen Hardwarefunktionen die App benötigt. Wenn für deine App beispielsweise die Unterstützung für Vulkan-Hardwareebene 0 erforderlich ist, gib Folgendes an:

<uses-feature
    android:name="android.hardware.vulkan.level"
    android:version="0"
    android:required="true" />

Weitere Informationen zur Funktionsversion findest du unter


    FEATURE_VULKAN_HARDWARE_LEVEL

android.hardware.vulkan.version

Die App verwendet Vulkan. Diese Funktion weist darauf hin, dass für die App die hardwarebeschleunigte Vulkan-Implementierung erforderlich ist. Die Funktionsversion gibt an, welche Version des Vulkan API-Supports für die App mindestens benötigt wird. Wenn deine App beispielsweise Vulkan 1.0 unterstützt, gib Folgendes an:

<uses-feature
    android:name="android.hardware.vulkan.version"
    android:version="0x400003"
    android:required="true" />

Weitere Informationen zur Funktionsversion findest du unter


    FEATURE_VULKAN_HARDWARE_VERSION

WLAN-Hardwarefunktionen

android.hardware.wifi: Die App verwendet 802.11-Netzwerkfunktionen (WLAN) auf dem Gerät.
android.hardware.wifi.direct: Die App verwendet die Netzwerkfunktionen von Wi-Fi Direct auf dem Gerät.

Softwarefunktionen

In diesem Abschnitt werden die Softwarefunktionen beschrieben, die vom aktuellen Plattformrelease unterstützt werden. Wenn Sie angeben möchten, dass Ihre Anwendung ein Softwarefeature verwendet oder erfordert, deklarieren Sie den entsprechenden Wert, der mit "android.software" beginnt, in einem android:name-Attribut. Verwende jedes Mal, wenn du ein Softwarefeature deklarieren, ein separates <uses-feature>-Element.

Funktionen der Kommunikationssoftware

android.software.sip

Die Anwendung verwendet SIP-Dienste (Session Initiation Protocol). Mit SIP kann die Anwendung Internettelefonievorgänge wie Videokonferenzen und Instant Messaging unterstützen.

android.software.sip.voip

Die App verwendet SIP-basierte VoIP-Dienste (Voice Over Internet Protocol). Durch die Verwendung von VoIP kann die Anwendung Internettelefonie in Echtzeit unterstützen, z. B. Videokonferenzen in beide Richtungen.

Durch die Verwendung dieser Funktion impliziert eine App, dass sie auch die Funktion android.software.sip verwendet, sofern diese übergeordnete Funktion nicht mit android:required="false" deklariert wird.

android.software.webview

Die App zeigt Inhalte aus dem Internet an.

Benutzerdefinierte Eingabesoftwarefunktionen

android.software.input_methods: In der App wird eine neue Eingabemethode verwendet, die der Entwickler in einem InputMethodService definiert.

Softwarefunktionen zur Geräteverwaltung

android.software.backup: Die Anwendung enthält Logik für einen Sicherungs- und Wiederherstellungsvorgang.
android.software.device_admin: Die App verwendet Geräteadministratoren, um Geräterichtlinien zu erzwingen.
android.software.managed_users: Die Anwendung unterstützt sekundäre Nutzer und verwaltete Profile.
android.software.securely_removes_users: Die App kann Nutzer und die zugehörigen Daten dauerhaft entfernen.
android.software.verified_boot: Die App enthält eine Logik zur Verarbeitung der Ergebnisse der Funktion für den verifizierten Bootmodus des Geräts. Diese erkennt, ob sich die Gerätekonfiguration während eines Neustarts ändert.

Funktionen der Mediensoftware

android.software.midi: Die App stellt über das MIDI-Protokoll (Musical Instrument Digital Interface) eine Verbindung zu Musikinstrumenten her oder gibt Töne wieder.
android.software.print: Die App enthält Befehle zum Drucken von auf dem Gerät angezeigten Dokumenten.
android.software.leanback: Die App wurde für Android TV-Geräte entwickelt.
android.software.live_tv: Die App streamt Live-Fernsehprogramme.

Softwarefunktionen der Bildschirmoberfläche

android.software.app_widgets: Die App verwendet App-Widgets oder stellt sie bereit. Sie ist nur für Geräte mit einem Startbildschirm oder einem ähnlichen Ort gedacht, auf dem Nutzer diese einbetten können.
android.software.home_screen: Die App fungiert als Ersatz für den Startbildschirm des Geräts.
android.software.live_wallpaper: Die App verwendet Hintergründe mit Animationen oder stellt diese bereit.

Berechtigungen, die Anforderungen an die Funktion implizieren

Einige Konstanten für Hardware- und Softwarefunktionen werden nach der entsprechenden API für Anwendungen verfügbar gemacht. Aus diesem Grund kann es vorkommen, dass einige Apps die API verwenden, bevor durch das <uses-feature>-System erklärt wird, dass die API erforderlich ist.

Um zu verhindern, dass diese Apps unbeabsichtigt verfügbar gemacht werden, geht Google Play davon aus, dass bestimmte hardwarebezogene Berechtigungen bedeuten, 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 Legacy-Apps geht Google Play davon aus, dass die Erklärung zu Berechtigungen bedeutet, dass die zugrunde liegende Funktion android.hardware.bluetooth für die App erforderlich ist, und richtet die Filterung auf Grundlage dieser Funktion ein. In Tabelle 2 sind Berechtigungen aufgeführt, für die Funktionsanforderungen gelten, die den in <uses-feature>-Elementen deklarierten Anforderungen entsprechen.

<uses-feature>-Deklarationen, einschließlich aller deklarierten android:required-Attribute, haben immer Vorrang vor den Funktionen, die durch die Berechtigungen in Tabelle 2 impliziert werden. Für jede dieser Berechtigungen können Sie das Filtern basierend auf dem impliziten Feature deaktivieren, indem Sie das Feature explizit in einem <uses-feature>-Element deklarieren, bei dem das Attribut required auf false gesetzt ist.

Wenn du beispielsweise die Filterung auf Grundlage der Berechtigung CAMERA deaktivieren möchtest, füge 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 deine 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 Standortupdates vom Netzwerk bzw. GPS zu erhalten, musst du außerdem explizit deklarieren, dass deine App die Hardwarefunktionen android.hardware.location.network oder android.hardware.location.gps verwendet.

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

Kategorie	Berechtigung	Implizite Funktionsanforderung
Bluetooth	`BLUETOOTH`	`android.hardware.bluetooth` Weitere Informationen finden Sie unter Besondere Hinweise zur Verwendung der Bluetooth-Funktion.
Bluetooth	`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`