Jede Android-App wird in einer Sandbox mit eingeschränktem Zugriff ausgeführt. Wenn Ihre App 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 gehören zum Workflow zur Verwendung von Berechtigungen.
Wenn du gefährliche Berechtigungen festlegst und deine App auf einem Gerät mit Android 6.0 (API-Level 23) oder höher installiert ist, musst du die gefährlichen Berechtigungen zur Laufzeit anfordern. Folge dazu den Schritten in dieser Anleitung.
Wenn du keine gefährlichen Berechtigungen deklarierst oder deine App auf einem Gerät mit Android 5.1 (API-Level 22) oder niedriger installiert ist, werden die Berechtigungen automatisch gewährt und du musst die restlichen Schritte auf dieser Seite nicht ausführen.
Grundprinzipien
Die Grundprinzipien für das Anfordern von Berechtigungen zur Laufzeit lauten wie folgt:
- Eine Berechtigung sollte im Kontext angefordert werden, wenn der Nutzer beginnt, mit der Funktion zu interagieren, für die sie erforderlich ist.
- Nutzer nicht blockieren Bieten Sie immer die Möglichkeit, einen pädagogischen UI-Ablauf abzubrechen, z. B. einen Ablauf, der die Begründung für das Anfordern von Berechtigungen erläutert.
- 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 können Sie beispielsweise 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 enthalten sind. Eine Berechtigungsgruppe trägt lediglich dazu bei, die Anzahl der Systemdialoge zu minimieren, die dem Nutzer angezeigt werden, wenn eine Anwendung eng verwandte Berechtigungen anfordert.
Workflow zum Anfordern von Berechtigungen
Bevor Sie Laufzeitberechtigungen in Ihrer App deklarieren und anfordern, sollten Sie zuerst prüfen, ob dies für Ihre App erforderlich ist. Sie können in Ihrer App viele Anwendungsfälle erfüllen, z. B. Fotos aufnehmen, die Medienwiedergabe pausieren und relevante Werbung einblenden, ohne dass Berechtigungen erteilt werden müssen.
Wenn Sie zu dem Schluss kommen, dass Ihre App Laufzeitberechtigungen deklarieren und anfordern muss, führen Sie die folgenden Schritte aus:
- Deklariere in der Manifestdatei deiner App die Berechtigungen, die sie gegebenenfalls anfordern muss.
- Gestalten Sie die UX Ihrer App so, dass bestimmte Aktionen in Ihrer App mit bestimmten Laufzeitberechtigungen verknüpft sind. Teile den Nutzern mit, bei welchen Aktionen sie möglicherweise die Berechtigung für deine App erteilen müssen, auf private Nutzerdaten zuzugreifen.
- Warten Sie, bis der Nutzer die Aufgabe oder Aktion in Ihrer Anwendung aufruft, die Zugriff auf bestimmte private Nutzerdaten erfordert. 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 die von Ihrer App erforderliche Laufzeitberechtigung bereits gewährt hat. In diesem Fall kann Ihre Anwendung 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 und erläutere, warum der Nutzer eine bestimmte Laufzeitberechtigung erteilen muss. Wenn das System feststellt, dass deine App keine Begründung enthalten sollte, fahre direkt mit dem nächsten Schritt fort, ohne ein UI-Element anzuzeigen.
Wenn das System feststellt, dass deine App eine Begründung enthalten soll, präsentiere diese dem Nutzer in einem UI-Element. Erklären Sie dabei klar, auf welche Daten Ihre App zugreifen möchte und welche Vorteile die App dem Nutzer bieten kann, wenn er die Laufzeitberechtigung gewährt. 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 für eine Laufzeitberechtigung wie auf der Seite mit der Berechtigungsübersicht an.
Prüfen Sie die Antwort des Nutzers. Dabei spielt es keine Rolle, ob er die Laufzeitberechtigung gewährt oder verweigert.
Wenn der Nutzer Ihrer App die Berechtigung erteilt hat, können Sie auf die privaten Nutzerdaten zugreifen. Wenn der Nutzer stattdessen die Berechtigung verweigert hat, verringere die Nutzerfreundlichkeit der App ordnungsgemäß, sodass der Nutzer ohne die Informationen, die durch diese Berechtigung geschützt sind, Funktionen zur Verfügung stellen kann.
In Abbildung 1 sehen Sie den Workflow und eine Reihe von Entscheidungen, die mit diesem Prozess verknüpft sind:
Prüfen, 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(). Diese Methode gibt entweder PERMISSION_GRANTED oder PERMISSION_DENIED zurück, je nachdem, ob Ihre App die Berechtigung hat.
Erläutere, warum deine App die Berechtigung benötigt
Das Berechtigungsdialogfeld, das vom System angezeigt wird, wenn Sie requestPermissions() aufrufen, gibt an, welche Berechtigung Ihre App benötigt, aber keinen Grund dafür. In einigen Fällen kann der Nutzer diese Rätsel empfinden. Du solltest dem Nutzer erklären, warum deine App die Berechtigungen benötigt, bevor du requestPermissions() aufrufst.
Studien haben gezeigt, dass Nutzer mit Berechtigungsanfragen viel wohler sind, wenn sie wissen, warum die App sie benötigt, z. B. ob die Berechtigung zur Unterstützung einer Hauptfunktion der App oder zu Werbezwecken erforderlich ist. Wenn Sie also nur einen Bruchteil der API-Aufrufe verwenden, die unter eine Berechtigungsgruppe fallen, ist es hilfreich, explizit aufzulisten, welche dieser Berechtigungen Sie verwenden und warum. Wenn du beispielsweise nur den ungefähren Standort verwendest, teile dem Nutzer dies in der App-Beschreibung oder in Hilfeartikeln zu deiner App mit.
Unter bestimmten Umständen ist es auch hilfreich, Nutzer in Echtzeit über den Zugriff auf sensible Daten zu informieren. Wenn du beispielsweise auf die Kamera oder das Mikrofon zugreifst, solltest du den Nutzer darauf hinweisen, indem du irgendwo in deiner App oder in der Benachrichtigungsleiste (wenn die App im Hintergrund ausgeführt wird) darauf hinweisen, damit keine unabsichtlich Daten erhoben werden.
Wenn du eine Berechtigung anfordern musst, damit etwas in deiner App funktioniert, der Grund aber für den Nutzer nicht klar ist, solltest du dem Nutzer mitteilen, warum du besonders sensible Berechtigungen benötigst.
Wenn die Methode ContextCompat.checkSelfPermission() PERMISSION_DENIED zurückgibt, rufen Sie shouldShowRequestPermissionRationale() auf.
Wenn diese Methode true zurückgibt, wird dem Nutzer eine pädagogische UI angezeigt. Beschreiben Sie in dieser UI, warum das Feature, das der Nutzer aktivieren möchte, eine bestimmte Berechtigung benötigt.
Wenn deine App eine Berechtigung für den Standort, das Mikrofon oder die Kamera anfordert, solltest du erklären, warum deine App Zugriff auf diese Informationen benötigt.
Berechtigungen anfordern
Wenn der Nutzer eine UI mit Lerninhalten aufgerufen hat oder der Rückgabewert von shouldShowRequestPermissionRationale() angibt, dass keine UI für den Bildungsbereich angezeigt werden muss, fordern Sie die Berechtigung an. Nutzer sehen ein Dialogfeld mit 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. Dort kannst du dem System erlauben, den Berechtigungsanfragecode für dich zu verwalten. Da die Verwendung des RequestPermission-Vertrags Ihre Logik vereinfacht, wird dies nach Möglichkeit empfohlen. Bei Bedarf können Sie im Rahmen der Berechtigungsanfrage Anfragecode auch selbst verwalten und diesen Anfragecode in Ihre Callback-Logik für Berechtigungen aufnehmen.
System erlauben, den Berechtigungsanforderungscode zu verwalten
Damit das System den Anfragecode verwalten kann, der einer Berechtigungsanfrage zugeordnet ist, fügen Sie der Datei build.gradle Ihres 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. - Mit
RequestMultiplePermissionskönnen Sie mehrere Berechtigungen gleichzeitig anfordern.
Die folgenden Schritte zeigen, wie Sie den RequestPermission-Vertrag verwenden. Die Vorgehensweise ist für den RequestMultiplePermissions-Vertrag fast identisch.
Übergeben Sie in der Initialisierungslogik des Fragments oder Ihrer Aktivität eine Implementierung von
ActivityResultCallbackin einen Aufruf vonregisterForActivityResult(). MitActivityResultCallbackwird definiert, wie deine App die Antwort des Nutzers auf die Berechtigungsanfrage verarbeitet.Behalten Sie einen Verweis auf den Rückgabewert von
registerForActivityResult()bei, der vom TypActivityResultLauncherist.Wenn Sie das Dialogfeld für Systemberechtigungen bei Bedarf aufrufen möchten, rufen Sie die Methode
launch()für die Instanz vonActivityResultLauncherauf, die Sie im vorherigen Schritt gespeichert haben.Nach dem Aufruf von
launch()wird das Dialogfeld mit den Systemberechtigungen angezeigt. Wenn der Nutzer eine Auswahl trifft, ruft das System asynchron Ihre Implementierung vonActivityResultCallbackauf, die Sie im vorherigen Schritt definiert haben.Hinweis : Das Dialogfeld, das beim Aufrufen von
launch()angezeigt wird, kann von deiner App nicht angepasst werden. Um dem Nutzer mehr Informationen oder Kontext zur Verfügung zu stellen, ändere die UI deiner App, damit Nutzer besser verstehen, warum ein Feature deiner App eine bestimmte Berechtigung benötigt. Du kannst beispielsweise den Text in der Schaltfläche ändern, mit der die Funktion aktiviert wird.Außerdem verweist der Text im Dialogfeld für Systemberechtigungen auf die Berechtigungsgruppe, die mit der angeforderten Berechtigung verknüpft ist. Diese Berechtigungsgruppierung dient der Nutzerfreundlichkeit des Systems und Ihre App sollte sich nicht darauf verlassen, dass Berechtigungen innerhalb oder außerhalb einer bestimmten Berechtigungsgruppe liegen.
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.
}
});
Dieses Code-Snippet zeigt das empfohlene Verfahren zur Prüfung auf eine Berechtigung und zum 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);
}
Berechtigungsanfragecode selbst verwalten
Anstatt dem System die Verwaltung des Berechtigungsanforderungscodes zu überlassen, können Sie den Berechtigungsanfragecode auch selbst verwalten. Fügen Sie dazu den Anfragecode in einen Aufruf von requestPermissions() ein.
Das folgende Code-Snippet zeigt, wie eine Berechtigung mithilfe eines Anfragecodes angefordert wird:
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 deiner App auf. Das System übergibt die Nutzerantwort an das Berechtigungsdialogfeld sowie den von Ihnen definierten Anforderungscode, 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.
}
}
Berechtigungen zur Standortermittlung anfordern
Beachten Sie beim Anfordern von Berechtigungen zur Standortermittlung dieselben Best Practices wie für alle anderen Laufzeitberechtigungen. Ein wichtiger Unterschied bei den Berechtigungen zur Standortermittlung besteht darin, dass das System mehrere Berechtigungen in Bezug auf den Standort umfasst. Welche Berechtigungen Sie anfordern und wie Sie sie anfordern, hängt von den Standortanforderungen für den Anwendungsfall Ihrer App ab.
Vordergrundstandort
Wenn deine 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.
- Eine Funktion in einer Messaging-App ermöglicht es Nutzern, ihren aktuellen Standort mit einem anderen Nutzer zu teilen.
Ihre App verwendet die Standortermittlung im Vordergrund, 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, zeigt das System eine dauerhafte Benachrichtigung an, um die Aufmerksamkeit des Nutzers zu wecken. Ihre 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 seines Geräts ausschaltet.
Unter Android 10 (API-Level 29) und höher musst du
locationals Dienst im Vordergrund deklarieren, wie im folgenden Code-Snippet gezeigt. In früheren Android-Versionen empfiehlt es sich, diesen Typ von Dienst 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 erklären, dass die Standortermittlung im Vordergrund erforderlich ist, 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>
Standort 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:
- Innerhalb einer App zur Standortfreigabe für Familien können Nutzer ihren Standort kontinuierlich mit Familienmitgliedern teilen.
- Innerhalb einer IoT-App können Nutzer ihre Smart-Home-Geräte so konfigurieren, dass sie sich ausschalten, wenn der Nutzer das Zuhause verlässt, und wieder einschalten, wenn der Nutzer nach Hause kommt.
Ihre App verwendet die Standortermittlung im Hintergrund, wenn sie unter einer anderen als der unter Position im Vordergrund beschriebenen Situation auf den aktuellen Standort des Geräts zugreift. Die Genauigkeit der Standortermittlung im Hintergrund ist mit der Genauigkeit der Standortermittlung im Vordergrund identisch. Sie hängt von den Berechtigungen zur Standortermittlung ab, die von Ihrer App deklariert werden.
Unter Android 10 (API-Level 29) und höher musst du im Manifest deiner App die Berechtigung ACCESS_BACKGROUND_LOCATION deklarieren, um während der Laufzeit Zugriff auf die Standortermittlung im Hintergrund anzufordern. Wenn Ihre App in früheren Android-Versionen Zugriff auf die Standortermittlung im Vordergrund erhält, erhält sie automatisch auch Zugriff auf die Standortermittlung im Hintergrund.
<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 abgelehnten Berechtigungen
Wenn der Nutzer eine Berechtigungsanfrage ablehnt, sollte deine App Nutzern dabei helfen, die Auswirkungen der Ablehnung der Berechtigung zu verstehen. Insbesondere sollte deine App Nutzer auf Funktionen hinweisen, die aufgrund der fehlenden Berechtigung nicht funktionieren. Beachten Sie dabei die folgenden Best Practices:
Die Aufmerksamkeit des Nutzers lenken. Hebe einen bestimmten Teil der Benutzeroberfläche deiner App hervor, für den die Funktionalität eingeschränkt ist, weil deine App nicht die erforderliche Berechtigung hat. Sie könnten beispielsweise Folgendes tun:
- Eine Nachricht anzeigen, in der die Ergebnisse oder Daten des Elements erscheinen würden.
- Zeigen Sie eine andere Schaltfläche an, die ein Fehlersymbol und eine Fehlerfarbe enthält.
Seien Sie konkret. Keine allgemeine Nachricht anzeigen. Mach stattdessen deutlich, welche Funktionen nicht verfügbar sind, da deine App nicht die erforderliche Berechtigung hat.
Die Benutzeroberfläche darf nicht blockiert werden. Mit anderen Worten: Zeigen Sie keine Vollbildwarnung an, die Nutzer daran hindert, Ihre Anwendung weiter zu verwenden.
Gleichzeitig sollte Ihre App die Entscheidung des Nutzers respektieren, eine Berechtigung abzulehnen. Wenn der Nutzer ab Android 11 (API-Level 30) während der Installation der App auf einem Gerät mehrmals auf Ablehnen für eine bestimmte Berechtigung tippt, wird das Dialogfeld für Systemberechtigungen nicht angezeigt, wenn die App diese Berechtigung noch einmal anfordert. Die Handlung des Nutzers impliziert „Nicht mehr fragen“. In früheren Versionen wurde Nutzern das Dialogfeld „Systemberechtigungen“ jedes Mal angezeigt, wenn Ihre Anwendung 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 um Berechtigungen zu bitten, wenn sie Zugriff auf eine bestimmte Funktion benötigen. Andernfalls könnten Sie unbeabsichtigt die Möglichkeit verlieren, Berechtigungen noch einmal anzufordern.
In bestimmten Situationen kann die Berechtigung automatisch verweigert werden, ohne dass der Nutzer Maßnahmen ergreift. Eine Berechtigung kann auch automatisch erteilt 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 der App diese Berechtigung noch gewährt wurde.
Informationen zum optimalen Anwenden 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 Debugging- und Testzwecken herauszufinden, ob einer Anwendung 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, werden von USER_SET gemeldet.
Berechtigungen, die dauerhaft durch zweimaliges Auswählen von Ablehnen dauerhaft abgelehnt wurden, werden von USER_FIXED gekennzeichnet.
Damit Tester das Anfragedialogfeld während des Tests sehen, setzen Sie diese Flags zurück, nachdem Sie das Debugging Ihrer Anwendung abgeschlossen haben. 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 für die permissions API.
Einmalige Berechtigungen
Ab Android 11 (API-Level 30) wird jedes Mal, wenn deine App eine Berechtigung in Bezug auf Standort, Mikrofon oder Kamera anfordert, im Dialogfeld für Nutzerberechtigungen die Option Nur dieses Mal angezeigt (siehe Abbildung 2). Wenn der Nutzer diese Option im Dialogfeld auswählt, erhält Ihre App eine temporäre einmalige Berechtigung.
Ihre Anwendung kann dann für einen Zeitraum, der vom Verhalten Ihrer Anwendung und den Aktionen des Nutzers abhängt, auf die zugehörigen Daten zugreifen:
- Solange die Aktivitäten Ihrer App sichtbar sind, kann sie auf die Daten zugreifen.
- Wenn der Nutzer Ihre App in den Hintergrund sendet, kann sie noch für kurze Zeit auf die Daten zugreifen.
- Wenn Sie einen Dienst im Vordergrund starten, während die Aktivität sichtbar ist, und der Nutzer Ihre App dann in den Hintergrund verschiebt, kann Ihre App weiterhin auf die Daten zugreifen, bis der Dienst im Vordergrund beendet wird.
Der 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. Wenn der Nutzer die einmalige Berechtigung Ihrer App widerruft, wird der App-Prozess wie bei jeder anderen Berechtigung beendet.
Wenn der Nutzer die App das nächste Mal öffnet und ein Feature in Ihrer 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 Standardstatus „Abgelehnt“ 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 sie nicht mehr benötigt. Wenn du deine App aktualisierst, führe diesen Schritt aus, damit Nutzer besser verstehen, warum deine App weiterhin bestimmte Berechtigungen anfordert. Dieses Wissen trägt dazu bei, das Vertrauen der Nutzer in Ihre App zu stärken.
Übergeben Sie den Namen dieser Berechtigung an revokeSelfPermissionOnKill(), um den Zugriff auf eine Laufzeitberechtigung zu entfernen.
Wenn Sie den Zugriff auf eine Gruppe von Laufzeitberechtigungen gleichzeitig entfernen möchten, übergeben Sie eine Sammlung von Berechtigungsnamen an revokeSelfPermissionsOnKill().
Das Entfernen von Berechtigungen erfolgt asynchron und beendet alle Prozesse, die mit der UID Ihrer App verknüpft sind.
Damit das System den Zugriff Ihrer Anwendung auf die Berechtigungen entfernen kann, müssen alle mit Ihrer Anwendung verbundenen Prozesse beendet werden. Wenn Sie die API aufrufen, ermittelt das System, wann diese Prozesse sicher beendet werden können. Normalerweise wartet das System, bis Ihre Anwendung längere Zeit im Hintergrund statt im Vordergrund ausgeführt wird.
Wenn Sie den Nutzer darüber informieren möchten, dass Ihre Anwendung keinen Zugriff mehr auf bestimmte Laufzeitberechtigungen benötigt, zeigen Sie beim nächsten Start der Anwendung ein Dialogfeld an. Dieses Dialogfeld kann eine Liste der Berechtigungen enthalten.
Berechtigungen für nicht verwendete Apps automatisch zurücksetzen
Wenn Ihre App auf Android 11 (API-Level 30) oder höher ausgerichtet ist und einige Monate nicht verwendet wird, schützt das System die Nutzerdaten, indem es die sensiblen Laufzeitberechtigungen, die der Nutzer Ihrer App erteilt hat, automatisch zurücksetzt. Weitere Informationen finden Sie im Leitfaden zum Ruhezustand von Apps.
Anfrage, bei Bedarf zum Standard-Handler zu werden
Einige Apps benötigen Zugriff auf vertrauliche Nutzerinformationen aus Anruflisten und SMS-Nachrichten. Wenn Sie die Berechtigungen für Anrufprotokolle 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 die Option -g für den Befehl adb shell install, wie im folgenden Code-Snippet gezeigt:
adb shell install -g PATH_TO_APK_FILE
Zusätzliche Ressourcen
Weitere Informationen zu Berechtigungen finden Sie in diesen Artikeln:
Weitere Informationen zum Anfordern von Berechtigungen finden Sie in den Berechtigungsbeispielen.
Sie können auch dieses Codelab mit Best Practices zum Datenschutz durcharbeiten.