Laufzeitberechtigungen

In Android 6.0 und höher ist das Android-Anwendungsberechtigungsmodell darauf ausgelegt, 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 gewährten Berechtigungen vorinstallieren, ohne den Benutzer zu benachrichtigen.

  • Laufzeitberechtigungen

    ( Android 6.0 – 9 ) Benutzer erteilen 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 der Anwendung den Zugriff auf bestimmte Berechtigungsgruppen. OEMs/Betreiber können Apps vorinstallieren, aber keine Berechtigungen vorab erteilen, es sei denn, sie durchlaufen den Ausnahmeprozess. (Siehe Ausnahmen erstellen .)

    ( Android 10 ) Benutzer sehen eine erhöhte Transparenz und haben die Kontrolle darüber, welche Apps über Laufzeitberechtigungen für die Aktivitätserkennung (AR) verfügen. Benutzer werden im Dialogfeld „Laufzeitberechtigungen“ 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, Benutzer können sie jedoch in den Einstellungen ändern.

Laufzeitberechtigungen verhindern, dass Apps ohne Zustimmung des 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, den Benutzern zu helfen, zu verstehen, warum Anwendungen die angeforderten Berechtigungen benötigen, und sorgt für mehr Transparenz, sodass Benutzer bessere Entscheidungen über die Gewährung oder Verweigerung dieser Berechtigungen treffen können.

Betroffene Berechtigungen

Android 6.0 und höher erfordert gefährliche Berechtigungen, um ein Laufzeitberechtigungsmodell verwenden zu können. 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 Berechtigungen, Systemberechtigungen 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 erteilt 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

Eine Berechtigung ist nicht nur gefährlich, sondern kann auch stark oder sanft eingeschränkt sein. In jedem Fall muss die eingeschränkte Berechtigung ebenfalls auf die Zulassungsliste gesetzt werden. Nicht zugelassene harte Beschränkungen verhalten sich anders als nicht zugelassene weiche Beschränkungen:

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

Bei der Installation einer App kann es sein, dass das Installationsprogramm (z. B. der Google Play Store) die eingeschränkten Berechtigungen für die App nicht auf die Zulassungsliste setzt. Berechtigungen werden durch die Plattform eingeschränkt und können nur gewährt werden, wenn eine App bestimmte Kriterien gemäß der 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 ist bereits eine App installiert.
  • eine Berechtigung vorab erteilt oder eine App vorinstalliert ist.
  • Für eine bereits definierte Rolle ist eine Berechtigung erforderlich, um die Berechtigung auf die Zulassungsliste zu setzen.
  • Das Installationsprogramm (z. B. Google Play Store) markiert die Berechtigung als zugelassen.

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

Anforderungen

Das Laufzeitberechtigungsmodell gilt für alle Anwendungen, einschließlich vorinstallierter Apps und Apps, die im Rahmen des Einrichtungsprozesses an 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 zur Laufzeit dazu auffordern, Anwendungsberechtigungen zu erteilen. Einzelheiten finden Sie unter Anwendungen aktualisieren . Für Standardanwendungen und -handler, die grundlegende Gerätefunktionen bereitstellen, die für den erwarteten Betrieb des Geräts von grundlegender Bedeutung sind, können begrenzte Ausnahmen gewährt werden. (Zum Beispiel verfügt die Standard-Dialer-App des Geräts für die Verarbeitung ACTION_CALL möglicherweise über Telefonberechtigungszugriff.) 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-Ablauf während der App-Installation darf nicht von der AOSP-Implementierung von PermissionController abweichen, Benutzer können gefährliche Berechtigungen vorinstallierter 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 .

Migration von Berechtigungen

Berechtigungen für Anwendungen auf Android 5.x bleiben auch nach dem Update auf Android 6.0 oder höher bestehen, Benutzer können diese Berechtigungen jedoch jederzeit widerrufen.

Bei einem Update von Android 9 auf 10 werden alle stark eingeschränkten Berechtigungen auf die Zulassungsliste gesetzt. Einzelheiten zur Implementierung der geteilten Vordergrund-/Hintergrundberechtigungen finden Sie unter Datenschutzänderung für Android 10 , beginnend mit „Hintergrundspeicherort anfordern“ .

Integration

