Laufzeitberechtigungen

Unter Android 6.0 und höher soll das Android-App-Berechtigungsmodell für Nutzer verständlicher, nützlicher und sicherer. Das Modell hat Android Apps, die gefährliche Berechtigungen erfordern (siehe Betroffene Berechtigungen) von einem Installationszeit-Berechtigungsmodell zu einem Laufzeitberechtigungsmodell:

  • Berechtigungen für die Installation

    Android 5.1 und niedriger: Nutzer erteilen einer App gefährliche Berechtigungen, wenn sie die App installieren oder aktualisieren. Gerät Hersteller und Mobilfunkanbieter können Apps mit vorab gewährten Berechtigungen vorinstallieren, ohne den Nutzer.

  • Laufzeitberechtigungen

    Android 6.0 bis 9: Nutzer gewähren einer App gefährliche Berechtigungen, während sie ausgeführt wird. Wenn Berechtigungen angefordert werden (z. B. wenn die App gestartet wird oder der Nutzer auf eine bestimmte -Funktion) von der App abhängt, aber der Nutzer gewährt/verweigert App-Zugriff auf bestimmte Berechtigungsgruppen. OEMs/Mobilfunkanbieter können Apps vorinstallieren, aber keine Berechtigungen im Voraus gewähren, es sei denn, sie haben den Ausnahmeprozess durchlaufen. (Siehe Erstellen Ausnahmen.

    (Android 10) Nutzer profitieren von mehr Transparenz und festlegen, welche Apps Laufzeitberechtigungen für die Aktivitätserkennung (AR) haben Nutzer werden aufgefordert, die Dialogfeld für Laufzeitberechtigungen, um Berechtigungen entweder immer zuzulassen, während der Verwendung 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. und bieten ihnen zusätzlichen Kontext und Einblick in die Arten von Berechtigungen, Apps suchen oder wurden zugelassen. Das Laufzeitmodell ermutigt Entwickelnde, Nutzern helfen zu verstehen, warum Apps die angeforderten Berechtigungen benötigen, und bieten Transparenz, damit Nutzer bessere Entscheidungen darüber treffen können, ob sie zugelassen oder abgelehnt werden.

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), durch die oder die Kontrolle über ein Gerät anfordern, auf die Nutzenden auswirken. Führen Sie den folgenden Befehl aus, um eine Liste gefährlicher Berechtigungen aufzurufen:

adb shell pm list permissions -g -d

Android 6.0 und höher ändert das Verhalten der normalen Berechtigungen Dies sind alle ungefähren Berechtigungen, einschließlich normaler, System- und Signaturberechtigungen. Normale Berechtigungen sind Berechtigungen mit geringerem Risiko (z. B. SET_WALLPAPER), die anfordernden Apps Zugriff auf isolierte App-Ebene gewähren Funktionen mit minimalem Risiko für andere Apps, das System oder die Nutzer. Wie in Android 5.1 und älteren Releases erteilt das System einer anfragenden App automatisch normale Berechtigungen und fordert den Nutzer nicht zur Genehmigung auf. Einzelheiten zu Berechtigungen finden Sie im Abschnitt <permission> Element-Dokumentation.

Feste und weiche Einschränkungen in Android 10

Eine Berechtigung ist nicht nur gefährlich, sondern kann auch oder eine vorläufige Einschränkung. In beiden Fällen muss auch die eingeschränkte Berechtigung auf die Zulassungsliste gesetzt werden. Nicht auf der Zulassungsliste Harte Einschränkungen verhalten sich anders als weiche Einschränkungen, die nicht auf der Zulassungsliste stehen. Einschränkungen:

  • (Erzwungene Einschränkungen) Apps können keine Berechtigungen gewährt werden, wenn auf der Zulassungsliste.
  • (Weiche Einschränkungen) Apps ohne Zulassungsliste verhalten sich wie folgt: bestimmte Berechtigung anfordern. Das Verhalten wird öffentlich beschrieben. Dokumentation für die angeforderte Genehmigung.

Bei der Installation einer App kann das Installationsprogramm (z. B. den Google Play Store) um die eingeschränkten Berechtigungen für die App nicht auf die Zulassungsliste zu setzen. Berechtigungen sind sind von der Plattform eingeschränkt und können nur gewährt werden, wenn eine App besondere Kriterien erfüllt. pro Plattformrichtlinie. Beispiele für strikt eingeschränkte Berechtigungstypen sind „SMS“ und "Anrufliste".

