Jede Android-App wird in einer Sandbox mit eingeschränktem Zugriff ausgeführt. Wenn Ihre App Ressourcen oder Informationen außerhalb der eigenen Sandbox zu nutzen, können Sie eine Laufzeit Berechtigung und richten Sie eine Berechtigungsanfrage das diesen Zugriff ermöglicht. Diese Schritte gehören zum Workflow zur Verwendung Berechtigungen
Wenn Sie eine gefährliche Website Berechtigungen deine App auf einem Gerät mit Android 6.0 (API-Level 23) installiert ist oder höher ist, müssen Sie die gefährlichen Berechtigungen zur Laufzeit anfordern, indem Sie in diesem Leitfaden.
Wenn Sie keine gefährlichen Berechtigungen deklarieren oder Ihre App auf einem auf einem Gerät mit Android 5.1 (API-Level 22) oder niedriger, automatisch gewährt und Sie müssen die verbleibenden Schritte nicht durchführen. auf dieser Seite.
Grundprinzipien
Die Grundprinzipien für das Anfordern von Berechtigungen zur Laufzeit lauten wie folgt:
- Fragen Sie im Kontext nach einer Berechtigung, wenn der Nutzer beginnt, mit dem die dies erfordert.
- Nutzer nicht blockieren Immer die Option zum Kündigen einer pädagogischen Benutzeroberfläche anbieten wie 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, Ihre App beeinträchtigen, sodass der Nutzer sie weiterhin verwenden kann, z. B. Deaktivieren der Funktion, für die die Berechtigung erforderlich ist
- Gehen Sie nicht von einem Systemverhalten aus. Gehen Sie beispielsweise nicht davon aus, dass Berechtigungen derselben Berechtigungsgruppe angehören. Eine Berechtigungsgruppe hilft lediglich System die Anzahl der Systemdialoge, die dem Nutzer angezeigt werden, wenn er eine App eng verwandte Berechtigungen anfordert.
Workflow zum Anfordern von Berechtigungen
Bevor Sie Laufzeitberechtigungen in Ihrer App deklarieren und anfordern, sollten Sie dies prüfen. ob Ihre App dies tun muss. Sie können Für viele Anwendungsfälle in Ihrer App, z. B. zum Aufnehmen von Fotos, zum Pausieren von Medien relevante Anzeigen wiedergegeben werden, ohne Berechtigungen.
Wenn Sie zu dem Schluss kommen, dass Ihre App Laufzeitberechtigungen deklarieren und anfordern muss, führen Sie diese Schritte aus:
- Deklarieren Sie in der Manifestdatei Ihrer App die Berechtigungen, die deine App möglicherweise benötigt,
- Gestalten Sie die UX Ihrer App so, dass bestimmte Aktionen in Ihrer App mit Laufzeitberechtigungen. Nutzer darüber informieren, welche Aktionen sie möglicherweise erfordern um Ihrer App die Berechtigung zu erteilen, auf private Nutzerdaten zuzugreifen.
- Warten Sie, bis der Nutzer die Aufgabe oder Aktion in Ihrer App aufgerufen hat. für die der Zugriff auf bestimmte private Nutzerdaten erforderlich ist. Dann kann Ihre App Fordern Sie die Laufzeitberechtigung an, die für den Zugriff auf diese Daten erforderlich ist.
Prüfen, ob der Nutzer die Laufzeit bereits gewährt hat Berechtigung, die deine App benötigt. In diesem Fall kann Ihre App auf die privaten Nutzerdaten. Sollte dies nicht der Fall sein, fahren Sie mit dem nächsten Schritt fort.
Sie müssen jedes Mal prüfen, ob Sie über eine Berechtigung verfügen, wenn Sie eine Vorgang ausführen, für den diese Berechtigung erforderlich ist.
Überprüfe, ob deine App dem Nutzer eine Begründung liefern soll. wird erläutert, warum der Nutzer in Ihrer App eine bestimmte Laufzeitberechtigung erteilen muss. Wenn das System feststellt, dass deine App keine Begründung enthalten sollte, fahre mit der ohne ein UI-Element anzuzeigen.
Wenn das System jedoch feststellt, dass Ihre App eine Begründung enthalten sollte, Sie präsentieren dem Nutzer die Begründung in einem UI-Element. In dieser Begründung Erklären Sie klar, auf welche Daten Ihre App zugreifen möchte und welche Vorteile diese bietet. die die App dem Nutzer bereitstellen kann, wenn er die Laufzeitberechtigung gewährt. Nachher bestätigt der Nutzer die Begründung, fahre mit dem nächsten Schritt fort.
Laufzeitberechtigung anfordern, die Ihre App benötigt auf die privaten Nutzerdaten zugreifen. Das System zeigt eine Laufzeit Berechtigungsaufforderung, wie z. B. in der Berechtigungsübersicht .
Prüfen Sie die Antwort des Nutzers. Dabei spielt es keine Rolle, ob er den Zugriff auf Laufzeitberechtigung.
Wenn der Nutzer Ihrer App die Berechtigung erteilt hat, können Sie auf den privaten Nutzerdaten. Wenn der Nutzer stattdessen die Berechtigung abgelehnt hat, schränken Sie Ihre App-Erfahrung und bietet dem Nutzer Funktionen. ohne die Informationen, die durch diese Genehmigung geschützt sind.
Abbildung 1 zeigt den Workflow und die damit verbundenen Entscheidungen. Prozess:
<ph type="x-smartling-placeholder">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 gewährt hat, geben Sie
diese Berechtigung in das
ContextCompat.checkSelfPermission()
. Diese Methode gibt entweder
PERMISSION_GRANTED
oder PERMISSION_DENIED
, je nachdem, ob deine App die entsprechende Berechtigung hat.
Erläutere, warum deine App die Berechtigung benötigt
Das Berechtigungsdialogfeld, das beim Aufruf angezeigt wird
requestPermissions()
gibt an, welche Berechtigung deine App benötigt, aber nicht angegeben
warum. In einigen Fällen kann der Nutzer diese Rätsel empfinden. Es empfiehlt sich,
Erkläre dem Nutzer, warum deine App die Berechtigungen benötigt, bevor du anrufst
requestPermissions()
Studien haben gezeigt, dass Nutzer mit Berechtigungsanfragen viel wohler sind, wenn wissen sie, warum die App sie braucht, z. B. ob die Berechtigung erforderlich ist, die eine Hauptfunktion der App unterstützen oder zu Werbezwecken dienen. Wenn Sie also nur einen Bruchteil der API-Aufrufe verwendet, die zu einer Berechtigungsgruppe gehören, hilft es, explizit aufzulisten, welche dieser Berechtigungen Sie verwenden und warum. Für Wenn Sie beispielsweise nur den ungefähren Standort verwenden, teilen Sie dies dem Nutzer in Ihrem in der App-Beschreibung oder in Hilfeartikeln zu Ihrer App.
Unter bestimmten Umständen ist es auch hilfreich, Nutzer über in Echtzeit auf sensible Daten zugreifen können. Wenn Sie zum Beispiel auf das Kamera oder Mikrofon verwenden, empfiehlt es sich, den Nutzer mit einem Benachrichtigungssymbol irgendwo in der App oder in der Benachrichtigungsleiste (wenn das im Hintergrund ausgeführt wird, sodass es nicht so aussieht, heimlich Daten sammeln.
Wenn Sie eine Berechtigung anfordern müssen, um etwas in Ihrer App zu erstellen aber der Grund ist für den Nutzer nicht klar, und wissen, warum Sie sensible Berechtigungen benötigen.
Wenn die Methode ContextCompat.checkSelfPermission()
PERMISSION_DENIED
zurückgibt,
rufen Sie shouldShowRequestPermissionRationale()
an.
Wenn diese Methode true
zurückgibt, wird dem Nutzer eine pädagogische UI angezeigt. In dieser UI
beschreiben, warum die Funktion, die Nutzende aktivieren möchten, eine bestimmte
Berechtigung.
Wenn Ihre App eine Berechtigung für Standort, Mikrofon, oder eine Kamera haben, sollten Sie erklären, warum Ihre App Zugriff auf diese Informationen.
Berechtigungen anfordern
Nachdem der Nutzer eine pädagogische Benutzeroberfläche aufgerufen hat oder der Rückgabewert eines
shouldShowRequestPermissionRationale()
gibt an, dass Sie keine
in einer Bildungseinrichtung, fordern Sie die Berechtigung an. Nutzer sehen ein System,
Berechtigungsdialogfeld, in dem sie auswählen können, ob sie einem bestimmten
Berechtigung für deine App.
Verwenden Sie dazu den RequestPermission
Vertrag, der in einer AndroidX-Bibliothek enthalten ist, mit dem das System
den Berechtigungsanfragecode für Sie. Weil
Die Verwendung des RequestPermission
-Vertrags vereinfacht die Logik. Es wird empfohlen,
wenn möglich. Bei Bedarf können Sie aber auch einen Anforderungscode verwalten.
Sie selbst im Rahmen der Berechtigungsanfrage
und fügen Sie diesen Anforderungscode in Ihre Berechtigungs-Callback-Logik ein.
System erlauben, den Berechtigungsanforderungscode zu verwalten
Damit das System den Anforderungscode verwalten kann, der mit einer
Berechtigungsanfrage stellen, fügen Sie Abhängigkeiten von den folgenden Bibliotheken in Ihrem
build.gradle
-Moduls des Moduls:
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:
- Um eine einzelne Berechtigung anzufordern, verwenden Sie
RequestPermission
- Um mehrere Berechtigungen gleichzeitig anzufordern, verwenden Sie
RequestMultiplePermissions
Die folgenden Schritte zeigen, wie Sie den RequestPermission
-Vertrag verwenden. Die
Der Ablauf für den RequestMultiplePermissions
-Vertrag ist fast identisch.
Übergeben Sie in der Initialisierungslogik Ihrer Aktivität oder des Fragments eine Implementierung von
ActivityResultCallback
in einen Aufruf anregisterForActivityResult()
DasActivityResultCallback
definiert, wie deine App die Antwort des Nutzers auf der Berechtigungsanfrage.Behalten Sie einen Verweis auf den Rückgabewert von
registerForActivityResult()
bei, der ist vom TypActivityResultLauncher
Um das Dialogfeld für Systemberechtigungen bei Bedarf anzuzeigen, rufen Sie die Methode
launch()
auf der Instanz vonActivityResultLauncher
, die Sie im vorherigen Schritt.Nach dem Aufruf von
launch()
wird das Dialogfeld mit den Systemberechtigungen angezeigt. Wenn der Parameter trifft der Nutzer eine Auswahl, ruft das System Ihre Implementierung asynchron auf. vonActivityResultCallback
, die Sie im vorherigen Schritt definiert haben.Hinweis : Das angezeigte Dialogfeld kann in der App nicht angepasst werden. wenn du
launch()
aufrufst. Um weitere Informationen bereitzustellen oder dem Nutzer Kontext bieten, ändern Sie die Benutzeroberfläche Ihrer App, damit die Nutzer warum eine Funktion in deiner App eine bestimmte Berechtigung benötigt. Für Sie können beispielsweise den Text in der Schaltfläche ändern, mit der die Funktion .Außerdem verweist der Text im Dialogfeld für Systemberechtigungen auf die Berechtigung Gruppe, die mit der angeforderten Berechtigung verknüpft ist. Dieses Berechtigungsgruppierungen sind für eine einfachere Nutzung des Systems gedacht und Ihre App dürfen sich nicht darauf verlassen, dass Berechtigungen innerhalb oder außerhalb eines bestimmten Berechtigungsgruppe.
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 den empfohlenen Prozess für die Prüfung auf und ggf. eine Berechtigung vom Nutzer anzufordern:
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 zu erlauben, die Berechtigungsanfrage zu verwalten
Code kannst du die Berechtigungsanfrage
selbst zu programmieren. Fügen Sie dazu den Anforderungscode in einen Aufruf von
requestPermissions()
Das folgende Code-Snippet zeigt, wie eine Berechtigung mithilfe eines Anforderungscode:
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 reagiert hat,
ruft die Implementierung von onRequestPermissionsResult()
in Ihrer App auf. Das System übergibt den Nutzer
auf das Dialogfeld mit den Berechtigungen
und auf den von Ihnen definierten Anforderungscode.
Dies wird 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 ist, dass das mehrere Berechtigungen in Bezug auf den Standort hat. Welche Berechtigungen Sie und wie Sie sie anfordern, hängen von den Standortanforderungen für Ihre Anwendungsfall der App.
Vordergrundstandort
Wenn Ihre App eine Funktion enthält, die nur Standortinformationen teilt oder empfängt einmal oder für einen festgelegten Zeitraum erfordert, dass diese Funktion Standortzugriff. Hier einige Beispiele:
- Innerhalb einer Navigations-App ermöglicht eine Funktion, die detaillierte Routenführung Wegbeschreibungen.
- Eine Funktion in einer Messaging-App ermöglicht es Nutzern, ihren aktuellen Standort zu teilen. mit einem anderen Nutzer.
Das System geht davon aus, dass Ihre App die Standortermittlung im Vordergrund verwendet, wenn eine Funktion Ihre App an einem der folgenden Orte auf den aktuellen Standort des Geräts zugreift Situationen:
- 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 informiert das System die Nutzer über eine dauerhafte Benachrichtigung. Ihre App behält den Zugriff, wenn sie im Hintergrund platziert wird, z. B. wenn der Der Nutzer drückt die Startbildschirmtaste auf seinem Gerät oder dreht das Display des Geräts. deaktiviert.
Unter Android 10 (API-Level 29) und höher müssen Sie einen Vordergrund Diensttyp
location
, wie im folgenden Code-Snippet gezeigt. Frühere Versionen wird empfohlen, 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
ACCESS_COARSE_LOCATION
oder die
ACCESS_FINE_LOCATION
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 teilt den Standort ständig mit anderen Nutzern oder verwendet Geofencing API hinzu. Hier einige Beispiele:
- Innerhalb einer App zur Standortfreigabe für Familien können Nutzer Standort mit Familienmitgliedern teilen.
- Innerhalb einer IoT-App können Nutzer mit einer Funktion ihre Smart-Home-Geräte konfigurieren, z. B. die sich ausschalten, wenn der Nutzer das Zuhause verlässt, und wieder einschalten, wenn der wenn Nutzende nach Hause kommen.
Das System nutzt die Standortermittlung im Hintergrund für deine App, wenn sie auf die Standort des Geräts in allen Situationen, die nicht in den im Vordergrund ein. Die Genauigkeit der Standortermittlung im Hintergrund ist entspricht der Genauigkeit der Standortermittlung im Vordergrund, die von die von Ihrer App deklarierten Berechtigungen zur Standortermittlung verwenden.
Unter Android 10 (API-Level 29) und höher musst du die
ACCESS_BACKGROUND_LOCATION
Berechtigung im Manifest deiner App, die Standortermittlung im Hintergrund anzufordern
Zugriff während der Laufzeit. In früheren Versionen von
Wenn deine App unter Android Zugriff auf die Standortermittlung im Vordergrund erhält,
erhält ebenfalls 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 den Nutzern helfen, zu verstehen, welche Auswirkungen es hat, die Berechtigung zu verweigern. Ihre App sollte vor allem Nutzern auf Funktionen aufmerksam gemacht werden, die aufgrund der fehlenden Berechtigung nicht funktionieren. Beachten Sie dabei die folgenden Best Practices:
Die Aufmerksamkeit des Nutzers lenken. Einen bestimmten Teil der Benutzeroberfläche Ihrer App hervorheben deren Funktionalität eingeschränkt ist, weil Ihre App nicht über die Berechtigung. 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. Machen Sie stattdessen deutlich, Funktionen sind nicht verfügbar, weil deine App nicht die erforderliche Berechtigung hat.
Die Benutzeroberfläche darf nicht blockiert werden. Mit anderen Worten: Zeigen Sie kein Vollbild-Warnmeldung, die Nutzer daran hindert, deine App weiter zu verwenden überhaupt nicht.
Gleichzeitig sollte Ihre App die Entscheidung des Nutzers respektieren, eine Berechtigung. Ab Android 11 (API-Level 30), wenn der Nutzer bei der Auswahl von Ablehnen für eine bestimmte Berechtigung mehrmals während der Installation deiner App erhalten. auf einem Gerät erscheint das Dialogfeld für Systemberechtigungen nicht, wenn Ihre App fordert diese Berechtigung noch einmal an. Die Handlung des Nutzers impliziert „Nicht mehr fragen“. An In früheren Versionen wurde das Dialogfeld für Systemberechtigungen jedes Mal angezeigt, App hat eine Berechtigung angefordert, es sei denn, die App hat zuvor die Option „Nicht fragen“ ausgewählt. wiederholen“ oder Option auswählen.
Wenn ein Nutzer eine Berechtigungsanfrage mehrmals ablehnt, gilt dies als dauerhaft. leugnen. Es ist sehr wichtig, Nutzer nur dann um Berechtigungen zu bitten, wenn sie sie benötigen auf eine bestimmte Funktion zugreifen, damit du die Funktion nicht mehr nutzen kannst. um Berechtigungen erneut anzufordern.
In bestimmten Situationen kann die Berechtigung automatisch ohne das wenn Nutzende eine Aktion ausführen. (Möglicherweise wird eine Berechtigung erteilt automatisch auch.) Es ist wichtig, nichts über automatische verhalten. Jedes Mal, wenn Ihre App auf Funktionen zugreifen muss, für die ein Berechtigung haben, prüfen Sie, ob Ihrer App diese Berechtigung noch gewährt wurde.
Um die Nutzererfahrung bei der App-Anfrage zu optimieren Best Practices für App-Berechtigungen
Ablehnungsstatus beim Testen und Debuggen prüfen
Um zu ermitteln, ob einer App dauerhaft Berechtigungen verweigert wurden (zur Fehlerbehebung) und Testzwecke), verwenden Sie den folgenden Befehl:
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 durch zweimaliges Auswählen von Ablehnen dauerhaft abgelehnt wurden, werden
von USER_FIXED
gemeldet.
Setzen Sie diese Flags zurück, damit Tester das Anfragedialogfeld während des Tests sehen können wenn Sie mit der Fehlerbehebung in 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 ausführen möchten zurückgesetzt werden.
Eine vollständige Liste der Berechtigungen für Android-Apps finden Sie in der permissions API Referenzseite.
Einmalige Berechtigungen
<ph type="x-smartling-placeholder">Ab Android 11 (API-Level 30) immer dann, wenn Ihre App eine Berechtigung anfordert die sich auf den Standort, das Mikrofon oder die Kamera beziehen, die Option Nur dieses Mal enthält (siehe Abbildung 2). Wenn der Nutzer diese Option wird Ihrer App eine vorübergehende einmalige Berechtigung gewährt.
Ihre App kann dann für einen Zeitraum, der von das Verhalten Ihrer App und die Aktionen der Nutzer:
- Solange die Aktivitäten Ihrer App sichtbar sind, kann sie auf die Daten zugreifen.
- Wenn der Nutzer Ihre App in den Hintergrund sendet, kann Ihre App weiterhin auf die Daten für einen kurzen Zeitraum.
- Wenn Sie einen Dienst im Vordergrund starten, während die Aktivität sichtbar ist, und der Nutzer und verschiebt Ihre App in den Hintergrund, kann sie 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, Die App kann nicht auf die Daten zugreifen, unabhängig davon, ob du einen Vordergrund Service. Widerruft der Nutzer die einmalige Berechtigung Ihrer App, Berechtigung hat, wird der Prozess der App beendet.
Wenn der Nutzer Ihre App das nächste Mal öffnet und eine Funktion in Ihrer App Zugriff auf Standort, Mikrofon oder Kamera hat, wird der Nutzer noch einmal um die Berechtigung gebeten.
Nicht verwendete Berechtigungen zurücksetzen
Android bietet mehrere Möglichkeiten, nicht verwendete Laufzeitberechtigungen Standardstatus, abgelehnt:
- Eine API, mit der Sie den Zugriff Ihrer App proaktiv entfernen können auf eine nicht verwendete Laufzeitberechtigung.
- Ein Systemmechanismus, der automatisch die Berechtigungen für nicht verwendete Apps zurücksetzen,
App-Zugriff entfernen
Unter Android 13 (API-Level 33) und höher können Sie den Zugriff Ihrer App auf Folgendes entfernen: Laufzeitberechtigungen, die deine App nicht mehr benötigt. Wenn Sie Ihre App aktualisieren, führen Sie diesen Schritt aus, damit die Nutzer besser verstehen, fordert weiterhin bestimmte Berechtigungen an. Dieses Wissen trägt dazu bei, das Vertrauen der Nutzer zu stärken. in Ihrer App.
Übergeben Sie den Namen dieser Berechtigung, um den Zugriff auf eine Laufzeitberechtigung zu entfernen
in
revokeSelfPermissionOnKill()
Um den Zugriff auf eine Gruppe von Laufzeitberechtigungen gleichzeitig zu entfernen, übergeben Sie eine
von Berechtigungsnamen in
revokeSelfPermissionsOnKill()
Das Entfernen von Berechtigungen erfolgt asynchron und bricht alle Prozesse ab.
mit der UID Ihrer App verknüpft.
Damit das System den Zugriff Ihrer App auf die Berechtigungen entfernen kann, Prozesse im Zusammenhang mit Ihrer App beendet werden müssen. Wenn Sie die API aufrufen, wann es sicher ist, diese Prozesse zu beenden. Normalerweise wartet das System bis Ihre App längere Zeit im Hintergrund läuft statt im Vordergrund.
Um den Nutzer darüber zu informieren, dass Ihre App keinen Zugriff mehr auf eine bestimmte Laufzeit benötigt Berechtigungen, wird ein Dialogfeld angezeigt, wenn der Nutzer das nächste Mal deine App startet. Dieses Dialogfeld die 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 Zeit nicht verwendet wird, Monate, schützt das System Nutzerdaten, indem es die sensiblen Daten Laufzeitberechtigungen, die der Nutzer Ihrer App erteilt hat. Weitere Informationen im Leitfaden zum Ruhezustand der App.
Anfrage, bei Bedarf zum Standard-Handler zu werden
Einige Apps benötigen Zugriff auf vertrauliche Nutzerinformationen aus der Anrufliste und SMS-Nachrichten. Wenn Sie die Berechtigungen für die Anrufliste anfordern möchten und SMS-Nachrichten senden und Ihre App im Play Store veröffentlichen, müssen Sie die Nutzer Ihre App als Standard-Handler für eine zentrale Systemfunktion festzulegen, bevor die diese Laufzeitberechtigungen anfordern.
Weitere Informationen zu Standard-Handlern, einschließlich einer Anleitung zum Anzeigen eines Standard-Handler-Aufforderung für Nutzer, siehe Leitfaden zu Berechtigungen, die nur in Standard-Handler.
Alle Laufzeitberechtigungen zu Testzwecken gewähren
Um alle Laufzeitberechtigungen automatisch zu gewähren, wenn Sie eine App auf einem
Emulator oder Testgerät, verwenden Sie die Option -g
für die adb shell install
verwenden, 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 der Beispiele für Berechtigungen
Sie können auch dieses Codelab absolvieren, in dem Sie den Datenschutz optimal demonstrieren. .