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.

Hinweis :Einige Berechtigungen schützen den Zugriff auf Systemressourcen, die besonders vertraulich sind oder nicht direkt mit dem Datenschutz zusammenhängen. Für diese besonderen Berechtigungen ist ein anderes Verfahren erforderlich.

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 mit Android 5.1 (API-Level 22) oder niedriger installiert ist, werden die Berechtigungen automatisch erteilt und Sie müssen keinen der verbleibenden Schritte auf dieser Seite ausführen.

Grundprinzipien

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

• Fragen Sie nach einer Berechtigung im Kontext, wenn der Nutzer mit der Funktion interagiert, für die sie erforderlich ist.
• Blockieren Sie den Nutzer nicht. Bieten Sie immer die Möglichkeit, einen UI-Ablauf abzubrechen, z. B. einen Ablauf, in dem die Gründe für das Anfordern 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. Gehen Sie 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 Sie Laufzeitberechtigungen in Ihrer App deklarieren und anfordern, sollten Sie prüfen, ob dies erforderlich ist. Viele Anwendungsfälle in Ihrer App, z. B. das Aufnehmen von Fotos, das Pausieren der Medienwiedergabe und das Anzeigen relevanter Anzeigen, können ohne Deklaration von Berechtigungen realisiert werden.

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

1. Deklarieren Sie in der Manifestdatei Ihrer App die Berechtigungen, die Ihre App möglicherweise anfordern muss.
2. Gestalten Sie die Benutzeroberfläche Ihrer App so, dass bestimmte Aktionen in Ihrer App mit bestimmten Laufzeitberechtigungen verknüpft sind. Informieren Sie Nutzer darüber, für welche Aktionen sie Ihrer App möglicherweise die Berechtigung zum Zugriff auf private Nutzerdaten erteilen müssen.
3. Warten Sie, bis der Nutzer die Aufgabe oder Aktion in Ihrer App aufruft, für die Zugriff auf bestimmte private Nutzerdaten erforderlich ist. Zu diesem Zeitpunkt kann Ihre App die Laufzeitberechtigung anfordern, die für den Zugriff auf diese Daten erforderlich ist.

4. Prüfen Sie, ob der Nutzer die Laufzeitberechtigung, die Ihre App benötigt, bereits erteilt hat. Wenn ja, 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, in der erklärt wird, warum Ihre App eine bestimmte Laufzeitberechtigung benötigt. Wenn das System feststellt, dass für Ihre App keine Begründung angezeigt werden sollte, fahren Sie direkt mit dem nächsten Schritt fort, ohne ein UI-Element anzuzeigen.

   Wenn das System feststellt, dass in Ihrer App eine Begründung angezeigt werden sollte, präsentieren Sie die Begründung dem Nutzer in einem UI-Element. Erklären Sie in dieser Begründung deutlich, auf welche Daten Ihre App zugreifen möchte und welche Vorteile die App dem Nutzer bietet, wenn er die Laufzeitberechtigung erteilt. Fahren Sie mit dem nächsten Schritt fort, nachdem der Nutzer die Begründung bestätigt hat.

6. Fordern Sie die Laufzeitberechtigung an, die Ihre App für den Zugriff auf die privaten Nutzerdaten benötigt. Das System zeigt eine Laufzeitberechtigungsaufforderung an, z. B. die auf der Seite Berechtigungsübersicht gezeigte.

7. Prüfen Sie die Antwort des Nutzers, um festzustellen, ob er die Laufzeitberechtigung erteilt oder verweigert hat.

8. Wenn der Nutzer Ihrer App die Berechtigung gewährt hat, können Sie auf die privaten Nutzerdaten zugreifen. Wenn der Nutzer die Berechtigung stattdessen abgelehnt hat, sollten Sie die App-Nutzung so anpassen, dass sie dem Nutzer auch ohne die durch diese Berechtigung geschützten Informationen Funktionen 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 Sie, warum Ihre App die Berechtigung benötigt.

