Jede Android-App wird in einer Sandbox mit eingeschränktem Zugriff ausgeführt. Wenn Ihre Anwendung Ressourcen oder Informationen außerhalb ihrer eigenen Sandbox verwenden muss, können Sie eine Laufzeitberechtigung deklarieren und eine Berechtigungsanfrage einrichten, die diesen Zugriff gewährt. Diese Schritte sind Teil des Workflows zur Verwendung von Berechtigungen.
Wenn Sie gefährliche Berechtigungen deklarieren und Ihre App auf einem Gerät mit Android 6.0 (API-Level 23) oder höher installiert ist, müssen Sie die gefährlichen Berechtigungen zur Laufzeit anfordern. Folgen Sie dazu der Anleitung in dieser Anleitung.
Wenn du keine gefährlichen Berechtigungen angibst oder deine App auf einem Gerät installiert ist, auf dem Android 5.1 (API-Level 22) oder niedriger ausgeführt wird, werden die Berechtigungen automatisch gewährt und du musst die restlichen Schritte auf dieser Seite nicht ausführen.
Grundprinzipien
Für das Anfordern von Berechtigungen während der Laufzeit gelten folgende Grundprinzipien:
- Fordern Sie eine Berechtigung im Kontext an, wenn der Nutzer beginnt, mit der Funktion zu interagieren, für die diese erforderlich ist.
- Sie sollten den Nutzer nicht blockieren. Bieten Sie immer die Option an, einen UI-Ablauf mit Bildungsinhalten abzubrechen, z. B. bei einem Ablauf, in dem die Begründung für das Anfordern von Berechtigungen erläutert wird.
- Wenn der Nutzer eine für eine Funktion erforderliche Berechtigung ablehnt oder widerruft, stufen Sie Ihre App so ein, dass der Nutzer sie weiterhin verwenden kann. Dazu muss er möglicherweise die Funktion deaktivieren, für die die Berechtigung erforderlich ist.
- Gehen Sie nicht von einem Systemverhalten aus. Gehen Sie beispielsweise nicht davon aus, dass Berechtigungen in derselben Berechtigungsgruppe aufgeführt sind. Eine Berechtigungsgruppe hilft dem System lediglich, die Anzahl der Systemdialoge zu minimieren, die dem Nutzer angezeigt werden, wenn eine App eng verwandte Berechtigungen anfordert.
Workflow zum Anfordern von Berechtigungen
Bevor Sie in Ihrer App Laufzeitberechtigungen deklarieren und anfordern, prüfen Sie, ob dies für Ihre App erforderlich ist. Sie können viele Anwendungsfälle in Ihrer App erfüllen, z. B. Fotos aufnehmen, die Medienwiedergabe pausieren und relevante Anzeigen einblenden, ohne Berechtigungen angeben zu müssen.
Wenn Sie zu dem Schluss kommen, dass Ihre Anwendung Laufzeitberechtigungen erklären und anfordern muss, führen Sie die folgenden Schritte aus:
- Deklarieren Sie in der Manifestdatei Ihrer Anwendung die Berechtigungen, die Ihre Anwendung möglicherweise anfordern muss.
- Gestalten Sie Ihre App so, dass bestimmte Aktionen in Ihrer App mit bestimmten Laufzeitberechtigungen verknüpft sind. Teilen Sie Nutzern mit, für welche Aktionen sie Ihrer App möglicherweise die Berechtigung erteilen müssen, auf private Nutzerdaten zuzugreifen.
- Warten Sie, bis der Nutzer die Aufgabe oder Aktion in Ihrer App aufruft, die Zugriff auf bestimmte private Nutzerdaten benötigt. Zu diesem Zeitpunkt kann Ihre Anwendung die Laufzeitberechtigung anfordern, die für den Zugriff auf diese Daten erforderlich ist.
Prüfen Sie, ob der Nutzer bereits die Laufzeitberechtigung gewährt hat, die für Ihre App erforderlich ist. In diesem Fall kann Ihre App auf die privaten Nutzerdaten zugreifen. Sollte dies nicht der Fall sein, fahren Sie mit dem nächsten Schritt fort.
Sie müssen jedes Mal prüfen, ob Sie eine Berechtigung haben, wenn Sie einen Vorgang ausführen, für den diese Berechtigung erforderlich ist.
Überprüfe, ob deine App dem Nutzer eine Begründung anzeigen soll. Erläutere, warum der Nutzer eine bestimmte Laufzeitberechtigung erteilen muss. Wenn das System feststellt, dass Ihre App keine Begründung anzeigen sollte, fahren Sie direkt mit dem nächsten Schritt fort, ohne ein UI-Element anzuzeigen.
Wenn das System feststellt, dass Ihre App eine Begründung anzeigen soll, präsentieren Sie die Begründung dem Nutzer in einem UI-Element. Erläutern Sie daher klar, auf welche Daten Ihre App zugreifen möchte und welche Vorteile die App dem Nutzer mit der Laufzeitberechtigung bieten kann. Nachdem der Nutzer die Begründung bestätigt hat, fahre mit dem nächsten Schritt fort.
Fordern Sie die Laufzeitberechtigung an, die Ihre App für den Zugriff auf die privaten Nutzerdaten benötigt. Das System zeigt eine Aufforderung zur Laufzeitberechtigung an, wie z. B. auf der Seite mit der Berechtigungsübersicht.
Prüfen Sie die Antwort des Nutzers – ob er die Laufzeitberechtigung gewährt oder abgelehnt hat.
Wenn der Nutzer die Berechtigung für Ihre App erteilt hat, können Sie auf die privaten Nutzerdaten zugreifen. Wenn der Nutzer stattdessen die Berechtigung verweigert hat, stufen Sie Ihre App-Nutzung gerechtfertigt ein, sodass sie Funktionen für den Nutzer ohne die Informationen bietet, die durch diese Berechtigung geschützt sind.
Abbildung 1 veranschaulicht den Workflow und die mit diesem Prozess verbundenen Entscheidungen:
Herausfinden, ob Ihrer App die Berechtigung bereits gewährt wurde
Wenn Sie prüfen möchten, ob der Nutzer Ihrer App bereits eine bestimmte Berechtigung erteilt hat, übergeben Sie diese Berechtigung an die Methode ContextCompat.checkSelfPermission(). Bei dieser Methode wird entweder PERMISSION_GRANTED oder PERMISSION_DENIED zurückgegeben, je nachdem, ob Ihre App die Berechtigung hat.
Erläutere, warum deine App die Berechtigung benötigt
Im Berechtigungsdialogfeld, das beim Aufrufen von requestPermissions() vom System angezeigt wird, wird angegeben, welche Berechtigung die App benötigt, aber nicht warum. In einigen Fällen könnte dies den Nutzenden ein Rätsel geben. Du solltest dem Nutzer erklären, warum deine App die Berechtigungen benötigt, bevor du requestPermissions() aufrufst.
Untersuchungen haben gezeigt, dass Nutzer mit Berechtigungsanfragen eher vertraut sind, wenn sie wissen, warum die App sie benötigt, z. B. ob die Berechtigung für eine Hauptfunktion der App oder für Werbung erforderlich ist. Wenn Sie nur einen Bruchteil der API-Aufrufe verwenden, die zu einer Berechtigungsgruppe gehören, ist es daher hilfreich, explizit anzugeben, welche dieser Berechtigungen Sie verwenden und warum. Wenn Sie beispielsweise nur den ungefähren Standort verwenden, teilen Sie dem Nutzer dies in der App-Beschreibung oder in den Hilfeartikeln zu Ihrer App mit.
Unter bestimmten Bedingungen ist es auch hilfreich, Nutzer in Echtzeit über den Zugriff auf sensible Daten zu informieren. Wenn Sie z. B. auf die Kamera oder das Mikrofon zugreifen, sollten Sie den Nutzer über ein Benachrichtigungssymbol irgendwo in der App oder in der Benachrichtigungsleiste (wenn die App im Hintergrund ausgeführt wird) darüber informieren, damit es nicht so aussieht, als würden Sie Daten heimlich erheben.
Wenn Sie eine Berechtigung anfordern müssen, um etwas in Ihrer App ausführen zu können, der Grund aber dem Nutzer nicht klar ist, versuchen Sie, dem Nutzer mitzuteilen, warum Sie die sensibelsten Berechtigungen benötigen.
Wenn die Methode ContextCompat.checkSelfPermission() PERMISSION_DENIED zurückgibt, rufen Sie shouldShowRequestPermissionRationale() auf.
Wenn diese Methode true zurückgibt, wird dem Nutzer eine Benutzeroberfläche zur Information angezeigt. Beschreiben Sie in dieser UI, warum für die Funktion, die der Nutzer aktivieren möchte, eine bestimmte Berechtigung erforderlich ist.
Wenn Ihre App eine Berechtigung für den Standort, das Mikrofon oder die Kamera anfordert, sollten Sie außerdem erklären, warum Ihre App Zugriff auf diese Informationen benötigt.
Berechtigungen anfordern
Nachdem der Nutzer eine UI für Bildungseinrichtungen aufgerufen hat oder der Rückgabewert von shouldShowRequestPermissionRationale() angibt, dass keine UI für Bildungseinrichtungen angezeigt werden muss, fordern Sie die Berechtigung an. Die Nutzer sehen ein Dialogfeld mit den Systemberechtigungen, in dem sie auswählen können, ob sie Ihrer App eine bestimmte Berechtigung gewähren möchten.
Verwende dazu den Vertrag RequestPermission, der in einer AndroidX-Bibliothek enthalten ist, und erlaube dem System, den Code für Berechtigungsanfragen zu verwalten. Da die Verwendung des RequestPermission-Vertrags Ihre Logik vereinfacht, ist es nach Möglichkeit die empfohlene Lösung. Bei Bedarf können Sie jedoch im Rahmen der Berechtigungsanfrage auch einen Anfragecode selbst verwalten und diesen Anfragecode in Ihre Callback-Logik für Berechtigungen aufnehmen.
System erlauben, den Code der Berechtigungsanfrage zu verwalten
Damit das System den Anfragecode verwalten kann, der mit einer Berechtigungsanfrage verknüpft ist, fügen Sie der Datei build.gradle des Moduls Abhängigkeiten von den folgenden Bibliotheken hinzu:
androidx.activity, Version 1.2.0 oder höherandroidx.fragment, Version 1.3.0 oder höher
Sie können dann eine der folgenden Klassen verwenden:
- Verwenden Sie
RequestPermission, um eine einzelne Berechtigung anzufordern. - Verwenden Sie
RequestMultiplePermissions, um mehrere Berechtigungen gleichzeitig anzufordern.
Die folgenden Schritte zeigen, wie der RequestPermission-Vertrag verwendet wird. Die Vorgehensweise für den RequestMultiplePermissions-Vertrag ist fast identisch.
Übergeben Sie in der Initialisierungslogik Ihrer Aktivität oder Ihres Fragments eine Implementierung von
ActivityResultCallbackin einen Aufruf vonregisterForActivityResult(). ÜberActivityResultCallbackwird definiert, wie Ihre Anwendung die Antwort des Nutzers auf die Berechtigungsanfrage verarbeitet.Verweisen Sie auf den Rückgabewert von
registerForActivityResult(), der vom TypActivityResultLauncherist.Rufen Sie bei Bedarf die Methode
launch()auf der Instanz vonActivityResultLauncherauf, die Sie im vorherigen Schritt gespeichert haben, damit das Dialogfeld für Systemberechtigungen bei Bedarf eingeblendet wird.Nachdem
launch()aufgerufen wurde, wird das Dialogfeld für Systemberechtigungen angezeigt. Wenn der Nutzer eine Auswahl trifft, ruft das System asynchron die Implementierung vonActivityResultCallbackauf, die Sie im vorherigen Schritt definiert haben.Hinweis : Das Dialogfeld, das beim Aufrufen von
launch()angezeigt wird, kann in Ihrer App nicht angepasst werden. Wenn du Nutzern mehr Informationen oder Kontext liefern möchtest, ändere die Benutzeroberfläche deiner App so, dass Nutzer leichter nachvollziehen können, warum eine Funktion in deiner App eine bestimmte Berechtigung benötigt. Sie können beispielsweise den Text in der Schaltfläche ändern, mit der das Feature aktiviert wird.Außerdem verweist der Text im Dialogfeld für Systemberechtigungen auf die Berechtigungsgruppe, die mit der angeforderten Berechtigung verknüpft ist. Diese Gruppierung von Berechtigungen ist für eine einfache Bedienbarkeit des Systems konzipiert. Ihre App sollte sich nicht darauf verlassen, dass Berechtigungen innerhalb oder außerhalb einer bestimmten Berechtigungsgruppe sind.
Das folgende Code-Snippet zeigt, wie die Berechtigungsantwort verarbeitet wird:
Kotlin
// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher. You can use either a val, as shown in this snippet,
// or a lateinit var in your onAttach() or onCreate() method.
val requestPermissionLauncher =
registerForActivityResult(RequestPermission()
) { isGranted: Boolean ->
if (isGranted) {
// Permission is granted. Continue the action or workflow in your
// app.
} else {
// Explain to the user that the feature is unavailable because the
// feature requires a permission that the user has denied. At the
// same time, respect the user's decision. Don't link to system
// settings in an effort to convince the user to change their
// decision.
}
}
Java
// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher, as an instance variable.
private ActivityResultLauncher<String> requestPermissionLauncher =
registerForActivityResult(new RequestPermission(), isGranted -> {
if (isGranted) {
// Permission is granted. Continue the action or workflow in your
// app.
} else {
// Explain to the user that the feature is unavailable because the
// feature requires a permission that the user has denied. At the
// same time, respect the user's decision. Don't link to system
// settings in an effort to convince the user to change their
// decision.
}
});
Und dieses Code-Snippet zeigt den empfohlenen Prozess für die Überprüfung auf eine Berechtigung und das Anfordern einer Berechtigung vom Nutzer, falls erforderlich:
Kotlin
when {
ContextCompat.checkSelfPermission(
CONTEXT,
Manifest.permission.REQUESTED_PERMISSION
) == PackageManager.PERMISSION_GRANTED -> {
// You can use the API that requires the permission.
}
ActivityCompat.shouldShowRequestPermissionRationale(
this, Manifest.permission.REQUESTED_PERMISSION) -> {
// In an educational UI, explain to the user why your app requires this
// permission for a specific feature to behave as expected, and what
// features are disabled if it's declined. In this UI, include a
// "cancel" or "no thanks" button that lets the user continue
// using your app without granting the permission.
showInContextUI(...)
}
else -> {
// You can directly ask for the permission.
// The registered ActivityResultCallback gets the result of this request.
requestPermissionLauncher.launch(
Manifest.permission.REQUESTED_PERMISSION)
}
}
Java
if (ContextCompat.checkSelfPermission(
CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
PackageManager.PERMISSION_GRANTED) {
// You can use the API that requires the permission.
performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
this, Manifest.permission.REQUESTED_PERMISSION)) {
// In an educational UI, explain to the user why your app requires this
// permission for a specific feature to behave as expected, and what
// features are disabled if it's declined. In this UI, include a
// "cancel" or "no thanks" button that lets the user continue
// using your app without granting the permission.
showInContextUI(...);
} else {
// You can directly ask for the permission.
// The registered ActivityResultCallback gets the result of this request.
requestPermissionLauncher.launch(
Manifest.permission.REQUESTED_PERMISSION);
}
Code für Berechtigungsanfragen selbst verwalten
Anstatt dem System zu erlauben, den Berechtigungsanfragecode zu verwalten, kannst du den Code für Berechtigungsanfragen auch selbst verwalten. Fügen Sie dazu den Anfragecode in einen Aufruf von requestPermissions() ein.
Das folgende Code-Snippet zeigt, wie Sie mit einem Anfragecode eine Berechtigung anfordern:
Kotlin
when {
ContextCompat.checkSelfPermission(
CONTEXT,
Manifest.permission.REQUESTED_PERMISSION
) == PackageManager.PERMISSION_GRANTED -> {
// You can use the API that requires the permission.
performAction(...)
}
ActivityCompat.shouldShowRequestPermissionRationale(
this, Manifest.permission.REQUESTED_PERMISSION) -> {
// In an educational UI, explain to the user why your app requires this
// permission for a specific feature to behave as expected, and what
// features are disabled if it's declined. In this UI, include a
// "cancel" or "no thanks" button that lets the user continue
// using your app without granting the permission.
showInContextUI(...)
}
else -> {
// You can directly ask for the permission.
requestPermissions(CONTEXT,
arrayOf(Manifest.permission.REQUESTED_PERMISSION),
REQUEST_CODE)
}
}
Java
if (ContextCompat.checkSelfPermission(
CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
PackageManager.PERMISSION_GRANTED) {
// You can use the API that requires the permission.
performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
this, Manifest.permission.REQUESTED_PERMISSION)) {
// In an educational UI, explain to the user why your app requires this
// permission for a specific feature to behave as expected, and what
// features are disabled if it's declined. In this UI, include a
// "cancel" or "no thanks" button that lets the user continue
// using your app without granting the permission.
showInContextUI(...);
} else {
// You can directly ask for the permission.
requestPermissions(CONTEXT,
new String[] { Manifest.permission.REQUESTED_PERMISSION },
REQUEST_CODE);
}
Nachdem der Nutzer auf das Dialogfeld mit den Systemberechtigungen geantwortet hat, ruft das System die Implementierung von onRequestPermissionsResult() in Ihrer App auf. Das System übergibt die Nutzerantwort an das Berechtigungsdialogfeld sowie den von Ihnen definierten Anfragecode, wie im folgenden Code-Snippet gezeigt:
Kotlin
override fun onRequestPermissionsResult(requestCode: Int,
permissions: Array<String>, grantResults: IntArray) {
when (requestCode) {
PERMISSION_REQUEST_CODE -> {
// If request is cancelled, the result arrays are empty.
if ((grantResults.isNotEmpty() &&
grantResults[0] == PackageManager.PERMISSION_GRANTED)) {
// Permission is granted. Continue the action or workflow
// in your app.
} else {
// Explain to the user that the feature is unavailable because
// the feature requires a permission that the user has denied.
// At the same time, respect the user's decision. Don't link to
// system settings in an effort to convince the user to change
// their decision.
}
return
}
// Add other 'when' lines to check for other
// permissions this app might request.
else -> {
// Ignore all other requests.
}
}
}
Java
@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions,
int[] grantResults) {
switch (requestCode) {
case PERMISSION_REQUEST_CODE:
// If request is cancelled, the result arrays are empty.
if (grantResults.length > 0 &&
grantResults[0] == PackageManager.PERMISSION_GRANTED) {
// Permission is granted. Continue the action or workflow
// in your app.
} else {
// Explain to the user that the feature is unavailable because
// the feature requires a permission that the user has denied.
// At the same time, respect the user's decision. Don't link to
// system settings in an effort to convince the user to change
// their decision.
}
return;
}
// Other 'case' lines to check for other
// permissions this app might request.
}
}
Berechtigung zur Standortermittlung anfordern
Wenn Sie Berechtigungen zur Standortermittlung anfordern, folgen Sie denselben Best Practices wie für jede andere Laufzeitberechtigung. Ein wichtiger Unterschied bei den Berechtigungen zur Standortermittlung besteht darin, dass das System mehrere Berechtigungen für die Standortermittlung enthält. Welche Berechtigungen Sie anfordern und wie Sie sie anfordern, hängt von den Standortanforderungen für den Anwendungsfall Ihrer App ab.
Position im Vordergrund
Wenn Ihre App eine Funktion enthält, die Standortinformationen nur einmal oder für einen bestimmten Zeitraum teilt oder empfängt, ist für diese Funktion der Zugriff auf die Standortermittlung im Vordergrund erforderlich. Hier einige Beispiele:
- Innerhalb einer Navigations-App können Nutzer mithilfe einer Funktion eine detaillierte Routenführung abrufen.
- Innerhalb einer Messaging-App können Nutzer über eine Funktion ihren aktuellen Standort mit einem anderen Nutzer teilen.
Das System geht davon aus, dass Ihre App die Standortermittlung im Vordergrund verwendet, wenn eine Funktion Ihrer App in einer der folgenden Situationen auf den aktuellen Standort des Geräts zugreift:
- Aktivitäten, die zu Ihrer App gehören, sind sichtbar.
In deiner App wird ein Dienst im Vordergrund ausgeführt. Wenn ein Dienst im Vordergrund ausgeführt wird, macht das System den Nutzer durch eine dauerhafte Benachrichtigung auf sich aufmerksam. Die App behält den Zugriff, wenn sie im Hintergrund platziert wird, z. B. wenn der Nutzer die Startbildschirmtaste auf seinem Gerät drückt oder das Display des Geräts ausschaltet.
Unter Android 10 (API-Level 29) und höher musst du
locationals Diensttyp im Vordergrund angeben, wie im folgenden Code-Snippet gezeigt. In früheren Android-Versionen wird empfohlen, diesen Typ von Diensten im Vordergrund zu deklarieren.<!-- Recommended for Android 9 (API level 28) and lower. --> <!-- Required for Android 10 (API level 29) and higher. --> <service android:name="MyNavigationService" android:foregroundServiceType="location" ... > <!-- Any inner elements go here. --> </service>
Sie deklarieren dies als erforderlich, wenn Ihre App die Berechtigung ACCESS_COARSE_LOCATION oder ACCESS_FINE_LOCATION anfordert, wie im folgenden Snippet gezeigt:
<manifest ... > <!-- Include this permission any time your app needs location information. --> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <!-- Include only if your app benefits from precise location access. --> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> </manifest>
Standortermittlung im Hintergrund
Eine App benötigt Zugriff auf die Standortermittlung im Hintergrund, wenn eine Funktion innerhalb der App den Standort ständig mit anderen Nutzern teilt oder die Geofencing API verwendet. Hier einige Beispiele:
- Mit einer Funktion in einer App zur Freigabe des Familienstandorts können Nutzer ihren Standort kontinuierlich mit Familienmitgliedern teilen.
- Innerhalb einer IoT-App können Nutzer ihre Smart-Home-Geräte mit einer Funktion so konfigurieren, dass sie sich ausschalten, wenn der Nutzer sein Zuhause verlässt, und wieder einschalten, wenn er nach Hause kommt.
Das System betrachtet die Standortermittlung im Hintergrund für Ihre App, wenn sie auf den aktuellen Standort des Geräts in einer anderen als der im Abschnitt Standort im Vordergrund beschriebenen Situation zugreift. Die Genauigkeit der Standortermittlung im Hintergrund entspricht der Genauigkeit der Standortermittlung im Vordergrund, die von den Standortberechtigungen abhängig ist, die in Ihrer App deklariert sind.
Unter Android 10 (API-Level 29) und höher müssen Sie im Manifest Ihrer App die Berechtigung ACCESS_BACKGROUND_LOCATION deklarieren, um zur Laufzeit Zugriff auf die Standortermittlung im Hintergrund anzufordern. Wenn Ihre App in früheren Android-Versionen Zugriff auf die Standortermittlung im Vordergrund erhält, wird diese ebenfalls automatisch auf die Standortermittlung im Hintergrund übertragen.
<manifest ... >
<!-- Required only when requesting background location access on
Android 10 (API level 29) and higher. -->
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</manifest>
Umgang mit Berechtigungsverweigerungen
Wenn der Nutzer eine Berechtigungsanfrage ablehnt, sollte Ihre App Nutzern dabei helfen, die Auswirkungen der Ablehnung der Berechtigung zu verstehen. Insbesondere sollte Ihre App Nutzer auf die Funktionen aufmerksam machen, die aufgrund der fehlenden Berechtigung nicht funktionieren. Dabei sind die folgenden Best Practices zu beachten:
Lenken Sie die Aufmerksamkeit des Nutzers. Heben Sie einen bestimmten Teil der App-Benutzeroberfläche hervor, der nur eingeschränkt funktioniert, weil Ihre App nicht die erforderlichen Berechtigungen hat. Sie könnten beispielsweise Folgendes tun:
- Blenden Sie eine Nachricht ein, in der die Ergebnisse oder Daten des Elements angezeigt worden wären.
- Zeigen Sie eine andere Schaltfläche mit einem Fehlersymbol und einer Fehlerfarbe an.
Seien Sie konkret. Keine allgemeine Mitteilung anzeigen. Erkenne stattdessen, welche Funktionen nicht verfügbar sind, da deine App nicht die erforderlichen Berechtigungen hat.
Blockiere nicht die Benutzeroberfläche. Mit anderen Worten: Zeigen Sie keine Vollbildwarnung an, die Nutzer daran hindert, Ihre App überhaupt nicht weiter zu verwenden.
Gleichzeitig sollte Ihre App die Entscheidung des Nutzers respektieren, eine Berechtigung zu verweigern. Wenn Nutzer ab Android 11 (API-Level 30) während der Installation der App auf einem Gerät mehrmals auf Ablehnen tippen, wird das Dialogfeld für Systemberechtigungen nicht angezeigt, wenn die App die Berechtigung noch einmal anfordert. Die Aktion des Nutzers impliziert „Nicht mehr fragen“. In früheren Versionen wurde den Nutzern das Dialogfeld für Systemberechtigungen jedes Mal angezeigt, wenn Ihre App eine Berechtigung anforderte, es sei denn, sie hatten zuvor das Kästchen oder die Option „Nicht mehr fragen“ ausgewählt.
Wenn ein Nutzer eine Berechtigungsanfrage mehr als einmal ablehnt, gilt dies als dauerhafte Ablehnung. Es ist sehr wichtig, Nutzer nur dann zur Berechtigung aufzufordern, wenn sie Zugriff auf eine bestimmte Funktion benötigen. Andernfalls können Sie versehentlich die Berechtigung verlieren, Berechtigungen noch einmal anzufordern.
In bestimmten Situationen kann die Berechtigung automatisch verweigert werden, ohne dass der Nutzer etwas ergreift. (Eine Berechtigung kann auch automatisch gewährt werden.) Es ist wichtig, nichts über automatisches Verhalten anzunehmen. Jedes Mal, wenn Ihre App auf Funktionen zugreifen muss, für die eine Berechtigung erforderlich ist, prüfen Sie, ob sie diese Berechtigung noch erhält.
Informationen zur optimalen Nutzerfreundlichkeit bei der Abfrage von App-Berechtigungen finden Sie unter Best Practices für App-Berechtigungen.
Ablehnungsstatus beim Testen und Debuggen prüfen
Verwenden Sie den folgenden Befehl, um zu Fehlerbehebungs- und Testzwecken zu ermitteln, ob einer App dauerhaft Berechtigungen verweigert wurden:
adb shell dumpsys package PACKAGE_NAME
Dabei ist PACKAGE_NAME der Name des zu prüfenden Pakets.
Die Ausgabe des Befehls enthält Abschnitte wie diese:
... runtime permissions: android.permission.POST_NOTIFICATIONS: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED] android.permission.ACCESS_FINE_LOCATION: granted=false, flags=[ USER_SET|USER_FIXED|USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED] android.permission.BLUETOOTH_CONNECT: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED] ...
Berechtigungen, die der Nutzer einmal verweigert hat, sind von USER_SET gekennzeichnet.
Berechtigungen, die durch zweimaliges Auswählen von Ablehnen dauerhaft abgelehnt wurden, werden von USER_FIXED gekennzeichnet.
Damit Tester das Dialogfeld mit den Anfragen während des Tests sehen, setzen Sie diese Flags zurück, wenn Sie mit dem Debugging Ihrer App fertig sind. Verwenden Sie dazu den folgenden Befehl:
adb shell pm clear-permission-flags PACKAGE_NAME PERMISSION_NAME user-set user-fixed
PERMISSION_NAME ist der Name der Berechtigung, die Sie zurücksetzen möchten.
Eine vollständige Liste der Berechtigungen für Android-Apps finden Sie auf der Referenzseite der Entitlements API.
Einmalige Berechtigungen
Ab Android 11 (API-Level 30) enthält das Dialogfeld mit Berechtigungen für Nutzer jedes Mal, wenn deine App eine Berechtigung für den Standort, das Mikrofon oder die Kamera anfordert, die Option Nur dieses Mal (siehe Abbildung 2). Wenn der Nutzer diese Option im Dialogfeld auswählt, wird Ihrer App eine temporäre einmalige Berechtigung gewährt.
Ihre App kann dann für einen bestimmten Zeitraum auf die zugehörigen Daten zugreifen, der vom Verhalten Ihrer App und den Aktionen des Nutzers abhängt:
- Die App-Aktivitäten sind zwar sichtbar, aber sie können auf die Daten zugreifen.
- Wenn der Nutzer Ihre App in den Hintergrund verschiebt, kann die App für kurze Zeit weiter auf die Daten zugreifen.
- Wenn Sie einen Dienst im Vordergrund starten, während die Aktivität sichtbar ist, und der Nutzer die App dann in den Hintergrund verschiebt, kann die App so lange auf die Daten zugreifen, bis der Dienst im Vordergrund beendet wird.
App-Prozess wird beendet, wenn die Berechtigung widerrufen wird
Wenn der Nutzer die einmalige Berechtigung widerruft, z. B. in den Systemeinstellungen, kann Ihre App nicht auf die Daten zugreifen, unabhängig davon, ob Sie einen Dienst im Vordergrund gestartet haben. Wie bei jeder Berechtigung wird der Prozess der App beendet, wenn der Nutzer die einmalige Berechtigung Ihrer App widerruft.
Wenn der Nutzer die App das nächste Mal öffnet und eine Funktion in der App Zugriff auf den Standort, das Mikrofon oder die Kamera anfordert, wird er noch einmal um die Berechtigung gebeten.
Nicht verwendete Berechtigungen zurücksetzen
Android bietet mehrere Möglichkeiten, nicht verwendete Laufzeitberechtigungen auf den standardmäßigen abgelehnten Status zurückzusetzen:
- Eine API, mit der Sie proaktiv den Zugriff Ihrer App auf eine nicht verwendete Laufzeitberechtigung entfernen können.
- Ein Systemmechanismus, der die Berechtigungen nicht verwendeter Apps automatisch zurücksetzt.
App-Zugriff entfernen
Unter Android 13 (API-Level 33) und höher können Sie den Zugriff Ihrer App auf Laufzeitberechtigungen entfernen, die für Ihre App nicht mehr erforderlich sind. Wenn du deine App aktualisierst, solltest du diesen Schritt ausführen, damit Nutzer besser nachvollziehen können, warum deine App weiterhin bestimmte Berechtigungen anfordert. Dieses Wissen stärkt das Vertrauen der Nutzer in deine App.
Wenn Sie den Zugriff auf eine Laufzeitberechtigung entfernen möchten, übergeben Sie den Namen dieser Berechtigung an revokeSelfPermissionOnKill().
Wenn Sie gleichzeitig den Zugriff auf eine Gruppe von Laufzeitberechtigungen entfernen möchten, übergeben Sie eine Sammlung von Berechtigungsnamen an revokeSelfPermissionsOnKill().
Der Vorgang zum Entfernen von Berechtigungen erfolgt asynchron und beendet alle Prozesse, die mit der UID Ihrer Anwendung verknüpft sind.
Damit das System den Zugriff Ihrer App auf die Berechtigungen entfernen kann, müssen alle mit Ihrer App verbundenen Prozesse beendet werden. Wenn Sie die API aufrufen, ermittelt das System, wann diese Prozesse beendet werden können. Normalerweise wartet das System, bis Ihre Anwendung längere Zeit im Hintergrund und nicht im Vordergrund ausgeführt wird.
Um den Nutzer zu informieren, dass Ihre App keinen Zugriff auf bestimmte Laufzeitberechtigungen mehr benötigt, zeigen Sie beim nächsten Start der App ein Dialogfeld an. Dieses Dialogfeld kann eine Liste der Berechtigungen enthalten.
Berechtigungen für nicht verwendete Apps automatisch zurücksetzen
Wenn deine App auf Android 11 (API-Level 30) oder höher ausgerichtet ist und einige Monate lang nicht verwendet wird, schützt das System Nutzerdaten, indem die vertraulichen Laufzeitberechtigungen, die der Nutzer deiner App erteilt hat, automatisch zurückgesetzt wird. Weitere Informationen findest du im Leitfaden zum App-Ruhezustand.
Anfrage zum Festlegen des Standard-Handlers, falls erforderlich
Einige Apps benötigen Zugriff auf vertrauliche Nutzerinformationen aus Anruflisten und SMS-Nachrichten. Wenn Sie die spezifischen Berechtigungen für Anruflisten und SMS anfordern und Ihre App im Play Store veröffentlichen möchten, müssen Sie den Nutzer auffordern, Ihre App als Standard-Handler für eine Kernsystemfunktion festzulegen, bevor Sie diese Laufzeitberechtigungen anfordern.
Weitere Informationen zu Standard-Handlern, einschließlich einer Anleitung zum Anzeigen einer Standard-Handler-Aufforderung für Nutzer, finden Sie im Leitfaden zu Berechtigungen, die nur in Standard-Handlern verwendet werden.
Alle Laufzeitberechtigungen zu Testzwecken gewähren
Wenn Sie alle Laufzeitberechtigungen automatisch gewähren möchten, wenn Sie eine App auf einem Emulator oder Testgerät installieren, verwenden Sie für den Befehl adb shell install die Option -g, wie im folgenden Code-Snippet gezeigt:
adb shell install -g PATH_TO_APK_FILE
Weitere Informationen
Weitere Informationen zu Berechtigungen finden Sie in diesen Artikeln:
Weitere Informationen zum Anfordern von Berechtigungen finden Sie in den Beispielen zu Berechtigungen.
Sie können auch dieses Codelab mit Best Practices zum Datenschutz durcharbeiten.