Laufzeitberechtigungen anfordern

Jede Android-App wird in einer Sandbox mit beschränktem Zugriff ausgeführt. Wenn Ihre App Ressourcen oder Informationen außerhalb ihrer eigenen Sandbox verwenden muss, können Sie eine Laufzeitberechtigung deklarieren und eine Berechtigungsanfrage einrichten, die diesen Zugriff ermöglicht. Diese Schritte sind Teil des Workflows zur Verwendung von Berechtigungen.

Hinweis: Einige Berechtigungen schützen den Zugriff auf Systemressourcen, die besonders sensibel sind oder keinen direkten Bezug zur Privatsphäre der Nutzer haben. Für diese besonderen Berechtigungen ist ein anderer Vorgang 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 gewährt und Sie müssen keine der verbleibenden Schritte auf dieser Seite ausführen.

Grundprinzipien

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

• Sie können eine Berechtigung im Kontext anfordern, wenn der Nutzer mit der Funktion interagiert, für die sie erforderlich ist.
• Blockieren Sie den Nutzer nicht. Bieten Sie Nutzern immer die Möglichkeit, einen UI-Vorgang abbrechen zu können, in dem beispielsweise erläutert wird, warum Berechtigungen angefordert werden.
• Wenn Nutzer eine Berechtigung, die für eine Funktion erforderlich ist, ablehnen oder widerrufen, ermöglichen Sie Ihren Nutzern durch graduelle Fehlertoleranz, Ihre App weiterhin zu verwenden. Möglicherweise können Sie die Funktion deaktivieren, für die Sie die Berechtigung oder die entsprechenden Daten benötigen.
• Gehen Sie nicht von einem bestimmten Systemverhalten aus. 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 miteinander verbundene Berechtigungen anfordert.

Workflow zum Anfordern von Berechtigungen

Bevor Sie Laufzeitberechtigungen in Ihrer App deklarieren und anfordern, sollten Sie prüfen, ob dies für Ihre App erforderlich ist. Sie können viele Anwendungsfälle in Ihrer App erfüllen, z. B. Fotos aufnehmen, die Medienwiedergabe pausieren und relevante Anzeigen schalten, ohne Berechtigungen deklarieren zu müssen.

Wenn Sie zu dem Schluss kommen, dass für Ihre App Laufzeitberechtigungen erklärt und angefordert werden müssen, 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 UX Ihrer App so, dass bestimmte Aktionen in Ihrer App mit bestimmten Laufzeitberechtigungen verknüpft sind. Informieren Sie die Nutzer darüber, für welche Aktionen sie Ihrer App möglicherweise die Berechtigung zum Zugriff auf private Nutzerdaten erteilen müssen.
3. Warten Sie, bis der Nutzer die Aufgabe oder Aktion in Ihrer App ausführt, für die Zugriff auf bestimmte personenbezogene Nutzerdaten erforderlich ist. Zu diesem Zeitpunkt kann Ihre App die Laufzeitberechtigung anfordern, die für den Zugriff auf diese Daten erforderlich ist.

4. Prüfen Sie, ob der Nutzer bereits die Laufzeitberechtigung erteilt hat, die Ihre App benötigt. In diesem Fall kann Ihre App auf die privaten Nutzerdaten zugreifen. Sollte dies nicht der Fall sein, fahren Sie mit dem nächsten Schritt fort.

   Sie müssen jedes Mal prüfen, ob Sie über eine Berechtigung verfügen, wenn Sie einen Vorgang ausführen, für den diese Berechtigung erforderlich ist.

5. Prüfen Sie, ob Ihre App Nutzern eine Begründung anzeigen sollte, warum Ihre App eine bestimmte Laufzeitberechtigung benötigt. Wenn das System feststellt, dass Ihre App keine Begründung enthalten sollte, fahren Sie direkt mit dem nächsten Schritt fort, ohne ein UI-Element anzuzeigen.

   Wenn das System jedoch feststellt, dass Ihre App eine Begründung enthalten sollte, müssen Sie sie dem Nutzer in einem UI-Element präsentieren. Erläutern Sie in dieser Begründung klar, auf welche Daten Ihre App zugreifen möchte und welche Vorteile die App für den Nutzer bietet, wenn er die Laufzeitberechtigung erteilt. Nachdem der Nutzer die Begründung akzeptiert 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, z. B. die auf der Übersichtsseite für Berechtigungen.

7. Prüfen Sie die Antwort des Nutzers, um festzustellen, ob er die Laufzeitberechtigung erteilt oder abgelehnt 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 abgelehnt hat, reduzieren Sie die Funktionalität Ihrer App, damit der Nutzer Funktionen nutzen kann, ohne dass die durch diese Berechtigung geschützten Informationen verwendet werden.

