2016-05-10 11 views
4

Frage zu Android-Laufzeitberechtigungen. AFAIK, Android gewähren gefährliche Erlaubnis zur Laufzeit. Ich setze mein Telefon zurück, dann adb pull /data/system/users/0/runtime-permissions.xml, ich fand android.ui.system hat bereits viele gefährliche Berechtigungen gewährt. kann mir jemand sagen, wie es geht?Android-Laufzeitberechtigung für System-Apps

+0

gibt es einige Berechtigungen, die braucht hier nicht gewährt werden, siehe für Details: - http://coderzpassion.com/android-new-runtime-permissions/ –

+0

danke Jagjit. Dies ist Teil von runtime-permissions.xml, user1890874

+0

Wie Sie sehen können, sind diese Berechtigungen gefährliche Berechtigungen, sie sollten zur Laufzeit gewährt werden, aber sie wurden beim ersten Start gewährt, es ist verwirrt. – user1890874

Antwort

8

Der Mechanismus zum Einfügen der Runtime-Berechtigung in den Dateibestätigungsdialog /data/system/users/0/runtime-permissions.xml für Gefährliche Berechtigungsstufe gilt für Anwendungen von Drittanbietern. Dies ist für integrierte Anwendungen nicht relevant.

Für eingebaut/Systemanwendungen und Framework-Komponenten, die alle Berechtigungen werden standardmäßig gewährt, wenn ein neuer Benutzer angelegt wird oder Gerät bootet und systemReady Ereignis wird gebrannt.

Sie können die AndroidManifest.xml von AOSP sehen, wo alle Arten von erforderlichen Berechtigungen für Systemkomponenten geschrieben werden.

Bei Apps von Drittanbietern, wenn der Benutzer Laufzeitberechtigungen erteilt, wird er in die Datei /data/system/users/0/runtime-permissions.xml hinzugefügt und entfernt, wenn Sie die Genehmigung einer Drittanbieter-App widerrufen. während nach dem Zurücksetzen auf die Werkseinstellungen die Laufzeitberechtigung aller Apps von Drittanbietern entfernt wird, da /data/system/users/0/runtime-permissions.xml gelöscht wird (Datenpartitionswipe).

Aber auch nach dem Zurücksetzen auf die Werkseinstellungen enthält /data/system/users/0/runtime-permissions.xml Laufzeitberechtigungen (sogar gefährliche Stufe) für Systemanwendungen, siehe Standardberechtigungen: runtime-permissions.xml.

Und es geschieht, weil:

die alle Standardberechtigungen erteilt werden aus PackageManagerService, über diese beiden Methoden:

newUserCreated() //this get called when new user is created 
systemReady() //this get called when device is booted 

und über Methoden intern aufruft:

DefaultPermissionPolicy.grantDefaultPermissions();

Have a look at How DefaultPermissionPolicy triggers

Und wenn Sie DefaultPermissionPolicy's implementation sehen, es enthält alle relevanten Verfahren alle Arten von Berechtigungen für Systemkomponenten zu laden.

Insbesondere DefaultPermissionPolicy.grantDefaultPermissions() ruft intern

grantPermissionsToSysComponentsAndPrivApps(userId); grantDefaultSystemHandlerPermissions(userId);

und intern sie gibt Anrufe grantRuntimePermissionsLPw() Methode, which performs all the remaining work.

+0

Danke shridutt kothari. In der b eginning, no runtime-permissions.xml, dann wurde PackageManagerService gestartet und generiert runtime-permissions.xml. Um dies deutlicher zu verstehen, können Sie aufzeigen, wo die Laufzeitberechtigungen für android.uid.system erteilt wurden, wie in der Datei runtime-permissions.xml zu sehen ist. – user1890874

+0

Ich fand unten Code in der RuntimePermissionPersistence-Klasse. aber ich habe nicht gefunden, wo PermissionState für android.uid.system als gewährt festgelegt wurde. – user1890874

+0

final int sharedUserCount = BerechtigungenForSharedUser.size(); für (int i = 0; i permissionStates = permissionsForSharedUser.valueAt (i); serializer.startTag (null, TAG_SHARED_USER); serializer.attribute (null, ATTR_NAME, Paketname); writePermissions (Serializer, permissionStates); Serializer.endTag (null, TAG_SHARED_USER); } – user1890874

Verwandte Themen