Laufzeitberechtigungen

Unter Android 6.0 und höher ist das Modell für Android-App-Berechtigungen so konzipiert, dass Berechtigungen für Nutzer verständlicher, nützlicher und sicherer sind. Durch das Modell wurden Android-Apps, für die gefährliche Berechtigungen erforderlich sind (siehe Betroffene Berechtigungen), von einem Berechtigungsmodell zur Installationszeit zu einem Berechtigungsmodell zur Laufzeit verschoben:

  • Berechtigungen bei der Installation

    (Android 5.1 und niedriger) Nutzer gewähren einer App gefährliche Berechtigungen, wenn sie die App installieren oder aktualisieren. Gerätehersteller und Mobilfunkanbieter können Apps mit vorab gewährten Berechtigungen vorinstallieren, ohne den Nutzer zu benachrichtigen.

  • Laufzeitberechtigungen

    (Android 6.0 bis 9) Nutzer gewähren einer App gefährliche Berechtigungen, während die App ausgeführt wird. Wann Berechtigungen angefordert werden (z. B. beim Starten der App oder beim Zugriff des Nutzers auf eine bestimmte Funktion), hängt von der App ab. Der Nutzer gewährt oder verweigert jedoch den App-Zugriff auf bestimmte Berechtigungsgruppen. OEMs/Mobilfunkanbieter können Apps vorinstallieren, aber keine Berechtigungen vorab gewähren, es sei denn, sie gehen den Ausnahmeprozess durch. Weitere Informationen finden Sie unter Ausnahmen erstellen.

    (Android 10) Nutzer erhalten mehr Transparenz und können festlegen, welche Apps Laufzeitberechtigungen für die Aktivitätserkennung haben. Im Dialogfeld für Laufzeitberechtigungen werden Nutzer aufgefordert, Berechtigungen entweder immer zuzulassen, während der Nutzung zuzulassen oder abzulehnen. Bei einem Betriebssystemupgrade auf Android 10 bleiben die Berechtigungen für Apps erhalten. Nutzer können sie jedoch in den Einstellungen ändern.

Laufzeitberechtigungen verhindern, dass Apps ohne Einwilligung des Nutzers auf private Daten zugreifen. Außerdem erhalten Nutzer zusätzlichen Kontext und Informationen zu den Arten von Berechtigungen, die Apps anfordern oder die ihnen gewährt wurden. Das Laufzeitmodell ermutigt Entwickler, Nutzern zu erklären, warum Apps die angeforderten Berechtigungen benötigen. Außerdem wird für mehr Transparenz gesorgt, damit Nutzer bessere Entscheidungen darüber treffen können, ob sie die Berechtigungen gewähren oder ablehnen möchten.

Betroffene Berechtigungen

Für Android 6.0 und höher sind gefährliche Berechtigungen erforderlich, um ein Laufzeitberechtigungsmodell zu verwenden. Gefährliche Berechtigungen sind Berechtigungen mit höherem Risiko (z. B. READ_CALENDAR), die anfragenden Apps Zugriff auf private Nutzerdaten oder die Kontrolle über ein Gerät gewähren, was sich negativ auf den Nutzer auswirken kann. Führen Sie den folgenden Befehl aus, um eine Liste der schädlichen Berechtigungen aufzurufen:

adb shell pm list permissions -g -d

Unter Android 6.0 und höher ändert sich das Verhalten von normalen Berechtigungen nicht. Dazu gehören alle ungefährlichen Berechtigungen, einschließlich normaler, System- und Signaturberechtigungen. Normale Berechtigungen sind Berechtigungen mit geringerem Risiko (z. B. SET_WALLPAPER), die anfragenden Apps Zugriff auf isolierte Funktionen auf App-Ebene gewähren, mit minimalem Risiko für andere Apps, das System oder den Nutzer. Wie bei Android 5.1 und niedrigeren Versionen gewährt das System der anfragenden App bei der Installation automatisch normale Berechtigungen und fordert den Nutzer nicht zur Genehmigung auf. Weitere Informationen zu Berechtigungen finden Sie in der Dokumentation zum Element<permission>.

