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 bewegte Android - Anwendungen , die gefährlichen Berechtigungen erforderlich (siehe Betroffene Berechtigungen ) von einem Installationszeit Berechtigungsmodell zu einem Laufzeitberechtigungsmodell:

  • Berechtigungen für die Installationszeit

    (Android 5.1 und niedriger) Benutzer gewähren gefährliche Berechtigungen zu einer App , 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 gefährliche Berechtigungen für eine App , wenn die Anwendung ausgeführt wird. Wann Berechtigungen angefordert werden (z. B. wenn die App gestartet wird oder 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/Träger können Apps vorinstallieren, aber keine Berechtigungen im Voraus erteilen, es sei denn, sie durchlaufen den Ausnahmeprozess. (Siehe Ausnahmen anlegen .)

    (Android 10) Benutzer sehen eine erhöhte Transparenz und die Kontrolle über die Apps Aktivitätserkennung (AR) Laufzeitberechtigungen verfügen. Benutzer aufgefordert werden , die durch die Laufzeitberechtigungen Dialog entweder immer erlauben, erlauben während der Benutzung oder Berechtigungen verweigern. Auf einem OS - Upgrade auf Android 10, Apps gegeben Berechtigungen werden beibehalten, aber die Benutzer in Einstellungen gehen und sie ändern.

Laufzeitberechtigungen verhindern, dass Apps ohne Zustimmung des Benutzers auf private Daten zugreifen, und bieten ihnen zusätzlichen Kontext und Einblick in die Arten von Berechtigungen, die Anwendungen entweder suchen oder ihnen 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 höheres Risiko Berechtigungen (wie READ_CALENDAR ), die den Zugriff gewährt anfordernden Anwendungen private Benutzerdaten oder die Kontrolle über eine Vorrichtung, die den Benutzer negativ 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 nicht das Verhalten ändern normalen Berechtigungen . Dies sind alles ungefährliche Berechtigungen, einschließlich Normal-, System- und Signaturberechtigungen. Normale Berechtigungen sind risikoärmere Berechtigungen (wie SET_WALLPAPER ) , die Anwendungen den Zugriff auf isolierte Anwendungsebene bietet mit minimalem Risiko für andere Anwendungen gewähren anfordert, das System oder den Benutzer. 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 den Berechtigungen finden Sie in der <permission> -Element - Dokumentation.

Harte und weiche Einschränkungen in Android 10

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

  • (Harte Einschränkungen) Apps können keine Berechtigungen erteilt werden , die nicht die weiße Liste gesetzt werden.
  • (Soft Einschränkungen) Apps ohne weiße Liste verhalten sich entsprechend der spezifischen Erlaubnis sie beantragen. Das Verhalten ist in der öffentlichen Dokumentation für die angeforderte Erlaubnis beschrieben.

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

Whitelisting erfolgt während der Installation und wenn

  • bei einem Android 9-to-10-Upgrade ist bereits eine App installiert.
  • eine Berechtigung wird vorab erteilt oder eine App ist vorinstalliert.
  • Für eine bereits definierte Rolle ist eine Berechtigung erforderlich, um die Berechtigung auf die weiße Liste zu setzen.
  • das Installationsprogramm (z. B. Google Play Store) markiert die Berechtigung als Whitelist.

Benutzer können Berechtigungen nicht manuell auf die weiße Liste setzen.

Anforderungen

Das Laufzeitberechtigungsmodell gilt für alle Anwendungen, einschließlich vorinstallierter Apps und Apps, die im Rahmen des Einrichtungsprozesses auf dem Gerät bereitgestellt werden. Die Anforderungen an die Anwendungssoftware umfassen:

  • 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 auffordern, Anwendungsberechtigungen zu erteilen. Weitere Einzelheiten finden Sie Aktualisieren von Anwendungen . Begrenzte Ausnahmen können Standardanwendungen und Handlern gewährt werden, die grundlegende Gerätefunktionen bereitstellen, die für den erwarteten Betrieb des Geräts grundlegend sind. (Zum Beispiel die Standard - Dialer App für den Umgang des Geräts ACTION_CALL können Telefon Erlaubnis Zugriff haben.) Weitere Informationen finden Sie Ausnahmen erstellen .
  • Vorinstallierte Apps mit gefährlichen Berechtigungen müssen auf API-Ebene 23 abzielen und das Laufzeitberechtigungsmodell beibehalten. Das heißt, der UI-Flow 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. Weitere Einzelheiten finden Sie Headless - Anwendungen .

Berechtigungsmigration

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

In einem Android 9-auf-10-Update werden alle stark eingeschränkten Berechtigungen auf die weiße Liste gesetzt. Ausführliche Informationen zur Durchführung der Vordergrund / Hintergrund - Split - Berechtigungen finden Sie Android 10 Privatsphäre ändern , beginnend mit Antrag Hintergrund Lage .

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 Anwendungen definieren , die der Standard - Handler / Anbieter für Kernfunktionalität sind, benutzerdefinierte Berechtigungen definieren, und das Thema in dem verwendeten anpassen PermissionController App.

Aktualisieren von Anwendungen

Anwendungen auf dem Systemabbild und vorinstallierte Anwendungen sind nicht automatisch vorab erteilte Berechtigungen. Wir empfehlen Ihnen, die Arbeit mit vorinstallierten App - Entwickler (OEM, Träger und Dritten) die erforderlichen Änderungen App verwenden , um Richtlinien für Entwickler . 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. Zum Beispiel muss der UI Fluss während einer App - Installation nicht von der AOSP Implementierung abweichen PermissionController . Benutzer können sogar die gefährlichen Berechtigungen vorinstallierter Apps widerrufen.

In Android 6.0 bis 9 werden einige Berechtigungen während des Installationsvorgangs erteilt. Doch in 10 starten, die Strömung installieren (durch die durchgeführt Package Installer App) ist eine separate Funktion von Berechtigungen gewährt (im Permission Controller - 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.)
    • Geben Sie eine UID für eine andere Anwendung frei, die über die erforderlichen Berechtigungen verfügt. Verwenden Sie diese Methode nur, wenn Sie die Plattform benötigen, um mehrere APKs als eine einzige Anwendung zu verarbeiten.

Das Ziel besteht darin, Benutzer nicht mit Berechtigungsanfragen zu verwirren, die außerhalb des Kontexts erscheinen.

Anpassen der PackageInstaller-Benutzeroberfläche

Falls gewünscht, können Sie die Berechtigungen UI Thema durch die Aktualisierung der Standardgeräte Themen (fertigen Theme.DeviceDefault.Settings und Theme.DeviceDefault.Light.Dialog.NoActionBar ) , die von PackageInstaller. Da jedoch Konsistenz für App-Entwickler 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 Strings für weitere Sprachen sind, tragen die Saiten zu AOSP.

Ausnahmen erstellen

Sie können auf Anwendungen vorab Berechtigungen erteilen , die Standard - Handler oder Anbieter für Core OS - Funktionalität mit der sind DefaultPermissionGrantPolicy.java Klasse in Packagemanager . 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 als gefährlich und fügen Sie OEM / Carrier-spezifische Berechtigungen für vorhandene Berechtigungen Gruppen, wie Sie kann in Android 5.x und früheren Versionen definieren.

Wenn Sie in Android 6.0 und höher eine neue gefährliche Berechtigung hinzufügen, muss diese genauso behandelt werden wie andere gefährliche Berechtigungen (wird während der App-Laufzeit angefordert und kann von Benutzern widerrufen werden). 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 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 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.