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