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 gewährt. Diese Schritte gehören zum Workflow 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 speziellen Berechtigungen gilt ein anderes Verfahren.

Wenn Sie gefährliche Berechtigungen deklarieren und Ihre App auf einem Gerät mit Android 6.0 (API-Level 23) oder höher installiert ist, müssen Sie die gefährlichen Berechtigungen zur Laufzeit anfordern. Folgen Sie dazu der Anleitung in diesem Leitfaden.

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

Grundprinzipien

Die 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 immer die Möglichkeit, einen pädagogischen UI-Ablauf abzubrechen, z. B. einen Ablauf, der die Begründung für das Anfordern von Berechtigungen erläutert.
• Wenn der Nutzer eine für eine Funktion erforderliche Berechtigung ablehnt oder widerruft, stufen Sie Ihre App so ein, dass der Nutzer sie weiterhin verwenden kann. Dazu können Sie beispielsweise die Funktion deaktivieren, für die die Berechtigung erforderlich ist.
• Gehen Sie nicht von einem bestimmten Systemverhalten aus. Angenommen werden darf beispielsweise nicht, dass Berechtigungen in derselben Berechtigungsgruppe enthalten sind. Eine Berechtigungsgruppe hilft dem System lediglich, die Anzahl der Systemdialogfelder zu minimieren, die dem Nutzer angezeigt werden, wenn eine App eng miteinander verbundene Berechtigungen anfordert.

Workflow zum Anfordern von Berechtigungen

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

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

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 Anwendung 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 dem Nutzer eine Begründung 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 bestätigt hat, fahre 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 sie auf der Übersichtsseite für Berechtigungen zu sehen ist.

7. Prüfen Sie die Antwort des Nutzers – unabhängig davon, ob er sich entschieden hat, die Laufzeitberechtigung zu gewähren oder zu verweigern.

8. Wenn der Nutzer Ihrer App die Berechtigung erteilt hat, können Sie auf die privaten Nutzerdaten zugreifen. Wenn der Nutzer stattdessen die Berechtigung abgelehnt hat, verringere die Nutzerfreundlichkeit der App ordnungsgemäß, sodass der Nutzer ohne die Informationen, die durch diese Berechtigung geschützt sind, Funktionen zur Verfügung stellt.

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

Das Berechtigungsdialogfeld, das vom System angezeigt wird, wenn Sie requestPermissions() aufrufen, gibt an, welche Berechtigung Ihre App benötigt, aber keinen Grund dafür. In einigen Fällen kann das für Nutzer verwirrend sein. Es ist empfehlenswert, dem Nutzer zu erklären, warum Ihre App die Berechtigungen benötigt, bevor Sie requestPermissions() aufrufen.

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

Unter bestimmten 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 irgendwo in Ihrer App oder im Benachrichtigungs-Tray, wenn die Anwendung 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 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 UI, warum das Feature, das der Nutzer aktivieren möchte, eine bestimmte Berechtigung benötigt.

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 mit 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 Ihre Logik vereinfacht, wird dies nach Möglichkeit empfohlen. Bei Bedarf können Sie im Rahmen der Berechtigungsanfrage Anfragecode auch selbst verwalten und diesen Anfragecode in Ihre Callback-Logik für Berechtigungen aufnehmen.

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 Vorgang 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 ActivityResultCallback wird definiert, wie deine App die Antwort des Nutzers auf die Berechtigungsanfrage verarbeitet.

   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);
}

Berechtigungsanfragecode selbst verwalten

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

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 dient jedoch der Nutzerfreundlichkeit des Systems. Deine App sollte nicht von Berechtigungen abhängig sein, die sich innerhalb oder außerhalb einer bestimmten Berechtigungsgruppe befinden.

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 für alle anderen Laufzeitberechtigungen. Ein wichtiger Unterschied bei Standortberechtigungen besteht darin, dass das System mehrere standortbezogene Berechtigungen umfasst. Welche Berechtigungen Sie anfordern und wie Sie sie anfordern, hängt von den Standortanforderungen für den Anwendungsfall Ihrer App ab.