Bei der Integration des Anwendungslaufzeit-Berechtigungsmodells für Android 6.0 und höher 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 erhalten nicht automatisch vorab gewährte Berechtigungen. Wir empfehlen Ihnen, mit Entwicklern vorinstallierter Apps (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-Level 23 oder höher abzielen und das AOSP-Berechtigungsmodell von Android 6.0 und höher beibehalten. Beispielsweise darf der UI-Ablauf 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 Installationsvorgangs gewährt. Ab Version 10 ist der Installationsablauf (durchgeführt von der Package Installer App) jedoch eine von der Berechtigungserteilung (in der Permission Controller App) getrennte Funktion.

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 durch Berechtigungsanfragen verwirrt werden, die aus dem Kontext gerissen erscheinen.

Anpassen der PackageInstaller-Benutzeroberfläche

Bei Bedarf können Sie das Berechtigungs-UI- Design anpassen, indem Sie die von PackageInstaller verwendeten Standardgerätedesigns ( Theme.DeviceDefault.Settings und Theme.DeviceDefault.Light.Dialog.NoActionBar ) aktualisieren. Da die Konsistenz jedoch für App-Entwickler von entscheidender Bedeutung ist, können Sie die Platzierung, Position und Regeln für die Anzeige der Berechtigungsbenutzeroberfläche nicht anpassen.

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

Ausnahmen erstellen

Mithilfe der Klasse DefaultPermissionGrantPolicy.java in PackageManager können Sie Anwendungen, die Standardhandler oder Anbieter für Kernfunktionen des Betriebssystems sind, vorab Berechtigungen erteilen. 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-/Netzbetreiber-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 diese auf die gleiche Weise gehandhabt werden wie andere gefährliche Berechtigungen (während der App-Laufzeit angefordert und von Benutzern widerrufbar). Speziell:

  • Sie können einer aktuellen Gruppe neue Berechtigungen hinzufügen, aber Sie können die AOSP-Zuordnung gefährlicher Berechtigungen und gefährlicher Berechtigungsgruppen nicht ändern. (Mit anderen Worten: Sie können einer Gruppe keine Berechtigung entziehen und sie einer anderen Gruppe zuweisen.)
  • Sie können neue Berechtigungsgruppen in auf dem Gerät installierten Anwendungen hinzufügen, aber Sie können keine neuen Berechtigungsgruppen im Plattformmanifest hinzufügen.

Testberechtigungen

Android umfasst 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.

Berechtigungen entziehen

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 ohne Beeinträchtigung des Benutzers sicher möglich ist. Wenn der Widerruf ausgelöst wird, werden alle Prozesse, die in der aufrufenden UID ausgeführt werden, beendet.

Es ist wichtig zu verstehen, dass der Widerruf einer einzelnen Berechtigung möglicherweise nicht in der Benutzeroberfläche der Einstellungen widergespiegelt wird, die Berechtigungen nach Gruppe behandelt. Normalerweise wird eine Berechtigungsgruppe als erteilt angezeigt, solange mindestens eine der Berechtigungen in dieser Gruppe erteilt ist. Wenn Sie sicherstellen möchten, dass Benutzer den Widerruf in den Einstellungen bestätigen können, müssen Sie sicherstellen, dass Sie jede Berechtigung in der Berechtigungsgruppe widerrufen. Um zu erfahren, welche Berechtigungen zu einer bestimmten Gruppe gehören, können Sie PackageManager.getGroupOfPlatformPermission und PackageManager.getPlatformPermissionsForGroup verwenden.

Wenn das System die angeforderten Berechtigungen widerruft, widerruft es auch die entsprechenden Hintergrundberechtigungen, wenn keine der entsprechenden Vordergrundberechtigungen mehr gewährt werden.

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.

Sobald der Widerruf einer Berechtigung wirksam ist, können Sie ihn erneut anfordern und der Benutzer wird aufgefordert, der Anforderung zuzustimmen oder sie abzulehnen. Es ist nicht möglich, eine Berechtigung anzufordern, die zuvor vom Benutzer verweigert wurde. Wir empfehlen Ihnen zwar, Berechtigungen zu widerrufen, über die Sie derzeit verfügen, die aber nicht mehr benötigt werden. Sie sollten jedoch darauf achten, den Benutzer erst nach Inkrafttreten des Widerrufs über den Widerruf zu informieren.