| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
As a next step they can be moved into separate directories to be
built as separate modules that may or may not be included in a
particular configuration.
Moves AppWidgetService, BackupManagerService, ClipboardService, DevicePolicyMS,
and WallpaperMS.
Change-Id: I33e48d070f38186819d3a1d7a4dc3984b75a9eda
|
| |
|
|
|
| |
Bug: b/2547993
Change-Id: Idcd4fc3ee4c2560a00a952e1910a50b30b736114
|
| |
|
|
| |
Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Change-Id: Ia75da053463249597b91ba629fd7a663cab1a07c
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Change the BackupManagerService and LocalTransport to support the new API.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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'.
|
|
|
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.
|
