Laufzeitberechtigungen

In Android 6.0 und höher wurde das Berechtigungsmodell für Android-Anwendungen entwickelt, um Berechtigungen für Benutzer verständlicher, nützlicher und sicherer zu machen. Das Modell hat Android-Anwendungen, die gefährliche Berechtigungen erfordern (siehe Betroffene Berechtigungen ), von einem Berechtigungsmodell zur Installationszeit in ein Berechtigungsmodell zur Laufzeit verschoben:

  • Berechtigungen zur Installationszeit

    ( Android 5.1 und niedriger ) Benutzer erteilen einer App gefährliche Berechtigungen , wenn sie die App installieren oder aktualisieren. Gerätehersteller und Netzbetreiber können Apps mit vorab erteilten Berechtigungen vorinstallieren, ohne den Benutzer zu benachrichtigen.

  • Laufzeitberechtigungen

    ( Android 6.0 – 9 ) Benutzer gewähren einer App gefährliche Berechtigungen, wenn die App ausgeführt wird. Wann Berechtigungen angefordert werden (z. B. wenn die App gestartet wird oder wenn der Benutzer auf eine bestimmte Funktion zugreift), hängt von der Anwendung ab, aber der Benutzer gewährt/verweigert den Anwendungszugriff auf bestimmte Berechtigungsgruppen. OEMs/Netzbetreiber können Apps vorinstallieren, aber keine Berechtigungen vorab erteilen, es sei denn, sie durchlaufen den Ausnahmeprozess. (Siehe Ausnahmen erstellen .)

    ( Android 10 ) Benutzer sehen mehr Transparenz und haben die Kontrolle darüber, welche Apps Laufzeitberechtigungen für die Aktivitätserkennung (AR) haben. Benutzer werden vom Laufzeitberechtigungsdialog aufgefordert, Berechtigungen entweder immer zuzulassen, während der Verwendung zuzulassen oder zu verweigern. Bei einem Betriebssystem-Upgrade auf Android 10 bleiben die Berechtigungen für Apps erhalten, aber Benutzer können in die Einstellungen gehen und sie ändern.

Laufzeitberechtigungen verhindern, dass Apps ohne die Zustimmung eines Benutzers Zugriff auf private Daten erhalten, und bieten ihnen zusätzlichen Kontext und Einblick in die Arten von Berechtigungen, die Anwendungen entweder anfordern oder denen sie gewährt wurden. Das Laufzeitmodell ermutigt Entwickler, Benutzern zu helfen, zu verstehen, warum Anwendungen die angeforderten Berechtigungen benötigen, und bietet mehr Transparenz, damit Benutzer bessere Entscheidungen über das Erteilen oder Verweigern dieser Berechtigungen treffen können.

Betroffene Berechtigungen

Android 6.0 und höher erfordert gefährliche Berechtigungen, um ein Laufzeitberechtigungsmodell zu verwenden. Gefährliche Berechtigungen sind Berechtigungen mit höherem Risiko (z. B. READ_CALENDAR ), die anfordernden Anwendungen Zugriff auf private Benutzerdaten oder die Kontrolle über ein Gerät gewähren, was sich negativ auf den Benutzer auswirken kann. Führen Sie den folgenden Befehl aus, um eine Liste gefährlicher Berechtigungen anzuzeigen:

adb shell pm list permissions -g -d

Android 6.0 und höher ändert das Verhalten normaler Berechtigungen nicht . Dies sind alles ungefährliche Berechtigungen, einschließlich normaler, System- und Signaturberechtigungen. Normale Berechtigungen sind Berechtigungen mit geringerem Risiko (z. B. SET_WALLPAPER ), die anfordernden Anwendungen Zugriff auf isolierte Funktionen auf Anwendungsebene mit minimalem Risiko für andere Anwendungen, das System oder den Benutzer gewähren. Wie in Android 5.1 und niedrigeren Versionen gewährt das System einer anfordernden Anwendung bei der Installation automatisch normale Berechtigungen und fordert den Benutzer nicht zur Genehmigung auf. Einzelheiten zu Berechtigungen finden Sie in der Dokumentation zum <permission>-Element .