Die Zulassungsliste erfolgt während der Installation und wenn

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

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

Voraussetzungen

Das Laufzeitberechtigungsmodell gilt für alle Apps, einschließlich vorinstallierter Apps und Apps an das Gerät gesendet werden. Zu den Anforderungen der App-Software gehören:

  • Das Laufzeitberechtigungsmodell muss auf allen Geräten mit Android 6.0 einheitlich sein. und höher. Dies wird durch CTS-Tests (Android Compatibility Test Suite) erzwungen.
  • Nutzer müssen von Apps zur Laufzeit aufgefordert werden, App-Berechtigungen zu gewähren. Weitere Informationen finden Sie unter Aktualisieren Apps. Begrenzte Ausnahmen können für Standard-Apps und -Handler gewährt werden die grundlegende Gerätefunktionen bieten, die für den erwarteten Betrieb des Geräts wichtig sind. Beispiel: Die Standard-Telefon-App des Geräts zur Verwaltung von ACTION_CALL hat möglicherweise Zugriff auf die Berechtigung „Telefon“.) Weitere Informationen finden Sie unter Ausnahmen erstellen.
  • Vorab geladene Apps mit gefährlichen Berechtigungen muss auf API-Level 23 ausgerichtet sein und das Laufzeitberechtigungsmodell beibehalten. Das heißt, der UI-Ablauf App-Installation darf nicht von der AOSP-Implementierung des PermissionController können Nutzer gefährliche Berechtigungen vorinstallierter Apps widerrufen. aktiviert.
  • Monitorlose Apps müssen eine Aktivität nutzen, um Berechtigungen anzufordern oder ein UID mit einer anderen App, die die erforderlichen Berechtigungen hat. Weitere Informationen

Migration von Berechtigungen

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

Beim Update von Android 9 auf 10 erhalten alle stark eingeschränkten Berechtigungen auf der Zulassungsliste. Weitere Informationen zur Implementierung der geteilten Berechtigungen für Vorder- und Hintergrund finden Sie unter Datenschutzänderung für Android 10, beginnend mit Hintergrund anfordern. Standort

Integration

Bei der Integration des App-Laufzeitberechtigungsmodells für Android 6.0 und höher müssen Sie Vorinstallierte Apps aktualisieren, damit sie mit dem neuen Modell funktionieren. Sie können auch Ausnahmen für Apps festlegen. Standard-Handler/-Anbieter für die Hauptfunktion, benutzerdefinierte Berechtigungen das in der PermissionController-App verwendete Design anpassen.

Apps aktualisieren

Apps im System-Image und vorinstallierte Apps werden nicht automatisch vorab gewährt Berechtigungen. Wir empfehlen Ihnen, mit Entwicklern von vorinstallierten Apps (OEM, Mobilfunkanbieter und Drittanbieter die erforderlichen App-Änderungen über den Entwickler . Insbesondere müssen Sie sicherstellen, dass vorinstallierte Apps modifiziert werden, um Abstürze und andere Probleme auftreten, wenn Nutzer Berechtigungen widerrufen.

Vorinstallierte Apps

In Android 9 und niedriger müssen vorab geladene Apps, die gefährliche Berechtigungen verwenden, auf API-Level 23 ausgerichtet sein oder höher und das AOSP-Berechtigungsmodell für Android 6.0 und höher beibehalten. Zum Beispiel der UI-Ablauf App-Installation nicht von der AOSP-Implementierung des PermissionController Nutzer können sogar die gefährlichen Berechtigungen vorinstallierten Apps installiert.

In Android 6.0 bis 9 werden einige Berechtigungen während der Installation gewährt. Zu Beginn Bei Version 10 ist der Installationsablauf (durch die App Package Installer) eine andere Funktion von der Gewährung von Berechtigungen (in der Permission Controller App).

Monitorlose Apps

Berechtigungen können nur von Aktivitäten angefordert werden. Dienste können Berechtigungen nicht direkt anfordern.

  • In Android 5.1 und niedriger können monitorlose Apps Berechtigungen anfordern, installiert sind oder sie ohne Aktivität vorinstalliert wurden.
  • In Bei monitorlosen Apps mit Android 6.0 und höher muss eine der folgenden Methoden verwendet werden, Berechtigungen anfordern:
    • Fügen Sie eine Aktivität hinzu, um Berechtigungen anzufordern. Dies ist die bevorzugte Methode.
    • Geben Sie eine UID für eine andere App frei, die über die erforderlichen Berechtigungen verfügt. Verwenden nur dann, wenn die Plattform mehrere APKs als ein einzelnes APK verarbeiten muss.

Damit soll vermieden werden, dass Nutzer durch Berechtigungsanfragen verwirrt werden, die außerhalb des Kontexts erscheinen.

PackageInstaller-Benutzeroberfläche anpassen

Bei Bedarf kannst du das Design der Benutzeroberfläche für Berechtigungen anpassen, indem du Aktualisieren der Standard-Gerätedesigns (Theme.DeviceDefault.Settings) und Theme.DeviceDefault.Light.Dialog.NoActionBar) verwendet von PackageInstaller verfügbar sind. Da Konsistenz für App-Entwickler jedoch wichtig ist, können Sie die Platzierung, die Position und die Regeln nicht anpassen, wenn die Berechtigungen UI wird angezeigt.