Im Berechtigungsdialogfeld, das vom System angezeigt wird, wenn Sie requestPermissions() aufrufen, wird angegeben, welche Berechtigung Ihre App benötigt, aber nicht warum. In einigen Fällen kann das für den Nutzer verwirrend sein. Es ist ratsam, 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 die Berechtigungen benötigt, z. B. ob sie für eine Kernfunktion der App oder für Werbung erforderlich sind. Wenn Sie also nur einen Teil der API-Aufrufe verwenden, die unter eine Berechtigungsgruppe fallen, sollten Sie explizit angeben, welche dieser Berechtigungen Sie verwenden und warum. Wenn Sie beispielsweise nur den ungefähren Standort verwenden, teilen Sie dies dem Nutzer in Ihrer App-Beschreibung oder in Hilfeartikeln zu Ihrer App mit.

Unter bestimmten Umständen ist es auch hilfreich, Nutzer in Echtzeit über den Zugriff auf vertrauliche Daten zu informieren. Wenn Sie beispielsweise auf die Kamera oder das Mikrofon zugreifen, sollten Sie den Nutzer darüber informieren. Verwenden Sie dazu ein Benachrichtigungssymbol in Ihrer App oder in der Benachrichtigungsleiste (wenn die Anwendung im Hintergrund ausgeführt wird). So wird nicht der Eindruck erweckt, dass Sie Daten heimlich erheben.

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

Wenn Sie eine Berechtigung benötigen, damit etwas in Ihrer App funktioniert, der Grund dafür aber für den Nutzer nicht klar ist, sollten Sie ihm erklären, warum Sie die sensibelsten Berechtigungen benötigen.

Wenn die Methode ContextCompat.checkSelfPermission() PERMISSION_DENIED zurückgibt, rufen Sie shouldShowRequestPermissionRationale() auf. Wenn diese Methode true zurückgibt, 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 den Standort, das Mikrofon oder die Kamera anfordert, sollten Sie erläutern, warum Ihre App Zugriff auf diese Informationen benötigt.

Berechtigungen anfordern

Nachdem der Nutzer eine Benutzeroberfläche mit Informationen gesehen hat oder der Rückgabewert von shouldShowRequestPermissionRationale() angibt, dass Sie keine Benutzeroberfläche mit Informationen anzeigen müssen, fordern Sie die Berechtigung an. Nutzer sehen ein Systemdialogfeld für Berechtigungen, in dem sie auswählen können, ob sie Ihrer App eine bestimmte Berechtigung erteilen möchten.

Verwenden Sie dazu den RequestPermission-Vertrag, der in einer AndroidX-Bibliothek enthalten ist, und erlauben Sie dem System, den Berechtigungsanforderungscode für Sie zu verwalten. Da die Verwendung des RequestPermission-Vertrags Ihre Logik vereinfacht, ist dies die empfohlene Lösung, sofern möglich. Bei Bedarf können Sie jedoch auch selbst einen Anfragecode verwalten und diesen in Ihre Berechtigungs-Callback-Logik einfügen.

Dem System erlauben, den Berechtigungsanfragecode zu verwalten

Damit das System den mit einer Berechtigungsanfrage verknüpften Anfragecode verwalten kann, fügen Sie der Datei build.gradle 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:

• 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 Prozess ist für den RequestMultiplePermissions-Vertrag nahezu identisch.

