3cd658e1a598e59738bc129c35eecf4cd0f20680 |
|
17-Aug-2016 |
Todd Kennedy <toddke@google.com> |
More refactoring * Break apart getSettingsWithBenefits() into separate methods for creating new settings and updating settings, etc... * Add more hooks to test equality of setting clones * Create tests for each subset of functionality Bug: 30219944 Change-Id: I1fb3d07bb9279f93ba81ada2ff802989ec2c5965
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
5e57a20c09512c676bc1ac938c5a2516ba260f72 |
|
30-Jun-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Performance optimizations in generatePackageInfo In PM.generatePackageInfo, granted permissions (returned by permissionsState. getPermissions) are only used if the package has a non-empty list of requested permissions. Added a shortcut to handle that. In my tests this shortcut is triggered in ~20% calls to PM.generatePackageInfo. Also added an early continue in PermissionsState.getPermissions. Calling hasRuntimePermission was not necessary in 90% cases. Also changed ArraySet to be created with capacity for all mPermissions -- this is the typical scenario, previously it was going through multiple grow operations. Bug: 29879962 Change-Id: Ic4d8914d1c4f4df447deee2e3e3a15a2594e90ef
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
9c165d76010d9f79f5cd71978742a335b6b8d1b4 |
|
02-Dec-2015 |
Svet Ganov <svetoslavganov@google.com> |
Add optional permission review for legacy apps - framework For some markets we have to allow the user to review permissions for legacy apps at runtime despite them not supporting the new permission model. This is achieved by showing a review UI before launching any app component. If an update is installed the user should see a permission review UI for the newly requested permissions. To allow distinguishing which permissions need a review we set a special flag in the permission flags that a review is required. This flag is set if a runtime permission is granted to a legacy app and the system does not launch any app components until this flag is cleared. Since install permissions are shared across all users the dangerous permissions for legacy apps in review mode are represented as always granted runtime permissions since the reivew requirement is on a per user basis. Whether the build supports permission review for legacy apps is determined by a build constant allowing us to compile away the unnecessary code for markets that do not require a permissions review. If an app launches an activity in another app that has some permissions needing review, we launch the permissions review UI and pass it a pending intent to launch the activity after the review is completed. If an app sends a broadcast to another app that has some permissions needing review, we do not deliver the broadcast and if the sending app is in the foreground plus the broadcast is explicit (has a component) we launch the review UI giving it a pending intent to send the broadcast after the review is completed. If an app starts a service in another app that has some permissions needing review, we do not start the service and if the calling app is in the foreground we launch the review UI and pass it a pending intent to start the service after the review is completed. If an app binds to a service in another app that has some permissions needing review, we schedule the binding but do not spin the target service's process and we launch the review UI and pass it a callback to invoke after the review is completed which spins the service process and completes the binding. If an app requests a content provider in another app that has some permissions needing review we do not return the provider and if the calling app is in the foreground we show the review UI. Change-Id: I550f5ff6cadc46a98a1d1a7b8415eca551203acf
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
ca8e6da41c6e63e3ed17eb461171f1ef2e1d29c6 |
|
25-Jun-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #22023824: Download folder is not created in internal storage The media provider and some other things need to be given storage access. Also, seems like we should give storage access to the camera app as well. And add a dump dump command that will dump data about a particular permission name. Change-Id: Idaaa9bba2ff4dc95290cf6d17e5df933df91e909
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
0bf8f7cc3982164a9e11ea4a25ed930e466f1dd8 |
|
22-Jun-2015 |
Amith Yamasani <yamasani@google.com> |
Runtime permissions cannot be set on legacy apps by device policy Clarify docs that runtime permissions can be granted or revoked by a profile owner/device owner only for MNC apps and not legacy apps. Check the targetSdkVersion and return false if legacy app. Remove all policy flags from permissions when cleaning up a device or profile owner. Bug: 21835304 Bug: 21889278 Change-Id: I4271394737990983449048d112a1830f9d0f2d78
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
91edde24ffa5d78df18bf752de88dfe2bc8c4119 |
|
20-May-2015 |
Jeff Sharkey <jsharkey@android.com> |
Write packages.list when adding/removing users. FUSE daemons now rely on getting per-user GID information when packages.list is written. Normal secondary user adding/removing usually has enough PackageManager traffic to trigger a side-effect rewrite, but this change writes explicitly to handle guest users. Also obtain the user list once, and exclude dying users. During user creation we manually splice in the user ID that we're bringing online. Bug: 19924661 Change-Id: Icc5b1b169300c9dc12099be12651acbf89d6bea9
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
b3f22b48bbd4e4816212e596e3cb612457d48fe5 |
|
12-May-2015 |
Svet Ganov <svetoslavganov@google.com> |
Runtime permissions for system components not revokable - framework Change-Id: I5b1d7bb1618ffa8d1231618ece47d0905c82f7bf
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
8c7f700a59ad26e75c9791335d78f14322cad49a |
|
07-May-2015 |
Svet Ganov <svetoslavganov@google.com> |
Add permission meta-state flags to support grant/revoke permission policy. We now maintain a mata-state with each permission in the form of flags specyfying the policy for this permission. This enables support of the following use cases: 1. The user denies a permission with prejudice in which case an app cannot request the permission at runtime. If an app requests such a permssion it gets a denial unless the user grants the permission from settings. 2. A legacy app with disabled app-ops being upgraded to support runtime permissions. The disabled app ops are converted to permission revocations. The app ops manager is a part of the activity manger which sits on top of the package manager, hence the latter cannot have a dependency on the former. To avoid this the package installer which is the global permission managment authority marks the permission as revoked on upgrade and the package manager revokes it on upgrade. 3. A device policy fixing a permission in a granted or revoked state. This additional information is folded in the meta-state flags and neither apps can request such permissions if revoked not the user can change the permission state in the UI. Change-Id: I443e8a7bb94bfcb4ff6003d158e1408c26149811
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
4f2dcfd48010a338dc9a2f5870ed12b382c30cd7 |
|
22-Apr-2015 |
Svet Ganov <svetoslavganov@google.com> |
Fix permission check imposed by broadcast sender. Change-Id: Id105b00aad7b369fa0337fa63753ce7ea71b3383
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
1b7025f264fd811ab27470867f8e65eeebf092e9 |
|
22-Apr-2015 |
Svetoslav <svetoslavganov@google.com> |
Report all permissions by type correctly Change-Id: I357ad52d022ffd7703cce7e1551fa10cc7edd72f
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
7aa6dfeb011e1886290f64958af9489ee0d25b6b |
|
20-Apr-2015 |
Svet Ganov <svetoslavganov@google.com> |
Report all permissions for user in PermissionsState Change-Id: I08a228018401820ef82cf1f95fe29556d3aeba5e
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
b3a6defec84ab1d420b049c575cb37b1151e095a |
|
11-Apr-2015 |
Svetoslav <svetoslavganov@google.com> |
Fix accounting of permission gids. bug:20143490 Change-Id: I718d4db74ebf003616241710a67774b2e2e5384f
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
d5752bdc8fd39d4f0a508f9088c538e30e73044a |
|
26-Mar-2015 |
Svet Ganov <svetoslavganov@google.com> |
Properly handle system app permissions - for real. System apps targeting SDK greater than Lollipop MR1 get runtime permissions by default but if the user takes them away we should not regrant them. To do that we keep track for each package which user ids were handled in the last permissions update. If a new user id has appeared we grant runtime permissions for this user to the sys package. When we start clean (i.e. first boot) the sys packages were updated for no user so we grant the runtime perms for the owner. When reading a package from packages.xml we set the updated user ids to all users ids on the device as the state in the xml reflects the latest state before a shutdown, i.e. the last state when permissions were updated. Change-Id: I93135baa57950405a357b139c59f432cf02f0bc6
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
00f3904629ef89192e061c1995801ef322fc0bcf |
|
24-Mar-2015 |
Jeff Sharkey <jsharkey@android.com> |
Introduce per-user GIDs for storage. This will eventually allow us to have a single unified filesystem instead of requiring zygote to use bind mounts. Change-Id: I29b819ab51498b4bab874e0367b1ab4165f84025
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|
c6d1c345f41cf817bf2c07c97b97107d94296064 |
|
26-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
Runtime permissions: per user permission tracking. Before all permissions were granted at install time at once, so the user was persented with an all or nothing choice. In the new runtime permissions model all dangarous permissions (nomal are always granted and signature one are granted if signatures match) are not granted at install time and the app can request them as necessary at runtime. Before, all granted permission to an app were identical for all users as granting is performed at install time. However, the new runtime model allows the same app running under two different users to have different runtime permission grants. This change refactors the permissions book keeping in the package manager to enable per user permission tracking. The change also adds the app facing APIs for requesting runtime permissions. Change-Id: Icbf2fc2ced15c42ca206c335996206bd1a4a4be5
/frameworks/base/services/core/java/com/android/server/pm/PermissionsState.java
|