Wenn Sie Strings für weitere Sprachen verwenden möchten, fügen Sie den Parameter zu AOSP.

Ausnahmen erstellen

Sie können Berechtigungen für Apps, die Standard-Handler sind oder für Kernfunktionen des Betriebssystems mithilfe der Klasse DefaultPermissionGrantPolicy.java in PackageManager. 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 sein und den vorhandenen Berechtigungen Berechtigungsgruppen, genau wie bei Android 5.x und früheren Releases.

Wenn Sie in Android 6.0 und höher eine neue gefährliche Berechtigung hinzufügen, muss diese in wie bei anderen gefährlichen Berechtigungen, die während der App-Laufzeit kann vom Nutzer widerrufen werden. Im Detail:

  • 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. (Mit anderen Worten: Sie Berechtigungen können nicht aus einer Gruppe entfernt und einer anderen Gruppe zugewiesen werden).
  • Sie können neue Berechtigungsgruppen in Apps hinzufügen, die auf dem Gerät installiert sind, aber Sie können keine neuen Berechtigungsgruppen im Plattformmanifest hinzufügen.

Berechtigungen testen

Android umfasst CTS-Tests (Compatibility Test Suite), bei denen werden die einzelnen Berechtigungen den richtigen Gruppen zugeordnet. Das Bestehen dieser Tests eine Anforderung für die CTS-Kompatibilität mit Android 6.0 und höher.

Berechtigungen widerrufen

Unter Android 13 und höher können Sie Ihre eigene Laufzeitberechtigungen mithilfe von Context.revokeSelfPermissionsOnKill() Der Widerruf erfolgt asynchron und wird ausgelöst, wenn dies sicher ist. Nutzenden. Wenn der Widerruf ausgelöst wird, werden alle Prozesse beendet, die in der aufrufenden UID ausgeführt werden.

Beachten Sie, dass der Widerruf einer einzelnen Berechtigung möglicherweise nicht im in der die Berechtigungen nach Gruppe behandelt werden. Normalerweise wird eine Berechtigungsgruppe als gewährt wird, solange mindestens eine der Berechtigungen in dieser Gruppe gewährt wurde. Wenn Sie sicherstellen, in den Einstellungen bestätigen können, dass der Widerruf wichtig für Sie ist, sollten Sie alle Berechtigung in der Berechtigungsgruppe. Um zu erfahren, welche Berechtigungen zu einer bestimmten Gruppe gehören, können Sie PackageManager.getGroupOfPlatformPermission verwenden und PackageManager.getPlatformPermissionsForGroup.

Wenn das System die angeforderten Berechtigungen widerruft, werden auch die entsprechenden Hintergrundberechtigungen widerrufen. Berechtigungen, wenn keine der entsprechenden Berechtigungen im Vordergrund weiterhin gewährt wird.

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

Wenn der Widerruf der Berechtigung wirksam ist, können Sie sie erneut anfordern und der Nutzer wird aufgefordert, die Anfrage zu gewähren oder abzulehnen. Es ist nicht möglich, eine Berechtigung anzufordern, für die vom Nutzer abgelehnt wurde. Es empfiehlt sich zwar, Berechtigungen zu widerrufen, die derzeit auf Hold gesetzt sind, aber nicht mehr benötigt werden, sollten Sie den Nutzer nicht über die erst nach deren Inkrafttreten widerrufen werden.