Harte und weiche Einschränkungen in Android 10

Eine Berechtigung kann nicht nur gefährlich sein, sondern auch entweder streng oder bedingt eingeschränkt sein. In beiden Fällen muss die eingeschränkte Berechtigung auch auf die Zulassungsliste gesetzt werden. Strenge Einschränkungen, die nicht auf der Zulassungsliste stehen, verhalten sich anders als weiche Einschränkungen, die nicht auf der Zulassungsliste stehen:

  • (Strikte Einschränkungen) Apps können keine Berechtigungen gewährt werden, die nicht auf der Zulassungsliste stehen.
  • (Weiche Einschränkungen) Apps ohne Zulassungsliste verhalten sich gemäß der angeforderten Berechtigung. Das Verhalten wird in der öffentlichen Dokumentation für die angeforderte Berechtigung beschrieben.

Beim Installieren einer App kann der Installationsvorgang (z. B. der Google Play Store) die eingeschränkten Berechtigungen für die App nicht auf die Zulassungsliste setzen. Berechtigungen werden von der Plattform eingeschränkt und können nur gewährt werden, wenn eine App die speziellen Kriterien gemäß den Plattformrichtlinien erfüllt. Beispiele für Berechtigungstypen mit strikten Einschränkungen sind Berechtigungen für SMS und Anruflisten.

Die Zulassungsliste wird während der Installation und in folgenden Fällen erstellt:

  • eine App bereits während eines Upgrades von Android 9 auf Android 10 installiert ist.
  • eine Berechtigung vorab gewährt oder eine App vorinstalliert ist.
  • Es ist eine Berechtigung für eine bereits definierte Rolle erforderlich, um die Berechtigung auf die Zulassungsliste zu setzen.
  • das Installationsprogramm (z. B. der Google Play Store) die Berechtigung auf die Zulassungsliste setzt.

Nutzer können Berechtigungen nicht manuell auf die Zulassungsliste setzen.

Voraussetzungen

Das Berechtigungsmodell für die Laufzeit gilt für alle Apps, einschließlich vorinstallierter Apps und Apps, die im Rahmen der Einrichtung auf das Gerät übertragen werden. Zu den Anforderungen an die App-Software gehören:

  • Das Modell für Laufzeitberechtigungen muss auf allen Geräten mit Android 6.0 und höher einheitlich sein. Dies wird durch die CTS-Tests (Compatibility Test Suite) von Android erzwungen.
  • Apps müssen Nutzer zur Laufzeit auffordern, App-Berechtigungen zu gewähren. Weitere Informationen finden Sie unter Apps aktualisieren. Für Standard-Apps und ‑Handler, die grundlegende Gerätefunktionen bereitstellen, die für den ordnungsgemäßen Betrieb des Geräts erforderlich sind, können begrenzte Ausnahmen gewährt werden. So kann beispielsweise die Standard-Telefon-App des Geräts für die Verarbeitung von ACTION_CALL die Berechtigung „Telefon“ haben. Weitere Informationen finden Sie unter Ausnahmen erstellen.
  • Vorinstallierte Apps mit gefährlichen Berechtigungen müssen auf API-Level 23 ausgerichtet sein und das Berechtigungsmodell der Laufzeit beibehalten. Das bedeutet, dass der UI-Vorgang während der App-Installation nicht von der AOSP-Implementierung von PermissionController abweichen darf, Nutzer gefährliche Berechtigungen von vorinstallierten Apps widerrufen können usw.
  • Für headless Apps muss eine Aktivität verwendet werden, um Berechtigungen anzufordern oder eine UID für eine andere App mit den erforderlichen Berechtigungen freizugeben. Weitere Informationen finden Sie unter Headless-Apps.

Migration von Berechtigungen

Berechtigungen, die Apps unter Android 5.x gewährt wurden, bleiben nach der Aktualisierung auf Android 6.0 oder höher bestehen. Nutzer können diese Berechtigungen jedoch jederzeit widerrufen.

