Laufzeitberechtigungen anfordern

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 ermöglicht. Diese Schritte sind Teil des Workflows für die 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 den Schritten in diesem Leitfaden.

Wenn Sie keine gefährlichen Berechtigungen deklarieren oder Ihre App auf einem Gerät mit Android 5.1 (API-Level 22) oder niedriger installiert ist, werden die Berechtigungen automatisch gewährt und Sie müssen die verbleibenden Schritte auf dieser Seite nicht ausführen.

Hinweis: Einige Berechtigungen schützen den Zugriff auf Systemressourcen, die besonders sensibel sind oder nicht direkt mit dem Datenschutz für Nutzer zusammenhängen. Für die Beantragung dieser speziellen Berechtigungen gilt ein anderes Verfahren.

Grundprinzipien

Die grundlegenden Prinzipien für das Anfordern von Berechtigungen zur Laufzeit sind:

• Frage im Kontext nach einer Berechtigung, wenn der Nutzer mit der Funktion interagiert, für die sie erforderlich ist.
• Blockieren Sie den Nutzer nicht. Biete immer die Möglichkeit, einen Informationsvorgang abzubrechen, z. B. einen Vorgang, in dem die Gründe für die Anforderung von Berechtigungen erläutert 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 benötigen.
• Gehen Sie nicht von einem bestimmten Systemverhalten aus. Gehe beispielsweise nicht davon aus, dass Berechtigungen in derselben Berechtigungsgruppe angezeigt werden. Eine Berechtigungsgruppe hilft dem System lediglich, die Anzahl der Systemdialogfelder zu minimieren, die dem Nutzer angezeigt werden, wenn eine App eng verwandte Berechtigungen anfordert.

Workflow zum Anfordern von Berechtigungen

Bevor du Laufzeitberechtigungen in deiner App deklarierst und anforderst, solltest du prüfen, ob dies überhaupt erforderlich ist. Viele Anwendungsfälle in deiner App, z. B. das Aufnehmen von Fotos, das Pausieren der Medienwiedergabe und das Einblenden relevanter Anzeigen, lassen sich auch ohne Deklaration von Berechtigungen umsetzen.

Wenn Sie zu dem Schluss kommen, dass Ihre App Laufzeitberechtigungen deklarieren und anfordern muss, führen Sie die folgenden Schritte aus:

1. Deklariere die Berechtigungen, die deine App möglicherweise anfordern muss, in der Manifestdatei deiner App.
2. Gestalte die User Experience (UX) deiner App so, dass bestimmte Aktionen in deiner App mit bestimmten Laufzeitberechtigungen verknüpft sind. Informieren Sie die Nutzer darüber, bei welchen Aktionen sie Ihrer App möglicherweise die Berechtigung erteilen müssen, auf private Nutzerdaten zuzugreifen.
3. Warte, bis der Nutzer die Aufgabe oder Aktion in deiner App aufruft, für die Zugriff auf bestimmte private Nutzerdaten erforderlich ist. Anschließend kann die App die Laufzeitberechtigung anfordern, die für den Zugriff auf diese Daten erforderlich ist.

4. Prüfen Sie, ob der Nutzer bereits die Berechtigung

   Laufzeitberechtigung, 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.

5. Prüfen Sie, ob Ihre App dem Nutzer eine Begründung anzeigen sollte, warum er Ihrer App eine bestimmte Laufzeitberechtigung gewähren muss. Wenn das System feststellt, dass in Ihrer App keine Begründung angezeigt werden sollte, fahren Sie direkt mit dem nächsten Schritt fort, ohne ein UI-Element anzuzeigen.

   Wenn das System jedoch feststellt, dass deine App eine Begründung anzeigen sollte, präsentiere die Begründung dem Nutzer in einem UI-Element. In dieser Begründung muss klar dargelegt werden, 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, fahren Sie mit dem nächsten Schritt fort.

6. 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 auf der Übersichtsseite zu Berechtigungen zu sehen ist.

