When an application being installed defines a backupAgent in its manifest, we
now automatically perform a restore of the latest-known-good data for that app.
This is defined as "data backed up by this app from this handset, if available;
otherwise data for this app as it existed when the device was initially
provisioned." If neither option exists for the app, no restore action is
taken.
The CL involves major changes in the Backup and Package Managers...
* The Package Manager's act of installing an application has now been split
into two separate phases, with a data-restore phase optionally occurring
between these two PM actions. First, the details of the install are performed
as usual. Instead of immediately notifying install observers and issuing the
install-related broadcasts, the in-process install state is snapshotted and
the backup manager notified that a restore operation should be attempted. It
does this by calling a new API on IBackupManager, passing a token by which it
identifies its in-progress install state.
The backup manager then downloads [if possible] the data for the newly-installed
application and invokes the app's backupAgent to do the restore. After this
step, regardless of failure, it then calls back into the Package Manager to
indicate that the restore phase has been completed, supplying the token that
was passed in the original notification from the Package Manager.
The Package Manager then runs the final post-install actions: notifying install
observers and sending out all the appropriate broadcasts. It's only at this
point that the app becomes visible to the Launcher and the rest of the OS.
... and a few other bits and pieces...
* The ApplicationInfo.backupAgentName field has been exposed to the SDK. This
can be reverted if there's a reason to do so, but it wasn't clear that this
info needs to be hidden from 3rd party apps.
* Debug logging of restore set IDs and operation timeout tokens [used during
any asynchronous Backup Manager operation] are now consistently in hex for
readability.
* We now properly reset our binder identity before calling into the transport
during restore-set operations. This fixes a permissions failure when a
single-app restore was attempted.
* The 'BackupTest' test app is no longer lumped onto the system partition
by default.
Change-Id: If3addefb846791f327e2a221de97c8d5d20ee7b3
The core backup/restore classes [BackupManager, BackupAgent, RestoreSession, and
RestoreObserver] are now published for 3rd party developers, as well as the suite
of helper classes that exist so far to aid authorship of backup/restore agents.
In conjunction with the API change, the restore-time automatic data wipe has now
been removed: applications are responsible for managing the logic of wipe vs
merge themselves. If the app's agent onRestore() callback throws, the data
is presumed to be incoherent and a wipe is issued via the Activity Manager;
otherwise, no automatic action is ever taken.
Change-Id: I0b3418b829d4689b58b88be3d9c4ace37a8583a9
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
This setting, like BACKUP_ENABLE, should never be set directly in the secure
settings database. Instead, it should be manipulated through the new IBackupManager
method setAutoRestore(boolean).
Change-Id: I5c3226ca85b6148bb756d753d7f9e4ea76e878c4
Callouts to app backup agents are now asynchronous, and timeouts are applied if
they take too long, hang, etc. The initial timeouts are set to 15 seconds on
backup, 60 seconds on restore. These operations typically run at background
priority, so it's necessary to give them ample time to run.
As part of setting up this asynchronicity, the Backup Manager's internal thread
management has been overhauled. It now spins off a single HandlerThread at
startup, and runs backup/restore/etc operations *synchronously* in that thread,
applying timeouts as appropriate. This means we're no longer spinning up new
threads all the time, and furthermore it ensures that we can never have more
than one operation in flight at once. Later CLs will remove the now-redundant
logic that previously ensured that operations didn't stomp on each other.
Bug: 2053560
Change-Id: Ie4315c219c7ff6dd8f51f2ad6c0872595b18cff1
This commit makes a few changes towards establishing a formal application
interface for interacting with the backup/restore mechanism:
1. Introduce public wrapper classes around the various binder interfaces; 3rd
party code will never see the binders directly.
2. Progress update callbacks during a restore sequence now occur on the main
thread, not in a binder thread [and not with system-process permissions!].
3. Rename the BackupManagerService's inner "RestoreSession" class to avoid
ambiguity with the new public "RestoreSession" class.
The core logging in BackupManagerService and in the Google backup transport are
still enabled at this point.
Change-Id: I10abfa565bbd1097dd3631051b6aca163e4af33a
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.
+ Now rechecks the cached IBinder each time the wrapper is used, and if it's
still null (i.e. the BackupManager was constructed before the system service
came up) it's refetched. This lets even system code cache a single
BackupManager instance and just keep making calls through it without worrying
about interactions with the life cycle of the backup service.
+ Added a static dataChanged(packageName) method as a convenience for code that
needs to indicate that some other package needs a backup pass. This is useful
even for third party code in the case of multiple packages in a shared-uid
situation.
This CL adds the concept of 'provisioned' to the backup manager. No backups
will be scheduled until the user has indicated that backups are to be enabled
*and* has clicked all the way through the setup wizard.
When the user first turns on the backup system, the delay before the initial
backup pass is different from the periodic backup interval. Currently that
initial delay is 12 hours. The intent here is to guess at a less-active time
for performing that first backup pass.
NOTE: currently the backup service defaults to 'provisioned'. Once the real
code goes live in Setup Wizard, this will be changed to default to
not-provisioned until the user has confirmed all the relevant UI.
It's now possible to ask that the backup manager wipe the saved data for a given
application from the backing store. LocalTransport implements this now but the
Google backend does not yet. When the data is wiped, the on-device backup state
is also wiped to ensure that the next backup pushes all necessary data.
Bmgr has not yet been modified to actually call into this method, but it will
be soon.
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.
BackupManager now no longer tries to use a null service binder if it's used
early during the boot process. ActivityManagerService no longer tries to
dereference null pointers if bind/unbind semantics get out of step due to things
being run too early.
The observer is told when restore begins how many packages are being restored.
It then gets an onUpdate() call telling it that the Nth package is now
undergoing restore. Ultimately, its restoreFinished() callback is invoked,
passing a simple success/fail error code, to let it know that the restore
operation has concluded.
This CL does the following:
+ adds an AbsoluteFileBackupHelper class for managing backup of files
known by absolute path, not based off of the app's getFilesDir() root
+ bumps up the collection interval from its testing-only default of 1 second
to 3 minutes
+ adds a SystemBackupAgent class to the main system package and names it as
the android:backupAgent for the main OS package. Right now this agent
only backs up & restores the wallpaper file.
+ amend the Wallpaper Service to inform the Backup Manager when the wallpaper
changes.
On the subject of the 3-minute collection interval before the backup actually
occurs: this can be short-circuited from an adb shell. Running the command
'bmgr run' will cause the Backup Manager to kick off any pending backup
operations immediately.
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.
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.
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.
We now supply an array of RestoreSet objects instead of wacky Bundle
shenanigans. Also, pushed beginRestoreSession() out to the BackupManager
concrete interface class so that SetupWizard can use it.
(beginRestoreSession() is @hide, non-privileged apps cannot use it. It's
also guarded by android.permission.BACKUP enforcement.)
Restore is a fairly complicated, somewhat stateful process, so we introduce
a new interface to encapsulate the various bits and pieces into a nicely
separable component. In particular, this will make it much cleaner to
open and interrogate an expensive-to-construct transport and then reuse it
for the actual restore process itself.
* Put in some permission enforcement around agent connection notification
and full-backup scheduling.
* Full backup now applies to any package, not just backup participants who
have declared their own android:backupAgent
* The process of running the backup operation on the set of apps who have
been queued for it is now done in a separate thread, with a notification
mechanism from the main Backup Manager service to pass along new-agent
binding knowledge. There's no longer one do-backup message on the primary
Handler per target application.
* The new backup thread sets up the desired transport now and passes
along the newly backed-up data to it for each backup target. Two
transports have been defined so far, GoogleTransport and AdbTransport;
both are stubs at present.
Note that at present the backup data output file seems to be properly
created, but after doBackup() is called on the test app's agent it's
still zero size.
Backups will be handled by launching the application in a special
mode under which no activities or services will be started, only
the BackupAgent subclass named in the app's android:backupAgent
manifest property. This takes the place of the BackupService class
used earlier during development.
In the cases of *full* backup or restore, an application that does
not supply its own BackupAgent will be launched in a restricted
manner; in particular, it will be using the default Application
class rather than any manifest-declared one. This ensures that the
app is not running any code that may try to manipulate its data
while the backup system reads/writes its data set.