1. Übergeben Sie in der Initialisierungslogik Ihrer Aktivität oder Ihres Fragments eine Implementierung von ActivityResultCallback in einen Aufruf von registerForActivityResult(). Die ActivityResultCallback definiert, wie Ihre 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. Rufen Sie die Methode launch() für die Instanz von ActivityResultLauncher auf, die Sie im vorherigen Schritt gespeichert haben, um das Dialogfeld für Systemberechtigungen bei Bedarf anzuzeigen.

   Nachdem launch() aufgerufen wurde, wird das Dialogfeld für 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 : In Ihrer App kann das Dialogfeld, das beim Aufrufen von launch() angezeigt wird, nicht angepasst werden. Um dem Nutzer mehr Informationen oder Kontext zu geben, ändern Sie die Benutzeroberfläche Ihrer App so, dass Nutzer leichter nachvollziehen können, warum für eine Funktion in Ihrer App eine bestimmte Berechtigung erforderlich ist. Sie können beispielsweise den Text auf der Schaltfläche ändern, mit der die Funktion aktiviert wird.

   Außerdem wird im Text des Systemberechtigungsdialogs auf die Berechtigungsgruppe verwiesen, die mit der von Ihnen angeforderten Berechtigung verknüpft ist. Diese Berechtigungsgruppierung soll die Verwendung des Systems vereinfachen. Ihre App sollte nicht darauf angewiesen sein, dass Berechtigungen innerhalb oder außerhalb einer bestimmten Berechtigungsgruppe liegen.

Das folgende Code-Snippet zeigt, wie die Berechtigungsantwort verarbeitet wird:

