Jede Android-App wird in einer Sandbox mit beschrä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 ermöglicht. 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 diesem Leitfaden.
Wenn Sie keine gefährlichen Berechtigungen deklarieren oder Ihre 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 Sie müssen keine der verbleibenden Schritte auf dieser Seite ausführen.
Grundprinzipien
Die Grundprinzipien für das Anfordern von Berechtigungen zur Laufzeit lauten wie folgt:
- Sie können eine Berechtigung im Kontext anfordern, wenn der Nutzer mit der Funktion interagiert, für die sie erforderlich ist.
- Nutzer nicht blockieren Bieten Sie Nutzern immer die Möglichkeit, einen UI-Vorgang abbrechen zu können, in dem beispielsweise erläutert wird, warum Berechtigungen angefordert werden.
- Wenn Nutzer eine Berechtigung, die für eine Funktion erforderlich ist, ablehnen oder widerrufen, ermöglichen Sie Ihren Nutzern durch graduelle Fehlertoleranz, Ihre App weiterhin zu verwenden. Möglicherweise können Sie die Funktion deaktivieren, für die Sie die Berechtigung oder die entsprechenden Daten benötigen.
- Gehen Sie nicht von einem bestimmten Systemverhalten aus. Angenommen werden darf beispielsweise nicht, dass Berechtigungen in derselben Berechtigungsgruppe enthalten sind. Eine Berechtigungsgruppe hilft dem System lediglich, die Anzahl der Systemdialogfelder zu minimieren, die dem Nutzer angezeigt werden, wenn eine App eng miteinander verbundene Berechtigungen anfordert.
Workflow zum Anfordern von Berechtigungen
Bevor Sie Laufzeitberechtigungen in Ihrer App deklarieren und anfordern, sollten Sie prüfen, 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 schalten, ohne Berechtigungen deklarieren zu müssen.
Wenn Sie zu dem Schluss kommen, dass Ihre App Laufzeitberechtigungen erklären und anfordern muss, führen Sie die folgenden Schritte aus:
- Deklarieren Sie in der Manifestdatei Ihrer App die Berechtigungen, die Ihre App möglicherweise anfordern muss.
- Gestalten Sie die UX Ihrer App so, dass bestimmte Aktionen in Ihrer App mit bestimmten Laufzeitberechtigungen verknüpft sind. Informieren Sie die Nutzer darüber, für welche Aktionen sie Ihrer App möglicherweise die Berechtigung zum Zugriff auf private Nutzerdaten erteilen müssen.
- Warten Sie, bis der Nutzer die Aufgabe oder Aktion in Ihrer App ausführt, für die Zugriff auf bestimmte personenbezogene Nutzerdaten erforderlich ist. Zu diesem Zeitpunkt kann Ihre App die Laufzeitberechtigung anfordern, die für den Zugriff auf diese Daten erforderlich ist.
Prüfen Sie, ob der Nutzer bereits die Laufzeitberechtigung erteilt hat, die Ihre App benötigt. 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.
Prüfen Sie, ob Ihre App Nutzern eine Begründung anzeigen sollte, warum Ihre App eine bestimmte Laufzeitberechtigung benötigt. Wenn das System feststellt, dass Ihre App keine Begründung enthalten sollte, fahren Sie direkt mit dem nächsten Schritt fort, ohne ein UI-Element anzuzeigen.
Wenn das System jedoch feststellt, dass Ihre App eine Begründung enthalten sollte, müssen Sie dem Nutzer eine Begründung in einem UI-Element präsentieren. 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 erteilt. Nachdem der Nutzer die Begründung akzeptiert hat, fahren Sie 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 sie auf der Übersichtsseite für Berechtigungen zu sehen ist.
Prüfen Sie die Antwort des Nutzers, um festzustellen, ob er die Laufzeitberechtigung erteilt oder abgelehnt hat.
Wenn der Nutzer Ihrer App die Berechtigung erteilt hat, können Sie auf die privaten Nutzerdaten zugreifen. Wenn der Nutzer die Berechtigung stattdessen abgelehnt hat, reduzieren Sie die Funktionalität Ihrer App, damit der Nutzer Funktionen nutzen kann, ohne dass die durch diese Berechtigung geschützten Informationen verwendet werden.
Abbildung 1 zeigt den Workflow und die damit verbundenen Entscheidungen:
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äutern Sie, warum Ihre 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 das für Nutzer verwirrend sein. Es ist empfehlenswert, dem Nutzer zu erklären, warum Ihre App die Berechtigungen benötigt, bevor Sie requestPermissions() aufrufen.
Studien haben gezeigt, dass Nutzer Berechtigungsanfragen viel eher akzeptieren, wenn sie wissen, warum die App sie benötigt. So kann es beispielsweise sein, dass die Berechtigung für eine Hauptfunktion der App oder für Werbung erforderlich ist. Wenn Sie also nur einen Teil der API-Aufrufe verwenden, die zu einer Berechtigungsgruppe gehören, sollten Sie explizit angeben, welche dieser Berechtigungen Sie verwenden und warum. Wenn Sie beispielsweise nur die grobe Standortermittlung verwenden, informieren Sie die Nutzer in der App-Beschreibung oder in Hilfeartikeln zu Ihrer App darüber.
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, aber der Grund für den Nutzer nicht klar ist, solltest du dem Nutzer mitteilen, warum du besonders sensible Berechtigungen benötigst.
Wenn die ContextCompat.checkSelfPermission()-Methode PERMISSION_DENIED zurückgibt, rufe shouldShowRequestPermissionRationale() auf.
Wenn diese Methode true zurückgibt, zeigen Sie dem Nutzer eine informative Benutzeroberfläche an. Beschreiben Sie in dieser Benutzeroberfläche, warum für die Funktion, die der Nutzer aktivieren möchte, eine bestimmte Berechtigung erforderlich ist.
Wenn Ihre App eine Berechtigung für die Standortermittlung, das Mikrofon oder die Kamera anfordert, sollten Sie außerdem erläutern, warum Ihre App auf diese Informationen zugreifen muss.
Berechtigungen anfordern
Nachdem 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 für Systemberechtigungen, in dem sie auswählen können, ob sie Ihrer App eine bestimmte Berechtigung erteilen möchten.
Verwenden Sie dazu den Vertrag RequestPermission, der in einer AndroidX-Bibliothek enthalten ist. Hier können Sie dem System erlauben, den Code für die Berechtigungsanfrage für Sie zu verwalten. Da die Verwendung des RequestPermission-Vertrags die Logik vereinfacht, wird diese Lösung nach Möglichkeit empfohlen. Bei Bedarf können Sie jedoch auch einen Anfragecode selbst verwalten, der Teil der Berechtigungsanfrage ist, und diesen Anfragecode in Ihre Berechtigungs-Callback-Logik einbinden.
Dem System erlauben, den Code für die Berechtigungsanfrage 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:
- Wenn Sie eine einzelne Berechtigung anfordern möchten, verwenden Sie
RequestPermission. - Wenn Sie mehrere Berechtigungen gleichzeitig anfordern möchten, verwenden Sie
RequestMultiplePermissions.
In den folgenden Schritten wird gezeigt, wie Sie den RequestPermission-Vertrag verwenden. Der Vorgang ist für den RequestMultiplePermissions-Vertrag nahezu identisch.
Übergeben Sie in der Initialisierungslogik des Fragments oder Ihrer Aktivität eine Implementierung von
ActivityResultCallbackin einen Aufruf vonregisterForActivityResult(). Mit derActivityResultCallbackwird festgelegt, wie Ihre App mit der Antwort des Nutzers auf die Berechtigungsanfrage umgeht.Behalten Sie einen Verweis auf den Rückgabewert von
registerForActivityResult(), der vom TypActivityResultLauncherist.Wenn Sie das Dialogfeld für die Systemberechtigungen bei Bedarf anzeigen lassen möchten, rufen Sie die Methode
launch()auf der Instanz vonActivityResultLauncherauf, die Sie im vorherigen Schritt gespeichert haben.Nach dem Aufruf von
launch()wird das Dialogfeld für die Systemberechtigungen angezeigt. Wenn der Nutzer eine Auswahl trifft, ruft das System asynchron Ihre Implementierung vonActivityResultCallbackauf, die Sie im vorherigen Schritt definiert haben.Hinweis : Ihre App kann das Dialogfeld, das beim Aufrufen von
launch()angezeigt wird, nicht anpassen. Um den Nutzern mehr Informationen oder Kontext zu bieten, ändern Sie die Benutzeroberfläche Ihrer App so, dass sie leichter verstehen können, warum eine Funktion in Ihrer App eine bestimmte Berechtigung benötigt. Sie können beispielsweise den Text auf der Schaltfläche ändern, mit der die Funktion aktiviert wird.Außerdem bezieht sich der Text im Dialogfeld für die Systemberechtigung auf die Berechtigungsgruppe, die mit der von Ihnen angeforderten Berechtigung verknüpft ist. Diese Berechtigungsgruppierung wurde für die Nutzerfreundlichkeit des Systems entwickelt. Ihre App sollte nicht davon abhängen, ob Berechtigungen zu einer bestimmten Berechtigungsgruppe gehören oder nicht.
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 veranschaulicht den empfohlenen Prozess zum Prüfen einer 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
Sie können den Code für die Berechtigungsanfrage vom System verwalten lassen oder selbst verwalten. Fügen Sie dazu den Anfragecode in einen Aufruf von requestPermissions() ein.
Das folgende Code-Snippet zeigt, wie eine Berechtigung mit einem Anfragecode 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 für die Systemberechtigungen geantwortet hat, ruft das System die Implementierung von onRequestPermissionsResult() Ihrer 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 Standortberechtigungen besteht darin, dass das System mehrere standortbezogene Berechtigungen umfasst. Welche Berechtigungen Sie anfordern und wie Sie sie anfordern, hängt von den Standortanforderungen für den Anwendungsfall Ihrer App ab.
Standortermittlung im Vordergrund
Wenn Ihre App eine Funktion enthält, die Standortinformationen nur einmal oder für einen bestimmten Zeitraum freigibt oder empfängt, ist für diese Funktion der Zugriff auf die Standortermittlung im Vordergrund erforderlich. Beispiele:
- Innerhalb einer Navigations-App können Nutzer mithilfe einer Funktion eine detaillierte Routenführung abrufen.
- In 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:
- Eine Aktivität, die zu deiner App gehört, ist sichtbar.
Ihre App führt einen Dienst im Vordergrund aus. Wenn ein Dienst im Vordergrund ausgeführt wird, wird der Nutzer durch eine dauerhafte Benachrichtigung darauf aufmerksam gemacht. Ihre App behält den Zugriff, wenn sie im Hintergrund ausgeführt wird, z. B. wenn der Nutzer die Startbildschirmtaste auf seinem Gerät drückt oder das Display ausschaltet.
Unter Android 10 (API-Level 29) und höher müssen Sie einen Typ für Dienste im Vordergrund von
locationdeklarieren, wie im folgenden Code-Snippet dargestellt. Bei früheren Android-Versionen wird empfohlen, diesen Diensttyp 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 Ihre App die Standortermittlung im Vordergrund benötigt, wenn sie entweder die Berechtigung ACCESS_COARSE_LOCATION oder die Berechtigung ACCESS_FINE_LOCATION anfordert, wie im folgenden Snippet dargestellt:
<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 in der App den Standort ständig mit anderen Nutzern teilt oder die Geofencing API verwendet. Beispiele:
- In einer App zur Standortfreigabe für Familien können Nutzer ihren Standort kontinuierlich mit Familienmitgliedern teilen.
- Mit einer Funktion in einer IoT-App können Nutzer ihre Haushaltsgeräte so konfigurieren, dass sie sich ausschalten, wenn der Nutzer das Haus verlässt, und wieder einschalten, wenn er nach Hause zurückkehrt.
Ihre App verwendet die Standortermittlung im Hintergrund, wenn sie unter einer anderen als der im Abschnitt Position im Vordergrund beschriebenen Situation auf den aktuellen Standort des Geräts zugreift. Die Genauigkeit der Standortermittlung im Hintergrund entspricht der Genauigkeit der Standortermittlung im Vordergrund, die von den von Ihrer App angegebenen Berechtigungen für die Standortermittlung abhängt.
Unter Android 10 (API-Level 29) und höher müssen Sie die Berechtigung ACCESS_BACKGROUND_LOCATION im Manifest Ihrer App deklarieren, um zur Laufzeit Zugriff auf die Standortermittlung im Hintergrund anzufordern. In früheren Android-Versionen erhält Ihre App, wenn sie den Zugriff auf den Standort im Vordergrund erhält, automatisch auch den Zugriff auf den Standort 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 der Ablehnung von Berechtigungen
Wenn der Nutzer eine Berechtigungsanfrage ablehnt, sollte Ihre App ihm helfen zu verstehen, welche Auswirkungen die Ablehnung der Berechtigung hat. Insbesondere sollten Nutzer in Ihrer App auf die Funktionen hingewiesen werden, die aufgrund der fehlenden Berechtigung nicht funktionieren. Beachten Sie dabei die folgenden Best Practices:
Lenken Sie die Aufmerksamkeit der Nutzer. Heben Sie einen bestimmten Teil der Benutzeroberfläche Ihrer App hervor, bei dem die Funktionalität eingeschränkt ist, weil Ihre App nicht die erforderliche Berechtigung hat. Beispiele für mögliche Maßnahmen:
- Eine Nachricht anzeigen, in der die Ergebnisse oder Daten des Elements erscheinen würden.
- Eine andere Schaltfläche mit einem Fehlersymbol und einer Fehlerfarbe anzeigen
Machen Sie möglichst genaue Angaben. Keine allgemeine Nachricht anzeigen. Geben Sie stattdessen an, welche Funktionen nicht verfügbar sind, weil Ihre App nicht die erforderliche Berechtigung hat.
Die Benutzeroberfläche darf nicht blockiert werden. Das bedeutet, dass Sie keine Vollbildwarnung anzeigen dürfen, die Nutzer daran hindert, Ihre App weiter zu verwenden.
Gleichzeitig sollte Ihre App die Entscheidung des Nutzers respektieren, eine Berechtigung abzulehnen. Ab Android 11 (API-Level 30) wird Nutzern, die während der Lebensdauer der Installation Ihrer App auf einem Gerät mehrmals auf Ablehnen für eine bestimmte Berechtigung tippen, das Dialogfeld für Systemberechtigungen nicht angezeigt, wenn Ihre App diese Berechtigung noch einmal anfordert. Die Aktion des Nutzers bedeutet „Nicht mehr fragen“. In früheren Versionen wurde Nutzern jedes Mal, wenn Ihre App eine Berechtigung anforderte, das Dialogfeld für Systemberechtigungen angezeigt, es sei denn, sie hatten zuvor ein Kästchen oder eine Option für „Nicht noch einmal fragen“ angeklickt.
Wenn ein Nutzer eine Berechtigungsanfrage mehrmals 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önnen Sie die Berechtigungen möglicherweise nicht noch einmal anfordern.
In bestimmten Situationen wird die Berechtigung möglicherweise automatisch abgelehnt, ohne dass der Nutzer etwas unternehmen muss. 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 der App diese Berechtigung noch gewährt wurde.
Informationen zum Erzielen der besten Benutzererfahrung bei der Abfrage von App-Berechtigungen finden Sie unter Best Practices für App-Berechtigungen.
Ablehnungsstatus beim Testen und Beheben von Fehlern prüfen
Mit dem folgenden Befehl können Sie prüfen, ob einer App dauerhaft Berechtigungen verweigert wurden (zum Debuggen und Testen):
adb shell dumpsys package PACKAGE_NAME
Dabei ist PACKAGE_NAME der Name des zu prüfenden Pakets.
Die Ausgabe des Befehls enthält Abschnitte, die so aussehen:
... 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 vom Nutzer einmal abgelehnt wurden, sind mit USER_SET gekennzeichnet.
Berechtigungen, die dauerhaft abgelehnt wurden, indem Sie zweimal Ablehnen ausgewählt haben, werden mit USER_FIXED gekennzeichnet.
Damit Tester das Dialogfeld für die Anfrage während des Tests sehen, setzen Sie diese Flags zurück, wenn Sie mit dem Debuggen Ihrer App fertig sind. Verwenden Sie dazu den 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 Android-App-Berechtigungen finden Sie auf der Referenzseite der Permissions API.
Einmalige Berechtigungen
Ab Android 11 (API-Ebene 30) enthält das Berechtigungsdialogfeld für Nutzer, in dem Ihre App eine Berechtigung für die Standortermittlung, das Mikrofon oder die Kamera anfordert, die Option Nur dieses Mal, wie in Abbildung 2 dargestellt. Wenn der Nutzer diese Option im Dialogfeld auswählt, wird Ihrer App eine vorübergehende einmalige Berechtigung gewährt.
Ihre App kann dann für einen Zeitraum auf die zugehörigen Daten zugreifen, der vom Verhalten Ihrer App und den Aktionen der Nutzer abhängt:
- Solange die Aktivitäten Ihrer App sichtbar sind, kann Ihre App auf die Daten zugreifen.
- Wenn der Nutzer Ihre App in den Hintergrund schickt, kann Ihre App 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.
App-Prozess wird beendet, wenn 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 Ihrer App beendet, wenn der Nutzer die einmalige Berechtigung Ihrer App widerruft.
Wenn der Nutzer Ihre App das nächste Mal öffnet und eine Funktion in Ihrer App Zugriff auf die Standortermittlung, 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. Führen Sie diesen Schritt aus, wenn Sie Ihre App aktualisieren, damit Nutzer besser nachvollziehen können, warum Ihre App weiterhin bestimmte Berechtigungen anfordert. Dieses Wissen stärkt das Vertrauen der Nutzer in Ihre App.
Wenn Sie den Zugriff auf eine Laufzeitberechtigung entfernen möchten, geben Sie den Namen dieser Berechtigung an revokeSelfPermissionOnKill() weiter.
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 App auf die Berechtigungen entfernen kann, müssen alle mit Ihrer App verknüpften 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 App über einen längeren Zeitraum 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 lang nicht verwendet wird, schützt das System die Nutzerdaten, indem die sensiblen Laufzeitberechtigungen, die der Nutzer Ihrer App gewährt hat, automatisch zurückgesetzt werden. Weitere Informationen finden Sie im Leitfaden zum App-Ruhezustand.
Bei Bedarf den Standard-Handler anfordern
Einige Apps benötigen Zugriff auf vertrauliche Nutzerdaten im Zusammenhang mit Anruflisten und SMS. 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-Handlersn, einschließlich einer Anleitung zum Einblenden einer Aufforderung für Standard-Handlers, finden Sie in diesem Leitfaden zu Berechtigungen, die nur in Standard-Handlersn 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
Weitere Informationen
Weitere Informationen zu Berechtigungen finden Sie in diesen Artikeln:
Weitere Informationen zum Anfordern von Berechtigungen finden Sie in den Beispielen für Berechtigungen.
Sie können auch dieses Codelab mit Best Practices zum Datenschutz durcharbeiten.