Enable default enforcement of READ_EXTERNAL_STORAGE on non-user
builds. Users can still explicitly enable enforcement in Settings.
Bug: 6131916
Change-Id: I7dc66b624ad252ed2a2ad3647f3ea85dda7f8e82
Broadcast intents that get sent out when users are added/removed/switched.
More work on generating user-specific information in package manager queries.
APIs to update user name and query a user by id.
Removed Package.mSetStopped and mSetEnabled, since they're not user specific.
User removal:
- Cleanup ActivityManager, PackageManager, WallpaperManager, AppWidgetService
and AccountManager.
- Shutdown processes belonging to the user.
Don't show vibrate option in long-press power if there's no vibrator.
Lock the screen when switching users, to force unlocking.
Change-Id: Ib23a721cb75285eef5fd6ba8c7272462764038fa
Packages can be enabled/disabled per user.
This requires maintaining stopped/launched states and
enabled / disabled components and packages per user.
Refactored pm.Settings and PackageSettingsBase to keep
track of states per user.
Migrated the stopped-packages.xml to users/<u>/package-restrictions.xml
Changed intent resolution to handle individual user restrictions.
Bunch of IPackageManager calls now have a userId argument.
Make AppWidgetService handle removals of packages.
Added some tests for pm.Settings and PackageManager.
Change-Id: Ia83b529e1df88dbcb3bd55ebfc952a6e9b20e861
Store enforcement state of specific permissions, allowing them to be
selectively enforced. Currently supports READ_EXTERNAL_STORAGE, which
by default isn't enforced, but enforcement can be enabled at runtime.
Bug: 6131916
Change-Id: I4bcc215a2eb5e6507d6257b577311cbd13c77acf
These are permissions that an application can request, but won't
normally be granted. To have the permission granted, the user
must explicitly do so through a new "adb shell pm grant" command.
I put these permissions in the "development tools" permission
group. Looking at the stuff there, I think all of the permissions
we already had in that group should be turned to development
permissions; I don't think any of them are protecting public APIs,
and they are really not things normal applications should use.
The support this, the protectionLevel of a permission has been
modified to consist of a base protection type with additional
flags. The signatureOrSystem permission has thus been converted
to a signature base type with a new "system" flag; you can use
"system" and/or "dangerous" flags with signature permissions as
desired.
The permissions UI has been updated to understand these new types
of permissions and know when to display them. Along with doing
that, it also now shows you which permissions are new when updating
an existing application.
This also starts laying the ground-work for "optional" permissions
(which development permissions are a certain specialized form of).
Completing that work requires some more features in the package
manager to understand generic optional permissions (having a
facility to not apply them when installing), along with the
appropriate UI for the app and user to manage those permissions.
Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
Ensure that all requests to read the list of installed packages
go through the PackageManager directly. Don't allow non-system
program to directly read the raw package list files.
Change-Id: Id083e6b3de4dd9173abfdc741ebf3f60997a1052
...the "Complete action using" dialog
When an application goes idle, it sends back to the activity manager
the configuration it last used, to make sure the two don't get out
of sync. Fix a bunch of edge cases here in dealing with that, and
be sure to also send the current configuration when launching an
activity so the client is always up-to-date when launching.
Also a small fix to not show the upgrading dialog during first boot.
Change-Id: I14ed366a87cd689d1c78787369e052422290ac6f
This adds a special device identifier that is usable only for device
validation. The user will be presented with this number encoded in
easily-transcribable Base32 in the Developer options of Settings.
Change-Id: I4843f55ee90d689a51d0269b22454ca04c1be7ec
If a system package was updated that used permissions provided by a
package signed with a different signature, it wouldn't grant
those permissions to the updated system app.
This is because the sharedUser field was not set in the disabled system
package. Therefore it was checking the disabled system package's
individual user permission grants which were empty.
This change populates the sharedUser field for disabled system packages
after reading all the existing shared users from the saved settings
database.
Bug: 4245273
Change-Id: I57c58c4083bd59f45095c184d6ca5a302f79ff6e
Split the dump() command between PMS and Settings.
Try to annotate all users of the mPackages lock in preparation for
switch to reader/writer lock.
Also mark some locals final as I was reading through the usage of the
synchronization on mPackages.
Change-Id: Ia7add63e835e67156edf886f98acebe50cc41f70
Split PackageManagerService from one monolithic class with several inner
classes to several classes. This will help determining how its data
structures can be reshuffled to provide better separation of concerns.
Change-Id: Ic7571daebdcf13ce08e08f34204c5bbf4140139b