Kotlin

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher. You can use either a val, as shown in this snippet,
// or a lateinit var in your onAttach() or onCreate() method.
val requestPermissionLauncher =
    registerForActivityResult(RequestPermission()
    ) { isGranted: Boolean ->
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // feature requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    }

Java

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher, as an instance variable.
private ActivityResultLauncher<String> requestPermissionLauncher =
    registerForActivityResult(new RequestPermission(), isGranted -> {
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // feature requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    });

Dieser Code-Snippet zeigt 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);
}

Code für Berechtigungsanfrage selbst verwalten

Alternativ dazu, dass das System den Berechtigungsanforderungscode verwaltet, können Sie den Berechtigungsanforderungscode selbst verwalten. Fügen Sie dazu den Anforderungscode in einen Aufruf von requestPermissions() ein.

Hinweis :Ihre App kann das Dialogfeld, das beim Aufrufen von requestPermissions() angezeigt wird, nicht anpassen. Im Dialogfeld für Systemberechtigungen wird auf eine Berechtigungsgruppe verwiesen. Diese Gruppierung von Berechtigungen dient jedoch nur der Benutzerfreundlichkeit des Systems. Ihre App sollte nicht darauf angewiesen sein, dass Berechtigungen innerhalb oder außerhalb einer bestimmten Berechtigungsgruppe liegen.

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 Systemberechtigungen geantwortet hat, ruft das System die Implementierung von onRequestPermissionsResult() in Ihrer App auf. Das System übergibt die Nutzerantwort auf das Berechtigungsdialogfeld sowie den von Ihnen definierten Anfragecode, wie im folgenden Code-Snippet gezeigt:

Kotlin

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

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

Java

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

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 Standortberechtigungen besteht darin, dass das System mehrere Berechtigungen im Zusammenhang mit dem Standort umfasst. Welche Berechtigungen Sie anfordern und wie Sie sie anfordern, hängt von den Standortanforderungen für den Anwendungsfall Ihrer App ab.

Vordergrundposition

Wenn Ihre App eine Funktion enthält, die Standortinformationen nur einmal oder für einen bestimmten Zeitraum weitergibt 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 mit einer Funktion 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, informiert das System den Nutzer durch eine dauerhafte Benachrichtigung. Ihre App behält den Zugriff bei, wenn sie in den Hintergrund verschoben wird, z. B. wenn der Nutzer die Startbildschirmtaste auf seinem Gerät drückt oder das Display seines Geräts ausschaltet.

  Unter Android 10 (API-Level 29) und höher müssen Sie einen Typ für Dienste im Vordergrund von location deklarieren, wie im folgenden Code-Snippet gezeigt. In 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 deklarieren einen Bedarf an der 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

Für eine App ist der Zugriff auf den Standort im Hintergrund erforderlich, 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 nach Hause kommt.

Das System geht davon aus, dass Ihre App den Standort im Hintergrund verwendet, wenn sie in einer anderen Situation als den im Abschnitt Standort im Vordergrund beschriebenen auf den aktuellen Standort des Geräts zugreift. Die Genauigkeit des Standorts im Hintergrund ist dieselbe wie die Genauigkeit des Standorts im Vordergrund. Sie hängt von den von Ihrer App deklarierten Standortberechtigungen ab.

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 den Standort im Hintergrund anzufordern. In früheren Android-Versionen erhält Ihre App automatisch auch den Standortzugriff im Hintergrund, wenn sie den Standortzugriff 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 Richtlinie zum Standort in Bezug auf den Gerätestandort, die den Zugriff auf den Standort im Hintergrund auf Apps beschränkt, die ihn für ihre Hauptfunktionen benötigen und die entsprechenden Richtlinienanforderungen erfüllen.

Umgang mit verweigerter Berechtigung

Wenn der Nutzer eine Berechtigungsanfrage ablehnt, sollte Ihre App ihm helfen, die Auswirkungen der Ablehnung zu verstehen. Ihre App sollte Nutzer insbesondere auf Funktionen hinweisen, die aufgrund der fehlenden Berechtigung nicht funktionieren. Beachten Sie dabei die folgenden Best Practices:

• Die Aufmerksamkeit des Nutzers lenken: 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:

  • Eine Meldung wird angezeigt, in der die Ergebnisse oder Daten der Funktion zu sehen gewesen wären.
  • Zeige eine andere Schaltfläche mit einem Fehlersymbol und einer Fehlerfarbe an.

• Machen Sie möglichst genaue Angaben. Keine allgemeine Meldung anzeigen Machen Sie stattdessen deutlich, welche Funktionen nicht verfügbar sind, weil Ihre App nicht die erforderliche Berechtigung hat.

• Benutzeroberfläche nicht blockieren: Das heißt, Sie sollten keine Vollbild-Warnmeldung anzeigen, die Nutzer daran hindert, Ihre App weiter zu verwenden.

Tipp :Ihre App sollte auch nach der Ablehnung von Berechtigungen eine möglichst gute Nutzerfreundlichkeit bieten. Wenn beispielsweise der Mikrofonzugriff verweigert wird, sollten Sie trotzdem die volle Nutzbarkeit der Textfunktionen bewerben.

Gleichzeitig sollte Ihre App die Entscheidung des Nutzers, eine Berechtigung zu verweigern, respektieren. Ab Android 11 (API-Level 30) gilt: Wenn der Nutzer während der Lebensdauer der Installation Ihrer App auf einem Gerät mehr als einmal auf Ablehnen für eine bestimmte Berechtigung tippt, wird das Systemberechtigungsdialogfeld nicht mehr angezeigt, wenn Ihre App diese Berechtigung noch einmal anfordert. Die Aktion des Nutzers impliziert „Nicht mehr fragen“. In früheren Versionen wurde Nutzern das Dialogfeld für Systemberechtigungen jedes Mal angezeigt, wenn Ihre App eine Berechtigung angefordert hat, es sei denn, sie hatten zuvor ein Kästchen oder eine Option vom Typ „Nicht noch einmal fragen“ ausgewählt.

Wenn ein Nutzer eine Berechtigungsanfrage mehrmals ablehnt, gilt dies als dauerhafte Ablehnung. Es ist sehr wichtig, Nutzer nur dann nach Berechtigungen zu fragen, wenn sie Zugriff auf eine bestimmte Funktion benötigen. Andernfalls verlieren Sie möglicherweise unbeabsichtigt die Möglichkeit, Berechtigungen noch einmal anzufordern.

In bestimmten Situationen kann die Berechtigung automatisch verweigert werden, ohne dass der Nutzer etwas unternimmt. Eine Berechtigung kann auch automatisch gewährt werden. Sie sollten nichts über das automatische Verhalten annehmen. Jedes Mal, wenn Ihre App auf Funktionen zugreifen muss, für die eine Berechtigung erforderlich ist, sollten Sie prüfen, ob Ihre App diese Berechtigung noch hat.

Weitere Informationen dazu, wie Sie die Nutzerfreundlichkeit beim Anfordern von App-Berechtigungen optimieren 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 ermitteln, 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, sind mit USER_SET gekennzeichnet. Berechtigungen, die durch zweimaliges Auswählen von Ablehnen dauerhaft abgelehnt wurden, sind mit USER_FIXED gekennzeichnet.

Damit Tester das Anforderungsdialogfeld während des Tests sehen, müssen Sie diese Flags zurücksetzen, wenn Sie mit dem Debugging Ihrer App fertig sind. Verwenden Sie dazu den folgenden Befehl:

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

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

Eine vollständige Liste der Android-App-Berechtigungen finden Sie auf der Referenzseite zur Permissions API.

Einmalige Berechtigungen

Abbildung 2. Systemdialogfeld, das angezeigt wird, wenn eine App eine einmalige Berechtigung anfordert.

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

Ihre App kann dann für einen Zeitraum, der vom Verhalten Ihrer App und den Aktionen des Nutzers abhängt, auf die entsprechenden Daten zugreifen:

• Solange die Aktivitäten Ihrer App sichtbar sind, kann Ihre App auf die Daten zugreifen.
• Wenn der Nutzer Ihre App in den Hintergrund sendet, kann Ihre App für kurze Zeit weiterhin 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 die Berechtigung widerrufen wird

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

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

Hinweis :Wenn Ihre App bereits den Best Practices entspricht, wenn sie Laufzeitberechtigungen anfordert, müssen Sie keine Logik in Ihrer App hinzufügen oder ändern, um Einmalberechtigungen zu unterstützen.

Nicht verwendete Berechtigungen zurücksetzen

Android bietet mehrere Möglichkeiten, nicht verwendete Laufzeitberechtigungen auf ihren Standardstatus „Verweigert“ 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. Wenn Sie Ihre App aktualisieren, sollten Sie diesen Schritt ausführen, damit die Nutzer besser nachvollziehen können, warum Ihre App weiterhin bestimmte Berechtigungen anfordert. So können Sie das Vertrauen der Nutzer in Ihre App 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 der Berechtigung 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 Prozesse, die mit Ihrer App verknüpft sind, beendet werden. Wenn Sie die API aufrufen, bestimmt das System, wann es sicher ist, diese Prozesse zu beenden. Normalerweise wartet das System, bis Ihre App längere Zeit im Hintergrund statt im Vordergrund ausgeführt wird.

Informieren Sie den Nutzer darüber, dass Ihre App keinen Zugriff mehr auf bestimmte Laufzeitberechtigungen benötigt, indem Sie beim nächsten Start der App ein Dialogfeld einblenden, das die Liste der Berechtigungen enthalten kann.

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 Nutzerdaten, indem es die sensiblen Laufzeitberechtigungen, die der Nutzer Ihrer App erteilt hat, automatisch zurücksetzt. Weitere Informationen finden Sie im Leitfaden zum Ruhezustand von Apps.

Bei Bedarf als Standard-Handler registrieren

Einige Apps sind auf den Zugriff auf vertrauliche Nutzerinformationen in Bezug auf Anruflisten und SMS angewiesen. Wenn Sie die Berechtigungen für Anruflisten und SMS-Nachrichten 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 wichtige Systemfunktion festzulegen, bevor Sie diese Laufzeitberechtigungen anfordern.

Weitere Informationen zu Standard-Handlern, einschließlich einer Anleitung zum Anzeigen einer Aufforderung für Standard-Handler für Nutzer, finden Sie im Leitfaden zu Berechtigungen, die nur in Standard-Handlern verwendet werden.

Alle Laufzeitberechtigungen zu Testzwecken gewähren

Wenn Sie alle Laufzeitberechtigungen automatisch erteilen 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:

• Berechtigungsübersicht
• Best Practices für App-Berechtigungen

Weitere Informationen zum Anfordern von Berechtigungen

Sie können auch dieses Codelab durcharbeiten, in dem Best Practices für den Datenschutz vorgestellt werden.