| 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
|