| 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
|