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
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
Switching activity stacks
Cache ContentProvider per user
Long-press power to switch users (on phone)
Added ServiceMap for separating services by user
Launch PendingIntents on the correct user's uid
Fix task switching from Recents list
AppWidgetService is mostly working.
Commands added to pm and am to allow creating and switching profiles.
Change-Id: I15810e8cfbe50a04bd3323a7ef5a8ff4230870ed
Adds a really crappy UI for toggling compat mode.
Persists compat mode selection across boots.
Turns on compat mode by default for newly installed apps.
Change-Id: Idc83494397bd17c41450bc9e9a05e4386c509399
To avoid blowing past the Binder IPC limit, change the
PackageManagerService to have a DB-like interaction where the client
tells the service the last "row" that it read.
The fact that we use a HashMap instead of a TreeMap makes this
problematic. For now we're just making a new ArrayList for the keys and
then sorting them for each call. This can make the API slower for callers
of this, but it's probably greatly overshadowed by the cost of the data
transfer itself.
Bug: 4064282
Change-Id: Ic370fd148d4c3813ae4f2daffa1a7c28d63d5a09
- Create /data/user directory and symlink /data/user/0 -> /data/data for
backward compatibility
- Create data directories for all packages for new user
- Remove data directories when removing a user
- Create data directories for all users when a package is created
- Clear / Remove data for multiple users
- Fixed a bug in verifying the location of a system app
- pm commands for createUser and removeUser (will be disabled later)
- symlink duplicate lib directories to the original lib directory
Change-Id: Id9fdfcf0e62406a8896aa811314dfc08d5f6ed95
Before the IPackageDeleteObserver only knew whether the deletion
succeeded or failed, but not the reason why.
Bug: 2520191
Change-Id: I1f0d7c04f06c539660b6e17e7e133defb0f61b5b
...current process has android.permission.WAKE_LOCK
When updating a system app, we would actually uninstall the package
of the system app, which also meant removing its uid...! It was just
luck that we would get the same uid when installing the update after
that. During that time, if anyone tried to do anything related to
that uid, it would be unknown.
This change tweaks how we go about replacing system apps by making
it more like normal apps -- to make this work, if we need to disable
the system app, we generate a new PackageSetting from the current
system app and replace it into our data structures, so we can update
that without trashing the current correct information about the (still
actually there) system app.
Also fixed a problem where we were not killing the currently running
app before installing, like we do when updating a normal application.
And fixed a problem where we were not deleting the /data .apk when
uninstalling a system app update.
And added a new option to the "pm" command to clear the data associated
with an app.
Change-Id: I0e879677849aa42950a3c360bf78ad820e87674b
Includes some other small fixes to battery collection and a few
other things.
Output of package info looks like this:
5,0,i,uid,1000,com.android.settings
5,0,i,uid,1000,com.android.providers.subscribedfeeds
5,0,i,uid,1000,com.android.providers.settings
5,0,i,uid,1000,com.android.server.vpn
5,0,i,uid,1000,android
5,0,i,uid,1000,com.android.systemui
5,0,i,uid,1000,com.google.android.backup
5,0,i,uid,1001,com.android.phone
5,0,i,uid,1001,com.android.providers.telephony
5,0,i,uid,1022,com.android.nfc
5,0,i,uid,10021,com.google.android.location
5,0,i,uid,10021,com.google.android.syncadapters.calendar
5,0,i,uid,10021,com.google.android.gsf
5,0,i,uid,10021,com.google.android.syncadapters.contacts
5,0,i,uid,10026,com.android.providers.downloads.ui
5,0,i,uid,10026,com.android.providers.media
5,0,i,uid,10026,com.android.providers.drm
5,0,i,uid,10026,com.android.providers.downloads
5,0,i,uid,10032,com.android.launcher
5,0,i,uid,10039,com.google.android.gm
5,0,i,uid,10041,com.google.android.gallery3d
5,0,i,uid,10049,com.android.providers.calendar
Change-Id: I9e38f254eef146339113ad270f5c6e8b60fb7a1d
pm command makes the assumption that every permission should
contain android:description and android:label attributes while
they are not mandatory. If a permission does not contain these
two attributes, we get "android.content.res.
Resources$NotFoundException: String resource ID #0x0"
followed by a NPE when using -f or -s options.
With the following change, users will get "null" in output for
respective fields.
Change-Id: I4e7f407592fa071abdab1d979775f46ec27dc9d2
Move install location values to secure settings.
Diable attribute for UI. Set default value to auto.
Add command line interface to set install location via pm.
Change-Id: I80e97b3d24845adad7102f40dcbe238f00efa406
PackageManager invokes this call back when its done handling
the media status update.
Add new uid check for updateExternalMediaStatus
Change killPids method in ActivityManager.
Remove mountsd command in Pm.java We cannot arbitrarily enable/disable
packages in PackageManager now.
Change-Id: I28dcba4afd2b4486f68abdaa1628a31b66544c91
Changes include
Add new remote call in default container service to determine
install location.
Rename INSTALL_ON_SDCARD
Remove recommentAppInstall method
Add some additional flags used in remote stubs.
Move check for protected apps prior to copy.
Unit tests
DefaultContainerService first parses the file uri(if content uri is specified
it returns a default install internal only value) and returns
a recommended location. Based on which the temporary id is determined
either a file name or a container id and the file is copied there.
This is then later renamed during install.
Todo's light weight parsing of package when determining location since we
just need the install location attribute only when finding out
recomended location. This will also enable to move the check for
updated system apps(cannot be on sdcard) prior to copying.
Persist flags in PackageSetting. Flags are relevant to ApplicationInfo.FLAG_SYSTEM, Application.FLAG_ON_SDCARD, ApplicationInfo.FLAG_FORWARD_LOCK.
New pm command to simulate mount/unmount in Pm. This will be removed
when MountService/vold event generation gets fixed.
Calls from MountService into PackageManager when media gets mounted/unmounted.
Scan the packages and grant permissions when the sdcard gets mounted.
This api might change again.
to install an app on sdcard, just resources.
Add new install path for /asec in installd.
ignore . when checking for apk path since the sdcard packages id'ed
by package name.
Add new -s option to adb shell pm
Refactor fwd locked from scanMode to ApplicationInfo.
Add new flag for sd install
Add new parse flags for fwd locking and installing on sdcard
New mock api's in PackageManagerService to invoke MountService api's. These
will be refactored again and so have been wrapped internally.
Some error codes in PackageManager
Changes in PackageManagerService to use mPath and mScanPath during installation
and switch to using PackageParser.Package.applicationInfo attributes for
source and public resource directories.
Some known issues that will be addressed later
using system_uid for now. needs some tinkering with uid and packagesetting creation to use the actual app uid
error handling from vold not very robust. ignoring lot of things for now
sending a delayed destroy to delete packages. will revisit later
revisit temp file creation later. just copy for now
Instead of a switch that needs to be maintained, the code now
look for public static final int fields in PackageManager
whose names start with INSTALL_FAILED or INSTALL_PARSE_FAILED.
If their int value match the error code, the name of the field
is used as a human readable error string.
Change-Id: If58ddc4d9ccc40a9a8aaec9de4cc7e4931db0292
You can now use android:testOnly="true" to not allow your .apk to be installed
as a normal app. The only way to do so is with the pm command and giving the
-t option, which sets a new INSTALL_ALLOW_TEST flag when installing.
I also used this to clean up the install API... actually, mostly to hide
it, since it is not accessible to apps so shouldn't be in the SDK. We
will be doing some more work on it, so this will prevent adding yet
another backwards-compatibility-for-no-reason version.
This adds new attributes for specifying a targetSdkVersion and maxSdkVersion.
There is a new ApplicationInfo flag that is set if the application has set
its targetSdkVersion to the current platform or later. Also you can now
use a string for minSdkVersion and targetSdkVerion, to indicate you are
building against a development tree instead of an official platform.