Abbildung 1 zeigt den Workflow und die damit verbundenen Entscheidungen:

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

Prüfen, ob Ihrer App die Berechtigung bereits gewährt wurde

Wenn Sie prüfen möchten, ob der Nutzer Ihrer App bereits eine bestimmte Berechtigung erteilt hat, übergeben Sie diese Berechtigung an die Methode ContextCompat.checkSelfPermission(). Diese Methode gibt entweder PERMISSION_GRANTED oder PERMISSION_DENIED zurück, je nachdem, ob Ihre App die Berechtigung hat.

Erläutern Sie, warum Ihre App die Berechtigung benötigt

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 Nutzer verwirrend sein. Es ist empfehlenswert, dem Nutzer zu erklären, warum Ihre App die Berechtigungen benötigt, bevor Sie requestPermissions() aufrufen.

Studien haben gezeigt, dass Nutzer Berechtigungsanfragen viel eher akzeptieren, wenn sie wissen, warum die App sie benötigt. So kann es beispielsweise sein, dass die Berechtigung für eine Hauptfunktion der App oder für Werbung erforderlich ist. Wenn Sie also nur einen Teil der API-Aufrufe verwenden, die zu einer Berechtigungsgruppe gehören, sollten Sie explizit angeben, welche dieser Berechtigungen Sie verwenden und warum. Wenn Sie beispielsweise nur die grobe Standortermittlung verwenden, informieren Sie die Nutzer in der App-Beschreibung oder in Hilfeartikeln zu Ihrer App darüber.

Unter bestimmten Bedingungen 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 im Benachrichtigungs-Tray, wenn die App im Hintergrund ausgeführt wird. So entsteht nicht der Eindruck, dass Sie Daten heimlich erheben.

Hinweis :Seit Android 12 (API-Level 31) werden Nutzer über Datenschutzanzeigen benachrichtigt, wenn Apps auf das Mikrofon oder die Kamera zugreifen.

Wenn Sie eine Berechtigung anfordern müssen, damit eine Funktion in Ihrer App funktioniert, der Grund für den Nutzer jedoch nicht klar ist, sollten Sie ihm erklären, warum Sie die sensibleren Berechtigungen benötigen.

Wenn die ContextCompat.checkSelfPermission()-Methode PERMISSION_DENIED zurückgibt, rufe shouldShowRequestPermissionRationale() auf. Wenn diese Methode true zurückgibt, zeigen Sie dem Nutzer eine informative Benutzeroberfläche an. Beschreiben Sie in dieser Benutzeroberfläche, warum für die Funktion, die der Nutzer aktivieren möchte, eine bestimmte Berechtigung erforderlich ist.

Wenn Ihre App eine Berechtigung für die Standortermittlung, das Mikrofon oder die Kamera anfordert, sollten Sie außerdem erläutern, warum Ihre App auf diese Informationen zugreifen muss.

Berechtigungen anfordern

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

Verwenden Sie dazu den Vertrag RequestPermission, der in einer AndroidX-Bibliothek enthalten ist. Hier können Sie dem System erlauben, den Code für die Berechtigungsanfrage für Sie zu verwalten. Da die Verwendung des RequestPermission-Vertrags die Logik vereinfacht, wird diese Lösung nach Möglichkeit empfohlen. Bei Bedarf können Sie jedoch auch einen Anfragecode selbst verwalten, der Teil der Berechtigungsanfrage ist, und diesen Anfragecode in Ihre Berechtigungs-Callback-Logik einbinden.

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

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

• androidx.activity, Version 1.2.0 oder hö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 Ablauf ist für den RequestMultiplePermissions-Vertrag nahezu identisch.

1. Geben Sie in der Initialisierungslogik Ihrer Aktivität oder Ihres Fragments eine Implementierung von ActivityResultCallback an einen Aufruf von registerForActivityResult() weiter. Mit der ActivityResultCallback wird festgelegt, wie Ihre App mit der Antwort des Nutzers auf die Berechtigungsanfrage umgeht.

   Behalten Sie einen Verweis auf den Rückgabewert von registerForActivityResult(), der vom Typ ActivityResultLauncher ist.

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

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

   Hinweis : Ihre App kann das Dialogfeld, das beim Aufrufen von launch() angezeigt wird, nicht anpassen. Um den Nutzern mehr Informationen oder Kontext zu bieten, ändern Sie die Benutzeroberfläche Ihrer App so, dass sie leichter verstehen können, warum eine Funktion in Ihrer App eine bestimmte Berechtigung benötigt. Sie können beispielsweise den Text auf der Schaltfläche ändern, mit der die Funktion aktiviert wird.

   Außerdem bezieht sich der Text im Dialogfeld für die Systemberechtigung auf die Berechtigungsgruppe, die mit der von Ihnen angeforderten Berechtigung verknüpft ist. Diese Berechtigungsgruppierung wurde für die Nutzerfreundlichkeit des Systems entwickelt. Ihre App sollte nicht davon abhängen, ob Berechtigungen zu einer bestimmten Berechtigungsgruppe gehören oder nicht.