Bei einem Update von Android 9 auf Android 10 werden alle Berechtigungen mit strikten Einschränkungen in die Zulassungsliste aufgenommen. Weitere Informationen zur Implementierung der Berechtigungen für den Vordergrund und Hintergrund finden Sie unter Datenschutzänderungen in Android 10, beginnend mit Standort im Hintergrund anfordern.

Integration

Wenn Sie das Modell für App-Laufzeitberechtigungen für Android 6.0 und höher einbinden, müssen Sie vorinstallierte Apps so aktualisieren, dass sie mit dem neuen Modell funktionieren. Außerdem können Sie Ausnahmen für Apps definieren, die die Standard-Handler/-Anbieter für Hauptfunktionen sind, benutzerdefinierte Berechtigungen festlegen und das in der PermissionController App verwendete Design anpassen.

Apps aktualisieren

Apps im System-Image und vorinstallierte Apps erhalten keine automatischen Berechtigungen. Wir empfehlen Ihnen, mit den Entwicklern der vorinstallierten Apps (OEM, Mobilfunkanbieter und Drittanbieter) zusammenzuarbeiten, um die erforderlichen App-Änderungen gemäß den Entwicklerleitlinien vorzunehmen. Insbesondere müssen Sie dafür sorgen, dass vorinstallierte Apps so geändert werden, dass Abstürze und andere Probleme vermieden werden, wenn Nutzer Berechtigungen widerrufen.

Vorinstallierte Apps

Unter Android 9 und niedriger müssen vorinstallierte Apps, die gefährliche Berechtigungen verwenden, auf API-Level 23 oder höher ausgerichtet sein und das AOSP-Berechtigungsmodell von Android 6.0 und höher einhalten. Beispielsweise darf der UI-Ablauf während einer App-Installation nicht von der AOSP-Implementierung von PermissionController abweichen. Nutzer können sogar die gefährlichen Berechtigungen vorinstallierter Apps widerrufen.

Unter Android 6.0 bis 9 werden einige Berechtigungen während der Installation erteilt. Ab Android 10 ist der Installationsablauf (durch die Package Installer App ausgeführt) jedoch eine separate Funktion von der Berechtigungserteilung (in der Permission Controller App).

Headless-Apps

Nur Aktivitäten können Berechtigungen anfordern. Dienste können Berechtigungen nicht direkt anfordern.

  • Unter Android 5.1 und niedriger können headless-Apps Berechtigungen anfordern, wenn sie installiert werden oder wenn sie ohne Verwendung einer Aktivität vorinstalliert wurden.
  • Unter Android 6.0 und höher müssen headless-Apps eine der folgenden Methoden verwenden, um Berechtigungen anzufordern:
    • Fügen Sie eine Aktivität hinzu, um Berechtigungen anzufordern. (Dies ist die bevorzugte Methode.)
    • Eine UID für eine andere App freigeben, die die erforderlichen Berechtigungen hat. Verwenden Sie diese Methode nur, wenn die Plattform mehrere APKs als einzelne App verarbeiten soll.

Ziel ist es, Nutzer nicht mit Berechtigungsanfragen zu verwirren, die aus dem Kontext gerissen sind.

Benutzeroberfläche des PackageInstaller anpassen

Sie können das Design der Berechtigungsoberfläche anpassen, indem Sie die Standardgerätedesigns (Theme.DeviceDefault.Settings und Theme.DeviceDefault.Light.Dialog.NoActionBar) aktualisieren, die von PackageInstaller verwendet werden. Da für App-Entwickler jedoch Einheitlichkeit wichtig ist, können Sie die Platzierung, Position und Regeln für das Einblenden der Berechtigungs-UI nicht anpassen.

Wenn Sie Strings für zusätzliche Sprachen einschließen möchten, tragen Sie sie in AOSP ein.

Ausnahmen erstellen