7. Prüfe die Antwort des Nutzers, also ob er die Laufzeitberechtigung gewährt oder verweigert hat.

8. Wenn der Nutzer Ihrer App die Berechtigung erteilt hat, können Sie auf die privaten Nutzerdaten zugreifen. Wenn der Nutzer die Berechtigung stattdessen verweigert hat, sollte die Nutzerfreundlichkeit der App so angepasst werden, dass sie dem Nutzer Funktionen ohne die durch diese Berechtigung geschützten Informationen bietet.

Abbildung 1 veranschaulicht den Workflow und die Entscheidungen, die mit diesem Prozess verbunden sind:

Abbildung 1. Diagramm, das den Workflow zum Deklarieren und Anfordern von Laufzeitberechtigungen unter Android zeigt.

Prüfen, ob Ihrer App die Berechtigung bereits erteilt 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, warum Ihre App die Berechtigung benötigt

Im Berechtigungsdialog, der vom System angezeigt wird, wenn du requestPermissions() aufrufst, wird angegeben, welche Berechtigung deine App benötigt, aber nicht, warum. In einigen Fällen kann das für den Nutzer verwirrend sein. Es empfiehlt sich, dem Nutzer zu erklären, warum Ihre App die Berechtigungen benötigt, bevor Sie requestPermissions() aufrufen.

Untersuchungen zeigen, dass Nutzer Berechtigungsanfragen viel eher zustimmen, wenn sie wissen, warum die App sie benötigt, z. B. ob die Berechtigung für eine Hauptfunktion der App oder für Werbung erforderlich ist. Wenn Sie also nur einen Bruchteil der API-Aufrufe verwenden, die zu einer Berechtigungsgruppe gehören, müssen Sie explizit angeben, welche dieser Berechtigungen Sie verwenden und warum. Wenn Sie beispielsweise nur den ungefähren Standort verwenden, informieren Sie den Nutzer darüber in der App-Beschreibung oder in Hilfeartikeln zu Ihrer App.

Unter bestimmten Bedingungen ist es auch hilfreich, Nutzer in Echtzeit über den Zugriff auf sensible Daten zu informieren. Wenn Sie beispielsweise auf die Kamera oder das Mikrofon zugreifen, sollten Sie den Nutzer darüber informieren, indem Sie ein Benachrichtigungssymbol an einer Stelle in Ihrer App oder in der Benachrichtigungsleiste (wenn die Anwendung im Hintergrund ausgeführt wird) anzeigen, damit es nicht so aussieht, als würden Sie heimlich Daten erfassen.

Hinweis :Ab Android 12 (API-Level 31) wird der Nutzer über Datenschutzanzeigen benachrichtigt, wenn Anwendungen auf das Mikrofon oder die Kamera zugreifen.

Wenn ihr eine Berechtigung für eine Funktion anfordern müsst, der Grund dafür aber nicht klar ist, solltet ihr dem Nutzer erklären, warum ihr vertrauliche Berechtigungen benötigt.

Wenn die Methode ContextCompat.checkSelfPermission() den Wert PERMISSION_DENIED zurückgibt, rufen Sie shouldShowRequestPermissionRationale() auf. Wenn diese Methode true zurückgibt, zeige dem Nutzer eine informative Benutzeroberfläche an. Beschreiben Sie in dieser Benutzeroberfläche, warum die Funktion, die der Nutzer aktivieren möchte, eine bestimmte Berechtigung benötigt.

Wenn Ihre App eine Berechtigung für den Zugriff auf den Standort, das Mikrofon oder die Kamera anfordert, sollten Sie außerdem erklären, warum Ihre App Zugriff auf diese Informationen benötigt.

Berechtigungen anfordern

Nachdem der Nutzer eine informative Benutzeroberfläche gesehen hat oder der Rückgabewert von shouldShowRequestPermissionRationale() angibt, dass keine informative Benutzeroberfläche angezeigt werden muss, fordern Sie die Berechtigung an. Nutzer sehen ein Dialogfeld für Systemberechtigungen, in dem sie auswählen können, ob sie deiner App eine bestimmte Berechtigung gewähren möchten.