Harte und weiche Einschränkungen in Android 10

Abgesehen davon, dass sie gefährlich ist, kann eine Erlaubnis entweder hart eingeschränkt oder weich eingeschränkt sein. In jedem Fall muss die eingeschränkte Berechtigung ebenfalls auf die Positivliste gesetzt werden. Harte Einschränkungen, die nicht auf der Zulassungsliste stehen, verhalten sich anders als weiche Einschränkungen, die nicht auf der Zulassungsliste stehen:

  • ( Harte Einschränkungen ) Apps können keine Berechtigungen erteilt werden, die nicht auf der Zulassungsliste stehen.
  • ( Weiche Beschränkungen ) Apps ohne Zulassungsliste verhalten sich entsprechend der spezifischen Erlaubnis, die sie anfordern. Das Verhalten wird in der öffentlichen Dokumentation für die angeforderte Erlaubnis beschrieben.

Beim Installieren einer App kann das Installationsprogramm (z. B. Google Play Store) auswählen, die eingeschränkten Berechtigungen für die App nicht auf die Zulassungsliste zu setzen. Berechtigungen werden von der Plattform eingeschränkt und können nur gewährt werden, wenn eine App spezielle Kriterien gemäß Plattformrichtlinie erfüllt. Beispiele für stark eingeschränkte Berechtigungstypen sind SMS- und Anrufprotokollberechtigungen.

Die Zulassungsliste erfolgt während der Installation und wann

  • Bei einem Upgrade von Android 9 auf 10 wird bereits eine App installiert.
  • eine Berechtigung vorab erteilt oder eine App vorinstalliert ist.
  • Für eine Rolle, die bereits definiert ist, ist eine Berechtigung erforderlich, um die Berechtigung auf die Zulassungsliste zu setzen.
  • Das Installationsprogramm (z. B. Google Play Store) markiert die Berechtigung auf der Zulassungsliste.

Benutzer können Berechtigungen nicht manuell auf die Positivliste setzen.

Anforderungen

Das Laufzeit-Berechtigungsmodell gilt für alle Anwendungen, einschließlich vorinstallierter Apps und Apps, die im Rahmen des Setup-Prozesses auf das Gerät geliefert werden. Zu den Anforderungen an die Anwendungssoftware gehören:

  • Das Laufzeitberechtigungsmodell muss auf allen Geräten mit Android 6.0 und höher konsistent sein. Dies wird durch Tests der Android Compatibility Test Suite (CTS) erzwungen.
  • Apps müssen Benutzer auffordern, Anwendungsberechtigungen zur Laufzeit zu erteilen. Einzelheiten finden Sie unter Aktualisieren von Anwendungen . Begrenzte Ausnahmen können standardmäßigen Anwendungen und Handlern gewährt werden, die grundlegende Gerätefunktionen bereitstellen, die für den erwarteten Betrieb des Geräts grundlegend sind. (Zum Beispiel kann die standardmäßige Dialer-App des Geräts für die Bearbeitung ACTION_CALL Zugriff auf die Telefonberechtigung haben.) Einzelheiten finden Sie unter Erstellen von Ausnahmen .
  • Vorinstallierte Apps mit gefährlichen Berechtigungen müssen auf API-Ebene 23 abzielen und das Laufzeitberechtigungsmodell beibehalten. Das heißt, der UI-Fluss während der App-Installation darf nicht von der AOSP-Implementierung von PermissionController abweichen, Benutzer können gefährliche Berechtigungen von vorinstallierten Apps widerrufen und so weiter.
  • Headless-Anwendungen müssen eine Aktivität verwenden, um Berechtigungen anzufordern oder eine UID mit einer anderen Anwendung zu teilen, die über die erforderlichen Berechtigungen verfügt. Einzelheiten finden Sie unter Headless-Anwendungen .

Berechtigungsmigration