Mit der Klasse DefaultPermissionGrantPolicy.java im PackageManager können Sie Apps, die Standard-Handler oder ‑anbieter für wichtige Betriebssystemfunktionen sind, vorab Berechtigungen gewähren. Beispiele:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone

SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

Benutzerdefinierte Berechtigungen festlegen

Sie können benutzerdefinierte Berechtigungen und Gruppen als normal oder gefährlich definieren und vorhandenen Berechtigungsgruppen OEM-/Mobilfunkanbieter-spezifische Berechtigungen hinzufügen, genau wie in Android 5.x und früheren Versionen.

Wenn Sie unter Android 6.0 und höher eine neue schädliche Berechtigung hinzufügen, muss sie wie andere schädliche Berechtigungen behandelt werden (während der App-Laufzeit angefordert und von Nutzern widerrufen werden). Im Detail:

  • Sie können einer aktuellen Gruppe neue Berechtigungen hinzufügen, aber die AOSP-Zuordnung gefährlicher Berechtigungen und gefährlicher Berechtigungsgruppen nicht ändern. Sie können also keine Berechtigung von einer Gruppe entfernen und einer anderen zuweisen.
  • Sie können neuen Berechtigungsgruppen in auf dem Gerät installierten Apps hinzufügen, aber nicht im Plattformmanifest.

Berechtigungen testen

Android umfasst CTS-Tests (Compatibility Test Suite), mit denen überprüft wird, ob einzelne Berechtigungen den richtigen Gruppen zugeordnet sind. Das Bestehen dieser Tests ist eine Voraussetzung für die CTS-Kompatibilität mit Android 6.0 und höher.

Berechtigungen widerrufen

Unter Android 13 und höher können Sie erteilte Laufzeitberechtigungen mit Context.revokeSelfPermissionsOnKill() widerrufen. Die Aufhebung erfolgt asynchron und wird ausgelöst, wenn dies sicher möglich ist, ohne den Nutzer zu stören. Wenn der Widerruf ausgelöst wird, werden alle Prozesse beendet, die mit der anrufenden UID ausgeführt werden.

Beachten Sie, dass das Widerrufen einer einzelnen Berechtigung möglicherweise nicht in der Benutzeroberfläche der Einstellungen angezeigt wird, da Berechtigungen dort nach Gruppe behandelt werden. Normalerweise wird eine Berechtigungsgruppe als gewährt angezeigt, solange mindestens eine der Berechtigungen in dieser Gruppe gewährt ist. Wenn Sie möchten, dass Nutzer den Widerruf in den Einstellungen bestätigen können, müssen Sie alle Berechtigungen in der Berechtigungsgruppe widerrufen. Mit PackageManager.getGroupOfPlatformPermission und PackageManager.getPlatformPermissionsForGroup können Sie herausfinden, welche Berechtigungen zu einer bestimmten Gruppe gehören.

Wenn das System die angeforderten Berechtigungen widerruft, werden auch die entsprechenden Berechtigungen für den Hintergrund widerrufen, wenn keine der entsprechenden Berechtigungen für den Vordergrund mehr gewährt werden.

Der Widerruf wird nicht ausgelöst, solange der Prozess im Vordergrund bleibt. Er kann aber auch sofort ausgelöst werden, indem alle Prozesse, die mit der aktuellen UID ausgeführt werden, manuell beendet werden, z. B. mit System.exit(). Wir empfehlen jedoch, das System entscheiden zu lassen, wann die Funktion ausgelöst wird.

Nachdem ein Berechtigungswiderruf wirksam geworden ist, können Sie die Berechtigung noch einmal anfordern. Der Nutzer wird dann aufgefordert, die Anfrage zu genehmigen oder abzulehnen. Es ist nicht möglich, eine Berechtigung anzufordern, die zuvor vom Nutzer abgelehnt wurde. Wir empfehlen Ihnen, Berechtigungen zu widerrufen, die Sie derzeit haben, aber nicht mehr benötigen. Informieren Sie den Nutzer jedoch erst über den Widerruf, wenn er in Kraft getreten ist.