| bdbc9692c7cb365d9d3f239baa2377724a6f7bc8 |
|
14-Dec-2015 |
Fyodor Kupolov <fkupolov@google.com> |
Introduced PRIVATE_FLAG_REQUIRED_FOR_SYSTEM_USER
When set, signals that the application is required for the system user and
should not be uninstalled.
Bug: 25616324
Change-Id: Idbbd1618e09c40bdb83fa26c0a3d9662dd73bea4
/frameworks/base/services/core/java/com/android/server/pm/SettingBase.java
|
| adc1cf46045ae756d3a9ccbccf6b0f894e4c1edd |
|
16-Jun-2015 |
Svet Ganov <svetoslavganov@google.com> |
Only grant runtime permissions to special components.
Now runtime permissions are granted only to components that are
part of the system or perform special system operations. For
exmple, the shell UID gets its runtime permissions granted by
default and the default phone app gets the phone permissions
granted by default.
bug:21764803
Change-Id: If8b8cadbd1980ffe7a6fc15bbb5f54a425f6e8f9
/frameworks/base/services/core/java/com/android/server/pm/SettingBase.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/SettingBase.java
|
| 37f05184b5641366b59c540ad6bf3e3b2a1ac6ea |
|
01-Apr-2015 |
Svet Ganov <svetoslavganov@google.com> |
Fix clobbered shared user install permissions.
The install permissions for a shared user were clobbered when a pending
package for this user was matched to the shared user after reading the
state from XML. The reason was that the copy code in PackageSettingBase was
using the getter to get its settings state to which to copy the permissions
for the pending package but this is the permissions state for the shared
user instead of the package. Since the pending package has no permissions
we ended up clobbering the permissions for the shared user.
bug:19955926
Change-Id: Ia8d090883d50fc987a32ceeed6c7562c49698328
/frameworks/base/services/core/java/com/android/server/pm/SettingBase.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/SettingBase.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/SettingBase.java
|