Verwende dazu den Vertrag RequestPermission, der in einer AndroidX-Bibliothek enthalten ist. Damit erlaubst du dem System, den Code für die Berechtigungsanfrage für dich zu verwalten. Da die Verwendung des RequestPermission-Vertrags die Logik vereinfacht, ist dies die empfohlene Lösung, sofern möglich. Bei Bedarf können Sie jedoch auch im Rahmen der Berechtigungsanfrage selbst einen Anfragecode verwalten und diesen Anfragecode in die Callback-Logik für Berechtigungen einfügen.

Dem System erlauben, den Code für die Berechtigungsanfrage zu verwalten

Damit das System den mit einer Berechtigungsanfrage verknüpften Anfragecode verwalten kann, fügen Sie in der build.gradle-Datei Ihres Moduls Abhängigkeiten von den folgenden Bibliotheken hinzu:

• androidx.activity, Version 1.2.0 oder höher
• androidx.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.
• Wenn Sie mehrere Berechtigungen gleichzeitig anfordern möchten, verwenden Sie RequestMultiplePermissions.

In den folgenden Schritten wird die Verwendung des RequestPermission-Vertrags beschrieben. Der Prozess ist für den RequestMultiplePermissions-Vertrag fast identisch.

1. Übergeben Sie in der Initialisierungslogik Ihrer Aktivität oder Ihres Fragments eine Implementierung von ActivityResultCallback an einen Aufruf von registerForActivityResult(). Mit ActivityResultCallback wird 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 Typ ActivityResultLauncher ist.

2. Wenn Sie das Dialogfeld für die Systemberechtigungen bei Bedarf anzeigen möchten, rufen Sie die Methode launch() für die Instanz von ActivityResultLauncher auf, die Sie im vorherigen Schritt gespeichert haben.

   Nachdem launch() aufgerufen wurde, wird das Dialogfeld für die Systemberechtigungen angezeigt. Wenn der Nutzer eine Auswahl trifft, ruft das System asynchron Ihre Implementierung von ActivityResultCallback auf, die Sie im vorherigen Schritt definiert haben.

   Hinweis : Das Dialogfeld, das beim Aufrufen von launch() angezeigt wird, kann in deiner App nicht angepasst werden. Wenn du Nutzern mehr Informationen oder Kontext bieten möchtest, ändere die Benutzeroberfläche deiner App, damit Nutzer leichter verstehen, warum eine Funktion in deiner App eine bestimmte Berechtigung benötigt. Sie können beispielsweise den Text auf der Schaltfläche ändern, über die die Funktion aktiviert wird.

   Außerdem bezieht sich der Text im Dialogfeld für die Systemberechtigung auf die Berechtigungsgruppe, die mit der von dir angeforderten Berechtigung verknüpft ist. Diese Berechtigungsgruppierung soll die Nutzung des Systems vereinfachen. Ihre App sollte sich nicht darauf verlassen, dass sich Berechtigungen innerhalb oder außerhalb einer bestimmten Berechtigungsgruppe befinden.

Das folgende Code-Snippet zeigt, wie die Antwort auf die Berechtigungsanfrage verarbeitet 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);
}

Dieses Code-Snippet zeigt, wie Sie eine Berechtigung prüfen und bei Bedarf vom Nutzer anfordern:

Kotlin

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        // The registered ActivityResultCallback gets the result of this request.
        requestPermissionLauncher.launch(
                Manifest.permission.REQUESTED_PERMISSION)
    }
}

Java

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    // The registered ActivityResultCallback gets the result of this request.
    requestPermissionLauncher.launch(
            Manifest.permission.REQUESTED_PERMISSION);
}

Code für Berechtigungsanfragen selbst verwalten

