History log of /frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
e684d9582cedf9bd5cc6c6fe47c600a79a13d816 06-Apr-2010 Jeff Brown <jeffbrown@google.com> Workaround NPE caused by packages missing signatures.

Bug: b/2547993
Change-Id: Idcd4fc3ee4c2560a00a952e1910a50b30b736114
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
4528186e0d65fc68ef0dd1941aa2ac8aefcd55a3 06-Mar-2010 Christopher Tate <ctate@google.com> Refactor android.backup => android.app.backup

Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
8a9b22056b13477f59df934928c00c58b5871c95 27-Feb-2010 Joe Onorato <joeo@android.com> Switch the services library to using the new Slog
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
b49ceb3b8b17656984fd969d548dc912e7d2c7c1 09-Feb-2010 Christopher Tate <ctate@google.com> Remember which apps have available restore info in the ancestral dataset

When we perform a full-system restore, remember the set of applications which
have data available in our ancestral dataset. This is a key filter for not
having to do a round trip to the [remote] storage backend at app-install time
unless it is likely to be fruitful.

Change-Id: I7c77b490c560c581888d84f02f258b2e2d73bc69
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
b808a939328b935592d9259e06c66b433a13c1a9 30-Sep-2009 Christopher Tate <ctate@android.com> Remove DEBUG-only logging in metadata backup agent

Change-Id: Ia75da053463249597b91ba629fd7a663cab1a07c
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
5a8a1151e267b29978f219f9569fdfc5e74cc210 11-Sep-2009 Christopher Tate <ctate@android.com> Try not to crash the system server because of corrupt restore data

When we're about to allocate an array based on the restore data for purposes of
unflattening a signature block, don't automatically assume that it's valid. If
it's corrupt [and we've seen this in practice] we can wind up trying to allocate
an array with 1.8 million objects, and throw an OutOfMemoryError, bringing down
the system.

This change arbitrarily decides that no package should have more than 20
signatures in its block, and aborts the restore if the metadata is thus revealed
to be corrupt.
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
3d7cd13e772bde1c4a72fa4e740baa03cb042e6c 07-Jul-2009 Christopher Tate <ctate@google.com> Fix the metadata-available test during restore
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
72d19aa51e90d45c7895629db78e548da2f6d469 30-Jun-2009 Christopher Tate <ctate@google.com> Tighten up the metadata backup logic

We now store the app version codes and and global OS incremental version name in
the PM backup state and the actual backup record. We then use that information
to trigger a re-backup of the metadata if the OS revision changes in any way, or
to back up single apps' metadata if we notice that they've been upgraded.
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
6f317426e49e73ef3e50d8839877504039cd2fca 30-Jun-2009 Christopher Tate <ctate@google.com> Don't issue a deletion for the global metadata backup

We were accidentally submitting a deletion for the global metadata key in the
PM backup handling (it was falling into the usual "here's a package that we said
we'd backed up last time, but now it's no longer on device" code). Don't do
that any more, i.e. actually keep the global metadata key in the backup set.
Oops.
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
efe52647f6b41993be43a5f47d1178bb0468cec8 24-Jun-2009 Dan Egnor <egnor@google.com> Modify the IBackupTransport API to support bulk restore operations.
Change the BackupManagerService and LocalTransport to support the new API.
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
5cbbf5652a78902ac3382dc4a3583bc5b0351027 23-Jun-2009 Christopher Tate <ctate@google.com> Pass the originating app's versionCode along with a restore set

This change amends the doRestore() / onRestore() interface to backup agents to
provide the integer android:versionCode of the app that stored the backup set.
This should help agents figure out how to handle whatever historical data set
they're handed at restore time.
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
3a31a93b8a195ae2d0180e6dfbf292da2e581f50 23-Jun-2009 Christopher Tate <ctate@google.com> Add some global metadata to the restore set

In addition to the signatures of each participating application, we now also
store the versionCode of each backed-up package, plus the OS version running on
the device that contributed the backup set. We also refuse to process a backup
from a later OS revision to an earlier one, or from a later app version to an
earlier.

LocalTransport has been modified as well to be more resilient to changes in the
system's use of metadata pseudopackages.
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
6aa41f4c575479672661f7eb4c704ef59d26a629 19-Jun-2009 Christopher Tate <ctate@google.com> Add app version to the backup metadata

We now record the version number of the app (drawn from its manifest versionCode
attribute) along with its signatures. At restore time, we compare the version
associated with the restore set with the version present on the device. If the
restore set is from a newer version of the app than is present on device, we do
not perform the restore operation.

Also fix the pending-backup iteration in 'dumpsys backup'.
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java
6785dd842075889e5230d93ed9c0ab9c204ab432 19-Jun-2009 Christopher Tate <ctate@google.com> Store the app signatures as part of the backup set

Under a pseudo-app for the Package Manager, we store the app signatures for all
participating applications installed on the device. At restore time we will
restore this first, then ensure that the current on-device signature chain is
compatible with the one in the backup set. If there's a mismatch, this may be a
spoof attempt and we will refuse to restore that app's data.

The restore side of this is not implemented, but the Package Manager agent is
here as well as the backup side theoretically pushing the data now.
/frameworks/base/services/java/com/android/server/PackageManagerBackupAgent.java