Das folgende Code-Snippet zeigt, wie die Antwort zu den Berechtigungen verarbeitet wird:

Kotlin

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

Java

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

Dieses Code-Snippet veranschaulicht den empfohlenen Prozess zum Prüfen einer Berechtigung und zum Anfordern einer Berechtigung vom Nutzer, falls erforderlich:

Kotlin

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

Java

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

Code für Berechtigungsanfragen selbst verwalten

Sie können den Code für die Berechtigungsanfrage vom System verwalten lassen oder selbst verwalten. Fügen Sie dazu den Anfragecode in einen Aufruf von requestPermissions() ein.

Hinweis: Sie können das Dialogfeld, das beim Aufrufen von requestPermissions() angezeigt wird, nicht anpassen. Der Text im Dialogfeld für die Systemberechtigung bezieht sich auf eine Berechtigungsgruppe. Diese Berechtigungsgruppierung dient jedoch der Nutzerfreundlichkeit des Systems. Ihre App sollte nicht davon ausgehen, dass Berechtigungen zu einer bestimmten Berechtigungsgruppe gehören oder nicht.

Das folgende Code-Snippet zeigt, wie eine Berechtigung mit einem Anfragecode angefordert wird:

Kotlin

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

Java

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

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

Kotlin

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

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

Java

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

Berechtigungen zur Standortermittlung anfordern

Beachten Sie beim Anfordern von Berechtigungen zur Standortermittlung dieselben Best Practices wie bei anderen Laufzeitberechtigungen. Ein wichtiger Unterschied bei Standortberechtigungen besteht darin, dass das System mehrere standortbezogene Berechtigungen umfasst. Welche Berechtigungen Sie anfordern und wie Sie sie anfordern, hängt von den Standortanforderungen für den Anwendungsfall Ihrer App ab.

Standortermittlung im Vordergrund

Wenn Ihre App eine Funktion enthält, die Standortinformationen nur einmal oder für einen bestimmten Zeitraum freigibt oder empfängt, ist für diese Funktion der Zugriff auf die Standortermittlung im Vordergrund erforderlich. Beispiele:

• In einer Navigations-App können Nutzer mit einer Funktion eine detaillierte Routenführung erhalten.
• In einer Messaging-App können Nutzer über eine Funktion ihren aktuellen Standort mit einem anderen Nutzer teilen.

Das System geht davon aus, dass Ihre App die Standortermittlung im Vordergrund verwendet, wenn eine Funktion Ihrer App in einer der folgenden Situationen auf den aktuellen Standort des Geräts zugreift:

• Eine Aktivität, die zu Ihrer App gehört, ist sichtbar.

• Ihre App führt einen Dienst im Vordergrund aus. Wenn ein Dienst im Vordergrund ausgeführt wird, wird der Nutzer durch eine dauerhafte Benachrichtigung darauf aufmerksam gemacht. Ihre App behält den Zugriff, wenn sie im Hintergrund ausgeführt wird, z. B. wenn der Nutzer die Startbildschirmtaste auf seinem Gerät drückt oder das Display ausschaltet.

  Unter Android 10 (API-Level 29) und höher müssen Sie einen Typ für Dienste im Vordergrund von location deklarieren, wie im folgenden Code-Snippet dargestellt. Bei früheren Android-Versionen wird empfohlen, diesen Diensttyp im Vordergrund zu deklarieren.

  <!-- Recommended for Android 9 (API level 28) and lower. -->
  <!-- Required for Android 10 (API level 29) and higher. -->
  <service
      android:name="MyNavigationService"
      android:foregroundServiceType="location" ... >
      <!-- Any inner elements go here. -->
  </service>
  

Sie erklären, dass Ihre App die Standortermittlung im Vordergrund benötigt, wenn sie entweder die Berechtigung ACCESS_COARSE_LOCATION oder die Berechtigung ACCESS_FINE_LOCATION anfordert, wie im folgenden Snippet dargestellt:

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

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

Standortermittlung im Hintergrund

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