Alternativ dazu, dass das System den Code für die Berechtigungsanfrage verwaltet, können Sie den Code für die Berechtigungsanfrage auch selbst verwalten. Fügen Sie dazu den Anfragecode in einen Aufruf von requestPermissions() ein.

Hinweis: Das Dialogfeld, das beim Aufrufen von requestPermissions() angezeigt wird, kann in Ihrer App nicht angepasst werden. Der Text im Dialogfeld für die Systemberechtigung bezieht sich auf eine Berechtigungsgruppe. Diese Berechtigungsgruppierung ist jedoch für die einfache Verwendung des Systems gedacht. Ihre App darf nicht davon abhängig sein, dass sich Berechtigungen innerhalb oder außerhalb einer bestimmten Berechtigungsgruppe befinden.

Das folgende Code-Snippet zeigt, wie Sie eine Berechtigung mit einem Anfragecode anfordern:

Kotlin

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
        performAction(...)
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        requestPermissions(CONTEXT,
                arrayOf(Manifest.permission.REQUESTED_PERMISSION),
                REQUEST_CODE)
    }
}

Java

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    requestPermissions(CONTEXT,
            new String[] { Manifest.permission.REQUESTED_PERMISSION },
            REQUEST_CODE);
}

Nachdem der Nutzer auf das Dialogfeld für die Systemberechtigungen reagiert hat, ruft das System die Implementierung von onRequestPermissionsResult() in Ihrer App auf. Das System übergibt die Antwort des Nutzers auf das Berechtigungsfenster sowie den von Ihnen definierten Anfragecode, wie im folgenden Code-Snippet gezeigt:

Kotlin

override fun onRequestPermissionsResult(requestCode: Int,
        permissions: Array<String>, grantResults: IntArray) {
    when (requestCode) {
        PERMISSION_REQUEST_CODE -> {
            // If request is cancelled, the result arrays are empty.
            if ((grantResults.isNotEmpty() &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED)) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            } else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return
        }

        // Add other 'when' lines to check for other
        // permissions this app might request.
        else -> {
            // Ignore all other requests.
        }
    }
}

Java

@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions,
        int[] grantResults) {
    switch (requestCode) {
        case PERMISSION_REQUEST_CODE:
            // If request is cancelled, the result arrays are empty.
            if (grantResults.length > 0 &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            }  else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return;
        }
        // Other 'case' lines to check for other
        // permissions this app might request.
    }
}

Berechtigungen zur Standortermittlung anfordern

Wenn Sie Berechtigungen zur Standortermittlung anfordern, sollten Sie dieselben Best Practices wie für alle anderen Laufzeitberechtigungen befolgen. Ein wichtiger Unterschied bei den Berechtigungen zur Standortermittlung ist, dass das System mehrere Berechtigungen im Zusammenhang mit dem Standort enthält. 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 teilt oder empfängt, ist für diese Funktion der Zugriff auf den Standort im Vordergrund erforderlich. Einige Beispiele:

• In einer Navigations-App können Nutzer eine detaillierte Routenführung abrufen.
• In einer Messaging-App können Nutzer ihren aktuellen Standort mit anderen Nutzern teilen.

Das System geht davon aus, dass Ihre App den Standort 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 Ihrer App gehört, ist sichtbar.

• In Ihrer App wird ein Dienst im Vordergrund ausgeführt. 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 des Geräts ausschaltet.

  Unter Android 10 (API-Level 29) und höher müssen Sie einen Diensttyp im Vordergrund von location deklarieren, wie im folgenden Code-Snippet gezeigt. Bei früheren Android-Versionen empfehlen wir, 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 deklarieren einen Bedarf für die Standortermittlung im Vordergrund, wenn Ihre App entweder die Berechtigung ACCESS_COARSE_LOCATION oder die Berechtigung ACCESS_FINE_LOCATION anfordert, wie im folgenden Snippet gezeigt:

<manifest ... >
  <!-- Include this permission any time your app needs location information. -->
  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

  <!-- Include only if your app benefits from precise location access. -->
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
</manifest>

Standortermittlung im Hintergrund

