I am getting tired of writing package monitor code, realized this is missing in
a number of places, and at this point it has gotten complicated enough that I
don't think anyone actually does it 100% right so:
Introducing PackageMonitor.
Yes there are no Java docs. I am still playing around with just what this
thing is to figure out what makes sense and how people will use it. It is
being used to fix this bug for monitoring voice recognizers (integrating the
code from the settings provider for setting an initial value), to replace
the existing code for monitoring input methods (and fix the bug where we
wouldn't remove an input method from the enabled list when it got
uninstalled), to now monitor live wallpaper package changes (now allowing
us to avoid reverting back to the default live wallpaper when the current
one is updated!), and to monitor device admin changes.
Also includes a fix so you can't uninstall an .apk that is currently enabled
as a device admin.
Also includes a fix where the default time zone was not initialized early
enough which should fix issue #2455507 (Observed Google services frame work crash).
In addition, this finally introduces a mechanism to determine if the
"force stop" button should be enabled, with convenience in PackageMonitor
for system services to handle it. All services have been updated to support
this. There is also new infrastructure for reporting battery usage as an
applicatin error report.
Don't go looking at attributes of a package struct without first verifying
that the struct pointer is non-null: in the failed-install case, of course
there will be no package info.
Change-Id: I3b2cafca2f1e3891a6592825ce5bcc977e7f3483
When an application being installed defines a backupAgent in its manifest, we
now automatically perform a restore of the latest-known-good data for that app.
This is defined as "data backed up by this app from this handset, if available;
otherwise data for this app as it existed when the device was initially
provisioned." If neither option exists for the app, no restore action is
taken.
The CL involves major changes in the Backup and Package Managers...
* The Package Manager's act of installing an application has now been split
into two separate phases, with a data-restore phase optionally occurring
between these two PM actions. First, the details of the install are performed
as usual. Instead of immediately notifying install observers and issuing the
install-related broadcasts, the in-process install state is snapshotted and
the backup manager notified that a restore operation should be attempted. It
does this by calling a new API on IBackupManager, passing a token by which it
identifies its in-progress install state.
The backup manager then downloads [if possible] the data for the newly-installed
application and invokes the app's backupAgent to do the restore. After this
step, regardless of failure, it then calls back into the Package Manager to
indicate that the restore phase has been completed, supplying the token that
was passed in the original notification from the Package Manager.
The Package Manager then runs the final post-install actions: notifying install
observers and sending out all the appropriate broadcasts. It's only at this
point that the app becomes visible to the Launcher and the rest of the OS.
... and a few other bits and pieces...
* The ApplicationInfo.backupAgentName field has been exposed to the SDK. This
can be reverted if there's a reason to do so, but it wasn't clear that this
info needs to be hidden from 3rd party apps.
* Debug logging of restore set IDs and operation timeout tokens [used during
any asynchronous Backup Manager operation] are now consistently in hex for
readability.
* We now properly reset our binder identity before calling into the transport
during restore-set operations. This fixes a permissions failure when a
single-app restore was attempted.
* The 'BackupTest' test app is no longer lumped onto the system partition
by default.
Change-Id: If3addefb846791f327e2a221de97c8d5d20ee7b3
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.
This will allow Market and others to find out what the "real" name
of a package is, when it is currently running under the old name of
a previously installed version.
We now have the new package retain the name of the old package. This makes
sure that all existing references to it (shortcuts, widgets, etc) will still
work.
This does mean that your package can run under either the old or new name,
depending on whether the user got it with an update. Buyer beware!
I have tried testing all of the paths of updating, installing another
update in /data, uninstalling the update, updating system with an even
newer update, etc. I think they all work. No promises though.
This file contains uid + debugFlag + dataPath information for
each non-system installed package. It is meant to be used later
from native code and thus needs to be considerably simpler to
parser than packages.xml.
The file should only be readable by non-system userIds, and its
format is essentially line-based with each line like:
<pkgName> <uid> <debugFlag> <dataDir>
With:
<pkgName> as the package name
<uid> as the application-specific user id
<debugFlag> either 0 or 1. 1 if the package is debuggable
<dataDir> path to the package's data directory
We need the debug flag to allow 'run-as' to only allow
commands to be executed on debuggable packages, even on
production devices.
This implements the spec for external storage organization, and
properly reflects how the media scanner organizes the files it finds.
Also includes package manager support for removing app private
files from external storage when the application is uninstalled.
For the new APIs and paths, the main place to look is Environment
and Context.
- Move android.storage.* -> android.os.storage.* and refactor users
- Refactor generic shares back to explicit ums enable/disable/isEnabled
- Remove media insert/removed event callbacks (not ready for Froyo)
- Remove 'label' from volume state change callbacks
- Add public API functions for enabling/disabling USB mass storage (permissions enforced
in MountSevice)
- Remove some stray un-needed import lines
- Move android.os.IMountService / android.os.IMountServiceListener -> android.os.storage
- Improve code comments
Updated:
MountService: Add dup state check and move debugging behind a conditional
UsbStorageActivity: Fix review comments + a TODO
StorageNotification: Add @Override tags
StorageManager: Don't use a static Listener list
MountService: Reduce bloat and fix == where I meant .equals()
PackageManagerTests: Update for new API
Signed-off-by: San Mehat <san@google.com>
This adds three new features:
- <original-package android:name="com.foo" /> manifest tag.
This allows an .apk to specify another package it originally came from,
propagating all state and data from the old to new package.
- <adopt-permissions android:name="com.foo" /> manifest tag.
In some more complicated cases, a new .apk may be a combination
of multiple older .apks that each declared their own permissions.
This allows you to propagate the permissions from these other
.apks into the new one.
- A new system/etc/updatecmds directory.
You can place files here which describe data files to move from
one package to another. (See below for details.)
Also in this change: we now clean up the data directories of
.apks that disappear from the system image, and some improvements
to logging and reporting error messages.
A typical file in the updatecmds directory looks like this:
-------
com.google.android.gsf:com.google.android.providers.talk
databases/talk.db
com.google.android.gsf:com.google.android.googleapps
databases/gls.db
-------
This says that for com.google.android.sfs, there are two packages to
move files from:
From com.google.android.providers.talk, the file databases/talk.db.
From com.google.android.googleapps, the file databases/gls.db
As part of moving the file, its owner will be changed from the old
package to whoever is the owner of the new package's data directory.
If those two files had existed, after booting you would now have the
files:
/data/data/com.google.android.gsf/databases/talk.db
/data/data/com.google.android.gsf/databases/gls.db
Note that all three of these facilities assume that the older .apk
is completely removed from the newer system. The WILL NOT work
correctly if the older .apk still remains.
Add new broadcasts ACTION_MEDIA_RESOURCES_AVAILABLE and
ACTION_MEDIA_RESOURCES_UNAVAILABLE that get broadcast by
PackageManagerService when sdcard gets mounted/unmounted
by MountService so that packages on sdcard get recognized by
various system services as being installed/available or
removed/unavailable by the system.
The broadcasts are sent before the actual package cleanup which includes
mounting/unmounting the packages and we force a gc right after so
that any lingering file references to resources on sdcard get
released.
The method packageManagerService.getNextCodePath(String oldCodePath,
String prefix, String suffix) threw StringIndexOutOfBoundsException if
oldCodePath does not contain prefix, and prefix is longer than
oldCodePath, or if the preix and suffix overlap.
Fixes http://b/issue?id=2404232
Change-Id: Ib8abb16f8bfd08f607476d9289f46d170c43a076
Add new remote interface to do temporary copies. The new
remote stub handling is done on mHandler thread and doesn't need locking
for now.
Add new InstallArgs class and subclasses to isolate cases for installation.
Move resource deletion for failed installs/upgrades to later on in installation
cycle.
Fix code path for forward locked apps when using scanPackageLI
TODO's
Fix installation paths to completely use InstallArgs based design later on.
Get rid of using flags in various install/uninstall code paths.
Ideally InstallArgs should be created using these flags and used in the
rest of the code.
Function renames.
Revisit mount api's.
Native-debuggable packages contain a lib/<abi>/gdbserver executable.
This patch ensures that the package manager will copy it to the
proper location (/data/data/<appname>/lib) at installation time.
Note that such packages are marked with a new ApplicationInfo flag
named FLAG_NATIVE_DEBUGGABLE, to be used later by the Activity
Manager.
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
We can now locate event log tag definitions in individual packages
(and java constants for the tag numbers get auto-generated), so move
all the tags used by the system server into the package.
The goal of this change is to allow the Package Manager to look for native
shared libraries corresponding to the CPU ABI reported by ro.product.cpu.abi2
if none was found for the CPU ABI given by ro.product.cpu.abi
This is used to support both ARMv5 and ARMv7 native code on modern ARMv7-based
devices. Typically, such a device would report a primary ABI of 'armeabi-v7a'
and a secondary one of 'armeabi', to indicate that it can run the binaries
generated for both.
Also reworks this intent protocol a little bit to be much more efficient, only
requiring one broadcast per package.
Change-Id: I580de4843ebd3c7f2e6df7295a2f80d2937cef7c
the package about to be deleted or upgraded when updating permissions associated
with the shared user. Include a simple null check when retrieving the permission.
Fix PackageParser to avoid ArrayIndexOutOfBounds exceptions in several places
when reading settings in PackageManager, we might rename the corrupted settings to
backup(in case of power failure between the earlier write failure and file deletion)
and end up loosing both files.
So just clear up the corrupted current settings file if we have backup.
The backup wouldn't exist if everything went well with persisting the earlier settings.
We do this in both read and write just in case.
Return valid package info for packages that have been uninstalled with
an option to retain data and resources using the flag GET_UNINSTALLED_PACKAGES
These packages do not have a package setting. just check the flag and return
the required info from PackageParser.generatePackageInfo
If not these system services will end up with inconsistent settings files
when the device runs out of storage.
Delete mangled settings file in PackageManager if the current write fails
so that we don't end up overwriting the backed up version with the
mangled version
Include null check when retrieving fwd locked resource for an existing package
I think when we were scanning the updated app in the system image,
from an older version on the data partition, we were not setting
the existing package to have the system flag, so not auto-granting
any new permissions.
This also includes some other cleanup in the package manager to
remove old files in various places, and tighten up logging.
Also similar logging cleanup elsewhere.
Change-Id: I6d113c7cf7e736ab9be512d6d7c94c806a24199a
PM first creates a temporary file from the input package uri before installing it.
if the package uri points to a content uri, the content provider has to be retrieved via the ActivityManager
which could cause deadlocks with the package manager locks being held.
Clean up by always copying or creating temporary files before acquiring these locks.
Fix issue when restoring a failed upgrade for third party apps.
This is needed to allow the BugReportService to start the dumpstate service.
Change-Id: I12cab23767c919592da102c654b6b80416717661
Signed-off-by: Mike Lockwood <lockwood@android.com>
components by apps which could result in thrashing on the PackageManager. For apps that
do not want to be restarted when such a broadcast is sent, we can just aggregate these broadcasts and
handle them at one go.
Changes include:
New structure to hold pending broadcasts by class name. If a component is enabled or disabled frequently
aggregate component enabled/disabled settings in this structure in a 10 second window and then
send out the accumulated list of broadcasts to the ActivityManager.
A new Handler implementation handles this message
Add new attribute name EXTRA_CHANGED_COMPONENT_NAME in broadcast intent Intent.ACTION_PACKAGE_CHANGED for
additional information for apps like Launcher.
Rename a couple of parameters, the names were too jarring.