• In einer App zur Standortfreigabe für Familien können Nutzer ihren Standort kontinuierlich mit Familienmitgliedern teilen.
• Mit einer Funktion in einer IoT-App können Nutzer ihre Haushaltsgeräte so konfigurieren, dass sie sich ausschalten, wenn der Nutzer das Haus verlässt, und wieder einschalten, wenn er nach Hause zurückkehrt.

Das System betrachtet Ihre App als App, die die Standortermittlung im Hintergrund verwendet, wenn sie in einer anderen Situation als den im Abschnitt Standortermittlung im Vordergrund beschriebenen Fällen auf den aktuellen Standort des Geräts zugreift. Die Genauigkeit der Standortermittlung im Hintergrund entspricht der Genauigkeit der Standortermittlung im Vordergrund, die von den von Ihrer App angegebenen Berechtigungen für die Standortermittlung abhängt.

Unter Android 10 (API-Level 29) und höher müssen Sie die Berechtigung ACCESS_BACKGROUND_LOCATION im Manifest Ihrer App deklarieren, um zur Laufzeit Zugriff auf die Standortermittlung im Hintergrund anzufordern. In früheren Android-Versionen erhält Ihre App, wenn sie den Zugriff auf den Standort im Vordergrund erhält, automatisch auch den Zugriff auf den Standort im Hintergrund.

<manifest ... >
  <!-- Required only when requesting background location access on
       Android 10 (API level 29) and higher. -->
  <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</manifest>

Hinweis :Der Google Play Store hat eine Richtlinie zum Standort für Geräte, 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.

Abgelehnte Berechtigung verarbeiten

Wenn der Nutzer eine Berechtigungsanfrage ablehnt, sollte Ihre App ihm helfen zu verstehen, welche Auswirkungen die Ablehnung der Berechtigung hat. Insbesondere sollten Nutzer in Ihrer App auf die Funktionen hingewiesen werden, die aufgrund der fehlenden Berechtigung nicht funktionieren. Beachten Sie dabei die folgenden Best Practices:

• Lenken Sie die Aufmerksamkeit der Nutzer. Heben Sie einen bestimmten Teil der Benutzeroberfläche Ihrer App hervor, bei dem die Funktionalität eingeschränkt ist, weil Ihre App nicht die erforderliche Berechtigung hat. Beispiele für mögliche Maßnahmen:

  • Eine Meldung an der Stelle anzeigen, an der die Ergebnisse oder Daten der Funktion angezeigt werden würden.
  • Eine andere Schaltfläche mit einem Fehlersymbol und einer Fehlerfarbe anzeigen

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

• Blockieren Sie nicht die Benutzeroberfläche. Das bedeutet, dass Sie keine Vollbildwarnung anzeigen dürfen, die Nutzer daran hindert, Ihre App weiter zu verwenden.

Tipp :Ihre App sollte auch nach einer Ablehnung von Berechtigungen möglichst nutzerfreundlich sein. Wenn der Mikrofonzugriff beispielsweise abgelehnt wird, sollten Sie dennoch für die volle Nutzerfreundlichkeit der Textfunktion werben.

Gleichzeitig sollte Ihre App die Entscheidung des Nutzers respektieren, eine Berechtigung abzulehnen. Ab Android 11 (API-Level 30) wird Nutzern, die während der Lebensdauer der Installation Ihrer App auf einem Gerät mehrmals auf Ablehnen für eine bestimmte Berechtigung tippen, das Dialogfeld für Systemberechtigungen nicht angezeigt, wenn Ihre App diese Berechtigung noch einmal anfordert. Die Aktion des Nutzers bedeutet „Nicht mehr fragen“. In früheren Versionen wurde Nutzern jedes Mal, wenn Ihre App eine Berechtigung anforderte, das Dialogfeld für Systemberechtigungen angezeigt, es sei denn, sie hatten zuvor ein Kästchen oder eine Option für „Nicht noch einmal fragen“ angeklickt.

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

In bestimmten Situationen wird die Berechtigung möglicherweise automatisch abgelehnt, ohne dass der Nutzer etwas unternehmen muss. Eine Berechtigung kann auch automatisch gewährt werden. Es ist wichtig, nichts über automatisches Verhalten anzunehmen. Prüfen Sie jedes Mal, wenn Ihre App auf Funktionen zugreifen muss, für die eine Berechtigung erforderlich ist, ob Ihre App diese Berechtigung weiterhin hat.

Informationen zum Erzielen der besten Benutzererfahrung bei der Abfrage von App-Berechtigungen finden Sie unter Best Practices für App-Berechtigungen.

Ablehnungsstatus beim Testen und Beheben von Fehlern prüfen