Eine App benötigt Zugriff auf die Standortermittlung im Hintergrund, wenn eine Funktion in der App den Standort ständig mit anderen Nutzern teilt oder die Geofencing API verwendet. Hier einige Beispiele:

• In einer App zur Standortfreigabe für Familien können Nutzer ihren Standort kontinuierlich mit Familienmitgliedern teilen.
• In 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 er zurückkehrt.

Das System geht davon aus, dass Ihre App die Standortermittlung im Hintergrund verwendet, wenn sie in einer anderen als den im Abschnitt Standortermittlung im Vordergrund beschriebenen Situationen auf den aktuellen Standort des Geräts zugreift. Die Standortgenauigkeit im Hintergrund entspricht der Standortgenauigkeit im Vordergrund, die von den Berechtigungen zur Standortermittlung abhängt, die Ihre App deklariert.

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 automatisch auch Zugriff auf die Standortermittlung im Hintergrund, wenn sie Zugriff auf die Standortermittlung im Vordergrund erhält.

<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>

Hinweis: Der Google Play Store hat eine Standortrichtlinie für den Gerätestandort, die den Zugriff auf die Standortermittlung im Hintergrund auf Apps beschränkt, die diese für ihre Hauptfunktion benötigen und die entsprechenden Richtlinienanforderungen erfüllen.

Umgang mit der Ablehnung von Berechtigungen

Wenn der Nutzer eine Berechtigungsanfrage ablehnt, muss Ihre App ihm die Auswirkungen der Ablehnung der Berechtigung verständlich machen. Insbesondere müssen Sie Nutzer in Ihrer App auf die Funktionen hinweisen, die aufgrund der fehlenden Berechtigung nicht funktionieren. Beachten Sie dabei die folgenden Best Practices:

• Funktionsverlust minimieren: Nutzer sollten die App so weit wie möglich ohne die angeforderten Berechtigungen nutzen können. Wenn die Funktion mit den verfügbaren Daten zumindest teilweise funktioniert, auch wenn sie im Vergleich zu dem, was mit der Berechtigung möglich gewesen wäre, eingeschränkt ist, ist es am besten, sie aktiviert zu lassen.

• Lenken Sie die Aufmerksamkeit der Nutzer. Heben Sie einen bestimmten Teil der Benutzeroberfläche Ihrer App hervor, in dem die Funktionalität eingeschränkt ist, weil Ihre App nicht die erforderliche Berechtigung hat. Beispiele dafür, was Sie tun können:

  • An der Stelle, an der die Ergebnisse oder Daten der Funktion angezeigt worden wären, wird eine Meldung eingeblendet.
  • Zeige einen anderen Button mit einem Fehlersymbol und einer Fehlerfarbe an.

• Machen Sie möglichst genaue Angaben. Zeigen Sie keine allgemeine Nachricht an. Machen Sie stattdessen deutlich, welche Funktionen nicht verfügbar sind, weil Ihre App nicht die erforderliche Berechtigung hat.

• Blockieren Sie die Benutzeroberfläche nicht. Mit anderen Worten: Zeigen Sie keine Warnmeldung im Vollbildmodus an, die Nutzer daran hindert, Ihre App überhaupt weiter zu verwenden.

• Nutzereinstellungen akzeptieren:Es ist in Ordnung, Nutzern mitzuteilen, wie sich der fehlende Zugriff auf die angeforderten Berechtigungen auf die Funktionalität auswirkt. Sie sollten sich jedoch nicht unter Druck gesetzt fühlen, ihre Meinung zu ändern. Es ist wichtig, Nutzer gegebenenfalls darauf hinzuweisen, dass sie nicht auf alle Funktionen zugreifen können, z. B. wenn sie versuchen, einen Teil der App zu verwenden, der ohne die Berechtigung blockiert ist. Sie sollten sie jedoch nicht ständig dazu auffordern, ihre Entscheidung zu überdenken.

