| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Bug 18379037
Change-Id: I4d6da2893f83e672920bbda9447aa4cbd1ecec7b
|
| |
|
|
|
|
|
|
| |
Also make it handle the list of packages to be backed up as a single
multiple-app argument to fullTransportBackup() rather than N calls
each backing up one app.
Change-Id: I9fe4d5caca54fafef70ffe9af4c26e3941dc5d26
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently no timed/scheduled full-data backup operations are
performed by the OS, but the plumbing is now in place and can
be tested using 'adb shell bmgr fullbackup pkg [pkg2 pkg3 ...]'.
The LocalTransport test transport implementation has been augmented
to support the new full-data backup API as well.
In addition, 'adb backup' now takes the -compress/-nocompress
command line options to control whether the resulting archive is
compressed before leaving the device. Previously the archive was
always compressed. (The default is still to compress, as it will
usually reduce the archive size considerably.)
Internally, the core implementation of gathering the full backup
data stream from the target application has been refactored into
an "engine" component that is shared by both 'adb backup' and the
transport-oriented full backup task. The archive file header
generation, encryption, and compression logic are now factored out
of the engine itself instead of being hardwired into the data
handling.
Bug 15329632
Change-Id: I4a044faa4070d684ef457bd3e11771198cdf557c
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The init & clear operations are particularly important to ensure
delivery when at all possible, so we retry those periodically
if the transport is unavailable when we first attempt them.
Now with 100% less build break.
Bug 11716868
Change-Id: I2af4e93788068cfac97c0a48d3568c561eefa23d
|
| |
|
|
|
|
|
|
| |
Revert "Harden against transiently unavailable backup transports"
This reverts commit 8f98252afea3fd0e68693635ec21b6004a52fa69.
Change-Id: I3aabb80f1a5932d530bce6b82d4b30c6cd1cdd5a
|
| |
|
|
|
|
|
|
|
|
| |
The init & clear operations are particularly important to ensure
delivery when at all possible, so we retry those periodically
if the transport is unavailable when we first attempt them.
Bug 11716868
Change-Id: I4860fe3d4e99618b2cd194c83162bd7cbd5a83a9
|
| |
|
|
|
|
|
|
|
|
|
| |
Adds the ability to filter a restore of an historical dataset so that it
only restores certain apps' data regardless of what is actually present
in the dataset. This is currently only used by the bmgr command-line tool,
for debugging / developer support.
Bug 2021590
Change-Id: I7685e5d609b0f5506f71d70c26410602bb387659
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The public API is not supposed to require the BACKUP permission in order
for an application to restore its own last-known-good backup data. However,
as currently implemented, BackupManager.requestRestore() [the public API
in question] depends on private Backup Manager methods that *do* enforce
that permission. The net result is that the method cannot be successfully
used by third party applications: it will throw an exception if attempted.
This CL restructures the permission checking involved.
First, the underlying beginRestoreSession() operation can now be passed a
'null' transport name; if this is done, then the restore session is begun
on whatever the currently-active transport is. Looking up the name of the
active transport is one of the permission-guarded actions that was required
with the initial implementation.
Second, a package name can now be passed to beginRestoreSession(). If
this is done, then the restore session can only be used to perform a
single-package restore of that one application. The BACKUP permission is
not required if the caller is tying the restore to its own package name.
In combination, these changes permit BackupManager.requestRestore() to
function without the calling app needing to hold any special permission.
The no-permission case is intentionally quite narrow: the caller must
hold the permission unless they both (a) pass 'null' for the transport
name, thereby accepting whatever the currently active transport is, and
(b) pass their own package name to restrict the restore session only
to their own app.
External bug http://code.google.com/p/android/issues/detail?id=10094
Internal bug 3197202
Change-Id: Ibc9d652323f2da03727d850f991b4096af6520d2
|
| |
|
|
|
|
|
|
|
|
| |
Properly guard against a null set of available restore sets when
validating the token passed to 'bmgr restore TOKEN' against what's
known to exist on the backend.
Fixes bug 3153986
Change-Id: I74bdd4c6242f682833c1633baa4fefccb2b165a7
|
| |
|
|
|
|
|
|
|
| |
again when device has no account setup)
- fix NPE
- code cleaning
Change-Id: Ieb30b666d995de8cbd27ee6d17e2178e7ea670f6
|
| |
|
|
|
|
| |
Fixes bug #2755355
Change-Id: I4690756bb5077a6b4bbbfb232cd852cad43cef77
|
| |
|
|
|
|
| |
Zero means success. Fixes bug #2573785
Change-Id: I11bd4d85aa2b3a061aa37e085790ee8cd52d50a2
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This transaction can involve the transport having to query a remote backend
over the wire, so it can take a Long Time(tm). Make it main-thread-safe by
making it asynchronous, with the results passed as a callback to the invoker's
RestoreObserver. We also make the IRestoreObserver callback interface
properly oneway.
Bug #2550665
Bug #2549422
Change-Id: If18a233a0a3d54c7b55101715c9e6195b762c5a0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* @hide the android.app.backup.RestoreSession class and functionality
* Provide a public method on android.app.backup.BackupManager that apps
can use to request a restore pass of their last-known-good dataset.
The new method is called requestRestore().
* Provide the name of the package being restored, not just its ordinal,
in the RestoreObserver's onUpdate() callback.
Part of bug #2545514
Change-Id: I9689bf8d6e2b808b4ee412424a36a835be0a5ca8
|
| |
|
|
| |
Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
Specifically, don't wait for the RestoreObserver to be informed that the restore
has completed unless performRestore() ran. We were winding up in a case where
bmgr was hanging forever waiting on a nonexistent restore process instead of
calling endRestoreSession().
Also improve the documentation, explicitly calling out the need to call
endRestoreSession() even if previous operations on the session were
unsuccessful.
|
| | |
|
| |
|
|
| |
Since they are android ids, it is much easier to use them as hex, since we can just copy then into android inspector and learn more about the restore set.
|
| |
|
|
|
|
| |
The caller needs to wait for the restore observer to be informed that the
restore has finished processing before it can safely shut down the restore
session.
|
| |
|
|
|
| |
"bmgr wipe PACKAGE" now issues the backup transport clearBackupData() operation
for the given package.
|
| |
|
|
|
|
|
|
|
| |
Backup & restore is still enabled by default, but with the expectation that it
will be enabled during the course of the Setup Wizard or some other privileged
entity that has notified the user about the ramifications. While disabled,
data-changed notices will still be collected, but no backup pass will be
scheduled. When the backup manager is later enabled, any pending data-changed
notices will then be processed and the apps invoked for backup.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change retools the transport selection mechanism a fair bit. Transports
are now specified by name rather than by numeric ID, and the name of the
currently selected transport is stored in a persistent system property under the
name "persist.service.bkup.trans".
The name -> IBackupTransport translation is now handled by maintaining a map
from the names to the live IBackupTransport objects that correspond. The Google
transport service observer now registers and unregisters the transport as the
service goes up and down.
The bmgr command has been expanded to include real transport interrogation and
selection by name, and some documentation has been written for it.
|
| | |
|
| | |
|
| |
|
|
| |
the backup is done.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
On restore now, the backup manager gets the signature blocks corresponding to
the restore set from the transport. It then validates those signatures against
the on-device app signatures, and refuses to restore data to an app whose
on-device sig block does not match the backup image's.
Also actually implement 'bmgr transport N' so that we can select the local
transport easily during runtime.
|
| |
|
|
|
|
| |
The 'list sets' and 'restore token#' commands from bmgr now do what they are
supposed to. At this point we see the restore target's data being cleared
properly and its agent being launched and invoked for restore.
|
|
|
Not finished, but eventually will allow adb shell access to the Backup Manager
for testing purposes etc.
|