Mit dem folgenden Befehl können Sie prüfen, ob einer App Berechtigungen dauerhaft verweigert wurden (zum Debuggen und Testen):

adb shell dumpsys package PACKAGE_NAME

Dabei ist PACKAGE_NAME der Name des zu prüfenden Pakets.

Die Ausgabe des Befehls enthält Abschnitte, die so aussehen:

...
runtime permissions:
  android.permission.POST_NOTIFICATIONS: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.ACCESS_FINE_LOCATION: granted=false, flags=[ USER_SET|USER_FIXED|USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.BLUETOOTH_CONNECT: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
...

Berechtigungen, die vom Nutzer einmal abgelehnt wurden, sind mit USER_SET gekennzeichnet. Berechtigungen, die dauerhaft abgelehnt wurden, indem Sie zweimal Ablehnen ausgewählt haben, werden mit USER_FIXED gekennzeichnet.

Damit Tester das Dialogfeld für die Anfrage während des Tests sehen, setzen Sie diese Flags zurück, wenn Sie mit dem Debuggen Ihrer App fertig sind. Verwenden Sie dazu den Befehl:

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

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

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

Einmalige Berechtigungen

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

Ab Android 11 (API-Ebene 30) enthält das Berechtigungsdialogfeld für Nutzer, in dem Ihre App eine Berechtigung für die Standortermittlung, das Mikrofon oder die Kamera anfordert, die Option Nur dieses Mal, wie in Abbildung 2 dargestellt. Wenn der Nutzer diese Option im Dialogfeld auswählt, wird Ihrer App eine vorübergehende einmalige Berechtigung gewährt.

Ihre App kann dann für einen Zeitraum auf die zugehörigen Daten zugreifen, der vom Verhalten Ihrer App und den Aktionen der Nutzer abhängt:

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

App-Prozess wird beendet, wenn Berechtigung widerrufen wird

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

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

Hinweis :Wenn Ihre App bereits Best Practices beim Anfordern von Laufzeitberechtigungen befolgt, müssen Sie keine Logik in Ihrer 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 proaktiv den Zugriff Ihrer App auf eine nicht verwendete Laufzeitberechtigung entfernen können.
• Ein Systemmechanismus, der die Berechtigungen nicht verwendeter Apps automatisch zurücksetzt.

App-Zugriff entfernen

Unter Android 13 (API-Level 33) und höher können Sie den Zugriff Ihrer App auf Laufzeitberechtigungen entfernen, die 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, geben Sie den Namen dieser Berechtigung an revokeSelfPermissionOnKill() weiter. Wenn Sie den Zugriff auf eine Gruppe von Laufzeitberechtigungen gleichzeitig entfernen möchten, übergeben Sie eine Sammlung von Berechtigungsnamen an revokeSelfPermissionsOnKill(). Das Entfernen 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 mit Ihrer App verknüpften Prozesse beendet werden. Wenn Sie die API aufrufen, ermittelt das System, wann diese Prozesse sicher beendet werden können. Normalerweise wartet das System, bis Ihre App über einen längeren Zeitraum im Hintergrund statt im Vordergrund ausgeführt wird.

Wenn Sie den Nutzer darüber informieren möchten, dass Ihre App keinen Zugriff mehr auf bestimmte Laufzeitberechtigungen benötigt, zeigen Sie beim nächsten Start der App ein Dialogfeld an. Dieses Dialogfeld kann 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 Monate lang nicht verwendet wird, schützt das System die Nutzerdaten, indem die sensiblen Laufzeitberechtigungen, die der Nutzer Ihrer App gewährt hat, automatisch zurückgesetzt werden. Weitere Informationen finden Sie im Leitfaden zum App-Ruhezustand.

Bei Bedarf den Standard-Handler anfordern

Einige Apps benötigen Zugriff auf vertrauliche Nutzerdaten im Zusammenhang mit Anruflisten und SMS. Wenn Sie die Berechtigungen für Anruflisten und SMS anfordern und Ihre App im Play Store veröffentlichen möchten, müssen Sie den Nutzer auffordern, Ihre App als Standard-Handler für eine Hauptsystemfunktion festzulegen, bevor Sie diese Laufzeitberechtigungen anfordern.

Weitere Informationen zu Standard-Handlersn, einschließlich einer Anleitung zum Einblenden einer Aufforderung für Standard-Handlers, finden Sie in diesem Leitfaden zu Berechtigungen, die nur in Standard-Handlersn verwendet werden.

Alle Laufzeitberechtigungen zu Testzwecken gewähren

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

adb shell install -g PATH_TO_APK_FILE

Weitere Informationen

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