Wenn Sie diese Richtlinien befolgen, können Sie dazu beitragen, dass Nutzer den Zugriff auf ihre privaten Daten so verwalten können, wie es ihren Werten entspricht. Wenn Sie die Datenschutzentscheidungen der Nutzer nicht akzeptieren, schadet das nicht nur dem Vertrauen in Ihre App und ihrem Ruf, sondern auch dem Ökosystem als Ganzes.

Tipp :Wir empfehlen, dass Ihre App auch nach der Ablehnung von Berechtigungen eine möglichst gute Nutzererfahrung bietet. Wenn beispielsweise der Zugriff auf das Mikrofon verweigert wird, müssen Sie dennoch die volle Nutzbarkeit der Textfunktionen gewährleisten.

Wenn der Nutzer während der Installationsdauer Ihrer App auf einem Gerät mehr als einmal auf „Ablehnen“ für eine bestimmte Berechtigung tippt, wird das Dialogfeld für die Systemberechtigungen nicht mehr angezeigt, wenn Ihre App diese Berechtigung noch einmal anfordert. Die Aktion des Nutzers impliziert „Nicht noch einmal fragen“ und wird als dauerhafte Ablehnung betrachtet. Es ist sehr wichtig, Nutzer nur dann um Berechtigungen zu bitten, wenn sie Zugriff auf eine bestimmte Funktion benötigen. Andernfalls kann es passieren, dass Sie Berechtigungen nicht noch einmal anfordern können. In bestimmten Situationen kann die Berechtigung automatisch verweigert werden, ohne dass der Nutzer etwas tun muss. (Eine Berechtigung kann auch automatisch gewährt werden.) Es ist wichtig, keine Annahmen über automatisches Verhalten zu treffen. Prüfen Sie jedes Mal, wenn Ihre App auf eine Funktion zugreifen muss, für die eine Berechtigung erforderlich ist, ob die App diese Berechtigung noch hat. Weitere Informationen dazu, wie Sie die Nutzerfreundlichkeit beim Anfordern von App-Berechtigungen verbessern können, finden Sie unter Best Practices für App-Berechtigungen.

Ablehnungsstatus beim Testen und Debuggen prüfen

Mit dem folgenden Befehl können Sie feststellen, ob einer App Berechtigungen dauerhaft verweigert wurden (zu Debugging- und Testzwecken):

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, werden mit USER_SET gekennzeichnet. Berechtigungen, die durch zweimaliges Auswählen von Ablehnen dauerhaft verweigert wurden, sind 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 Debugging Ihrer App fertig sind. Verwenden Sie dazu den folgenden Befehl:

adb shell pm clear-permission-flags PACKAGE_NAME PERMISSION_NAME user-set user-fixed

PERMISSION_NAME ist der Name der Berechtigung, die Sie zurücksetzen möchten.

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 zur Berechtigungs-API.

Einmalige Berechtigungen

Abbildung 2: Systemdialog, der angezeigt wird, wenn eine App eine einmalige Berechtigung anfordert.

Ab Android 11 (API-Level 30) enthält das Dialogfeld für Berechtigungen, das Nutzern angezeigt wird, wenn eine App eine Berechtigung für den Zugriff auf den Standort, das Mikrofon oder die Kamera anfordert, die Option Nur dieses Mal (siehe Abbildung 2). Wenn der Nutzer diese Option im Dialogfeld auswählt, erhält deine App eine temporäre einmalige Berechtigung.

Ihre App kann dann für einen bestimmten Zeitraum auf die zugehörigen Daten zugreifen. Dieser Zeitraum hängt vom Verhalten Ihrer App und den Aktionen des Nutzers ab:

• Solange die Aktivität Ihrer App sichtbar ist, kann sie auf die Daten zugreifen.
• Wenn der Nutzer Ihre App in den Hintergrund verschiebt, kann sie noch für kurze Zeit auf die Daten zugreifen.
• Wenn du einen Dienst im Vordergrund startest, während die Aktivität sichtbar ist, und der Nutzer deine App dann in den Hintergrund verschiebt, kann deine App weiterhin auf die Daten zugreifen, bis der Dienst im Vordergrund beendet wird.