Berechtigungen, die Anwendungen auf Android 5.x gewährt wurden, bleiben nach dem Update auf Android 6.0 oder höher gewährt, aber Benutzer können diese Berechtigungen jederzeit widerrufen.

Bei einem Update von Android 9 auf 10 werden alle stark eingeschränkten Berechtigungen auf die Positivliste gesetzt. Ausführliche Informationen zum Implementieren der geteilten Berechtigungen für Vordergrund/Hintergrund finden Sie unter Android 10-Datenschutzänderung , beginnend mit Hintergrundstandort anfordern .

Integration

Wenn Sie das Berechtigungsmodell für die Anwendungslaufzeit für Android 6.0 und höher integrieren, müssen Sie vorinstallierte Anwendungen aktualisieren, damit sie mit dem neuen Modell funktionieren. Sie können auch Ausnahmen für Apps definieren, die die Standardhandler/-anbieter für Kernfunktionen sind, benutzerdefinierte Berechtigungen definieren und das in der PermissionController -App verwendete Design anpassen.

Anwendungen aktualisieren

Anwendungen auf dem Systemabbild und vorinstallierten Anwendungen werden nicht automatisch vorab gewährte Berechtigungen gewährt. Wir empfehlen Ihnen, mit vorinstallierten App-Entwicklern (OEM, Netzbetreiber und Drittanbieter) zusammenzuarbeiten, um die erforderlichen App-Änderungen gemäß den Entwicklerrichtlinien vorzunehmen . Insbesondere müssen Sie sicherstellen, dass vorinstallierte Anwendungen geändert werden, um Abstürze und andere Probleme zu vermeiden, wenn Benutzer Berechtigungen widerrufen.

Vorinstallierte Anwendungen

In Android 9 und niedriger müssen vorinstallierte Apps, die gefährliche Berechtigungen verwenden, auf API-Ebene 23 oder höher abzielen und das AOSP-Berechtigungsmodell von Android 6.0 und höher beibehalten. Beispielsweise darf der UI-Fluss während einer App-Installation nicht von der AOSP-Implementierung von PermissionController abweichen. Benutzer können sogar die gefährlichen Berechtigungen vorinstallierter Apps widerrufen.

In Android 6.0 bis 9 werden einige Berechtigungen während des Installationsablaufs gewährt. Ab Version 10 ist der Installationsablauf (durchgeführt von der Package Installer -App) jedoch eine separate Funktion von der Berechtigungsgewährung (in der Permission Controller -App).

Headless-Anwendungen

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

  • In Android 5.1 und früher können Headless-Anwendungen Berechtigungen anfordern, wenn sie installiert sind oder wenn sie ohne Verwendung einer Aktivität vorinstalliert wurden.
  • In Android 6.0 und höher müssen Headless-Anwendungen eine der folgenden Methoden verwenden, um Berechtigungen anzufordern:
    • Fügen Sie eine Aktivität hinzu, um Berechtigungen anzufordern. (Dies ist die bevorzugte Methode.)
    • Teilen Sie eine UID mit einer anderen Anwendung, die über die erforderlichen Berechtigungen verfügt. Verwenden Sie diese Methode nur, wenn die Plattform mehrere APKs als eine einzige Anwendung verarbeiten soll.

Das Ziel besteht darin, zu vermeiden, dass Benutzer mit Berechtigungsanfragen verwirrt werden, die aus dem Zusammenhang gerissen erscheinen.

Anpassen der PackageInstaller-Benutzeroberfläche

Falls gewünscht, können Sie das Design der Theme.DeviceDefault.Light.Dialog.NoActionBar für Berechtigungen anpassen, indem Sie die standardmäßigen Gerätedesigns ( Theme.DeviceDefault.Settings und Theme.DeviceDefault.Light.Dialog.NoActionBar ) aktualisieren, die von PackageInstaller verwendet werden. Da Konsistenz für App-Entwickler jedoch von entscheidender Bedeutung ist, können Sie die Platzierung, Position und Regeln für die Anzeige der Benutzeroberfläche für Berechtigungen nicht anpassen.

