Add new remote method to check for insufficient error conditions.
Some fixes in MountService when updating media status on PackageManagerService
Fix size calculation condition in installd.
Add new error code if media is unavailable.
New tests for testing error codes.
Some additional debugging statements in MountService.
Change-Id: Ibfe90d5ed6c71d57f9c1c67806f38b5ae9ecdfbf
Use constants defined in PackageHelper for user preferences
to install auto, internal, external.
Set default install location to external.
Update settings db version number
Change-Id: Ib5110c9377990e20a48cee923e55898dfddfd1e6
Also sanity-check the package name on the Backup Manager side, failing gracefully
if the given package is not a backup/restore participant.
Bug: 2293977
Change-Id: I3575046ffcaa3cf45c1c602824baeadd64082f70
change hard coded path in installd
fix tests
Work around for renaming containers.
Do forced unmount when destroying containers.
Force a gc in default container service to release handle to parsed package
and thus avoid getting killed by vold
Some cosmetic changes to PackageManager api.
Unit tests for renaming container for MountService
Remove internal size limit on app to be installed.
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.
Renamed the RestoreSession performRestore() method to restoreAll(), and
added a new restorePackage() method that only restores the single
specified app. In order to restore an app other than itself, the
caller must hold the android.permission.BACKUP permission.
This change also introduces dataset tracking: the Backup Manager
persistently remembers both the current backup dataset's identity
and that of the "ancestral" dataset, i.e. the one most recently used
for a whole-device restore such as performed by SetupWizard. When a
single package is restored via restorePackage(), the selection of
most-recent dataset to use is this:
1. The data from the currently-active backup dataset, if such exists.
An app that has ever backed up data will therefore get its last-
known-good data.
2. The app's data from the ancestral dataset, if such exists. This
covers the case of a factory reset followed by reinstallation of
an app at a later time. The app had not yet backed anything up
post-wipe, but the old data is in the ancestral dataset and should
be brought forward when the app reappears.
3. If neither 1. nor 2. exist, there is no data to restore, so just
skip it and return failure.
Note that the infrastructure to automatically attempt a restore after
an application has been installed does not yet exist; that's coming.
Change-Id: I0ba170df9885128000c46ed28d3dddda3a63a143
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 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.