App-Prozess wird beendet, wenn die Berechtigung widerrufen wird

Wenn der Nutzer die einmalige Berechtigung widerruft, z. B. in den Systemeinstellungen, kann Ihre App nicht auf die Daten zugreifen, unabhängig davon, ob Sie einen Dienst im Vordergrund gestartet haben. Wie bei jeder Berechtigung wird der Prozess Ihrer App beendet, wenn der Nutzer die einmalige Berechtigung Ihrer App widerruft.

Wenn der Nutzer deine App das nächste Mal öffnet und eine Funktion in deiner App Zugriff auf den Standort, das Mikrofon oder die Kamera anfordert, wird der Nutzer noch einmal um die Berechtigung gebeten.

Hinweis: Wenn deine App bereits die Best Practices für das Anfordern von Laufzeitberechtigungen befolgt, musst du keine Logik in deiner App hinzufügen oder ändern, um einmalige Berechtigungen zu unterstützen.

Nicht verwendete Berechtigungen zurücksetzen

Android bietet mehrere Möglichkeiten, nicht verwendete Laufzeitberechtigungen auf den Standardstatus „Abgelehnt“ zurückzusetzen:

• Eine API, mit der Sie den Zugriff Ihrer App auf eine nicht verwendete Laufzeitberechtigung proaktiv 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 Ihre App 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 trägt dazu bei, das Vertrauen der Nutzer in Ihre App zu stärken.

Wenn Sie den Zugriff auf eine Laufzeitberechtigung entfernen möchten, übergeben Sie den Namen dieser Berechtigung an revokeSelfPermissionOnKill(). 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.

Hinweis :Damit in den Systemeinstellungen angezeigt wird, dass Ihre App nicht auf Daten in einer bestimmten Berechtigungsgruppe zugreift, müssen Sie den Zugriff auf alle Berechtigungen in dieser Berechtigungsgruppe entfernen. In diesem Fall kann es hilfreich sein, revokeSelfPermissionsOnKill() aufzurufen und mehrere Berechtigungen innerhalb der Berechtigungsgruppe zu übergeben.

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, bestimmt das System, wann diese Prozesse sicher beendet werden können. In der Regel wartet das System, bis Ihre App längere Zeit im Hintergrund statt im Vordergrund ausgeführt wird.

Wenn du den Nutzer darüber informieren möchtest, dass deine App keinen Zugriff mehr auf bestimmte Laufzeitberechtigungen benötigt, kannst du beim nächsten Start der App ein Dialogfeld einblenden. Dieses Dialogfeld kann die Liste der Berechtigungen enthalten.

Berechtigungen nicht verwendeter 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 es die sensiblen Laufzeitberechtigungen, die der Nutzer Ihrer App gewährt hat, automatisch zurücksetzt. Weitere Informationen finden Sie im Leitfaden zum App-Ruhezustand.

Anfrage, bei Bedarf der Standard-Handler zu werden

Einige Apps sind auf den Zugriff auf sensible Nutzerdaten im Zusammenhang mit Anruflisten und SMS angewiesen. Wenn Sie die Berechtigungen für Anruflisten und SMS anfordern und Ihre App im Google Play Store veröffentlichen möchten, müssen Sie den Nutzer auffordern, Ihre App als Standard-Handler für eine Hauptfunktion des Systems festzulegen, bevor Sie diese Laufzeitberechtigungen anfordern.

Weitere Informationen zu Standard-Handlern, einschließlich einer Anleitung zum Anzeigen einer Aufforderung für Standard-Handler, findest du 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:

• Berechtigungen – Übersicht
• Best Practices für App-Berechtigungen

Weitere Informationen zum Anfordern von Berechtigungen finden Sie in den Beispielen für Berechtigungen.

Sie können auch dieses Codelab zu Best Practices für den Datenschutz durcharbeiten.