Standortermittlung im Vordergrund

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

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

Ihre App verwendet die Standortermittlung im Vordergrund, 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. In früheren Android-Versionen empfiehlt es sich, diesen Typ von Dienst im Vordergrund zu deklarieren.

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

Sie erklären, dass die Standortermittlung im Vordergrund erforderlich ist, wenn Ihre App die Berechtigung ACCESS_COARSE_LOCATION oder 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>

Standort 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.
• Innerhalb 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 der Nutzer nach Hause kommt.

Das System betrachtet Ihre App als Nutzer der Standortermittlung im Hintergrund, 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 ist mit der Genauigkeit der Standortermittlung im Vordergrund identisch. Sie hängt von den Berechtigungen zur Standortermittlung ab, die von Ihrer App deklariert werden.

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 :Im Google Play Store gibt es eine Standortrichtlinie zum Gerätestandort, die den Zugriff auf die Standortermittlung im Hintergrund auf Apps einschränkt, die sie für ihre Hauptfunktion benötigen und die zugehörigen Richtlinienanforderungen erfüllen.

Umgang mit der Ablehnung von Berechtigungen

Wenn der Nutzer eine Berechtigungsanfrage ablehnt, sollte deine App Nutzern dabei helfen, die Auswirkungen der Ablehnung der Berechtigung zu verstehen. 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:

• Die Aufmerksamkeit des Nutzers lenken. 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. Sie könnten beispielsweise Folgendes tun:

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

• Machen Sie möglichst genaue Angaben. Keine allgemeine Nachricht anzeigen. Mach stattdessen deutlich, welche Funktionen nicht verfügbar sind, da deine 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 Handlung des Nutzers impliziert „Nicht mehr fragen“. In früheren Versionen wurde Nutzern jedes Mal, wenn Ihre App eine Berechtigung anforderte, das Dialogfeld für Systemberechtigungen angezeigt, es sei denn, sie hatten zuvor ein Kästchen oder eine Option für „Nicht noch einmal fragen“ angeklickt.

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

In bestimmten Situationen kann die Berechtigung automatisch verweigert werden, ohne dass der Nutzer Maßnahmen ergreift. Eine Berechtigung kann auch automatisch erteilt werden. Es ist wichtig, nichts über automatisches Verhalten anzunehmen. Jedes Mal, wenn Ihre App auf Funktionen zugreifen muss, für die eine Berechtigung erforderlich ist, prüfen Sie, ob der App diese Berechtigung noch gewährt wurde.

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

Ablehnungsstatus beim Testen und Debuggen prüfen

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

adb shell dumpsys package PACKAGE_NAME

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

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

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

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

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

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

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

Eine vollständige Liste der Berechtigungen für Android-Apps finden Sie auf der Referenzseite für die 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. Wenn der Nutzer die einmalige Berechtigung Ihrer App widerruft, wird der App-Prozess wie bei jeder anderen Berechtigung beendet.

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 Anwendung keinen Zugriff mehr auf bestimmte Laufzeitberechtigungen benötigt, zeigen Sie beim nächsten Start der Anwendung ein Dialogfeld an. Dieses Dialogfeld kann eine Liste der Berechtigungen enthalten.

Berechtigungen für nicht verwendete Apps automatisch zurücksetzen

Wenn Ihre App auf Android 11 (API-Level 30) oder höher ausgerichtet ist und einige Monate lang nicht verwendet wird, schützt das System die Nutzerdaten, indem die sensiblen Laufzeitberechtigungen, die der Nutzer Ihrer App gewährt hat, automatisch zurückgesetzt werden. Weitere Informationen finden Sie im Leitfaden zum App-Ruhezustand.

Bei Bedarf den Standard-Handler anfordern

Einige Apps benötigen Zugriff auf vertrauliche Nutzerdaten im Zusammenhang mit Anruflisten und SMS. Wenn Sie die Berechtigungen für 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:

• Übersicht über Berechtigungen
• 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.