Um Zeichenfolgen für zusätzliche Sprachen einzuschließen, tragen Sie die Zeichenfolgen zu AOSP bei.

Ausnahmen erstellen

Sie können Anwendungen, die standardmäßige Handler oder Anbieter für Kernfunktionen des Betriebssystems sind, vorab Berechtigungen erteilen, indem Sie die Klasse DefaultPermissionGrantPolicy.java in PackageManager verwenden. Beispiele:

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

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

Benutzerdefinierte Berechtigungen definieren

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

Wenn Sie in Android 6.0 und höher eine neue gefährliche Berechtigung hinzufügen, muss sie genauso behandelt werden wie andere gefährliche Berechtigungen (während der App-Laufzeit angefordert und von Benutzern widerrufen). Speziell:

  • Sie können einer aktuellen Gruppe neue Berechtigungen hinzufügen, aber Sie können die AOSP-Zuordnung von gefährlichen Berechtigungen und gefährlichen Berechtigungsgruppen nicht ändern. (Mit anderen Worten, Sie können eine Berechtigung nicht aus einer Gruppe entfernen und einer anderen Gruppe zuweisen).
  • Sie können neue Berechtigungsgruppen in Anwendungen hinzufügen, die auf dem Gerät installiert sind, aber Sie können keine neuen Berechtigungsgruppen im Plattformmanifest hinzufügen.

Berechtigungen testen

Android enthält Compatibility Test Suite (CTS)-Tests, die überprüfen, 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.

Widerrufen von Berechtigungen

In Android 13 und höher können Sie Ihre eigenen gewährten Laufzeitberechtigungen mit Context.revokeSelfPermissionsOnKill() widerrufen. Der Widerruf erfolgt asynchron und wird ausgelöst, wenn dies sicher ist, ohne den Benutzer zu stören. Wenn der Widerruf ausgelöst wird, werden alle Prozesse, die in der aufrufenden UID laufen, beendet.

Es ist wichtig zu verstehen, dass sich das Widerrufen einer einzelnen Berechtigung möglicherweise nicht in der Einstellungs-UI widerspiegelt, die Berechtigungen nach Gruppe behandelt. Normalerweise wird eine Berechtigungsgruppe als erteilt angezeigt, solange mindestens eine der Berechtigungen in dieser Gruppe erteilt ist. Wenn es Ihnen wichtig ist, dass Benutzer den Widerruf in den Einstellungen bestätigen können, achten Sie darauf, jede Berechtigung in der Berechtigungsgruppe zu entziehen. Um zu erfahren, welche Berechtigungen zu einer bestimmten Gruppe gehören, können Sie PackageManager.getGroupOfPlatformPermission und PackageManager.getPlatformPermissionsForGroup .

Wenn das System die angeforderten Berechtigungen widerruft, widerruft es auch die entsprechenden Hintergrundberechtigungen, wenn keine ihrer entsprechenden Vordergrundberechtigungen noch erteilt sind.

Der Widerruf wird nicht ausgelöst, solange der Prozess im Vordergrund bleibt, kann aber auch sofort ausgelöst werden, indem alle Prozesse, die in der aktuellen UID laufen, manuell beendet werden, beispielsweise mit System.exit() . Es wird jedoch empfohlen, das System entscheiden zu lassen, wann es ausgelöst wird.

Nachdem ein Berechtigungsentzug wirksam ist, können Sie ihn erneut anfordern, und der Benutzer wird aufgefordert, die Anforderung zu gewähren oder abzulehnen. Es ist nicht möglich, eine Erlaubnis anzufordern, die zuvor vom Benutzer verweigert wurde. Es wird Ihnen zwar empfohlen, Berechtigungen zu widerrufen, die Sie derzeit besitzen, aber nicht mehr benötigt werden, Sie sollten jedoch darauf achten, den Benutzer erst dann über den Widerruf zu informieren, wenn er in Kraft getreten ist.