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.
Given a package name, the Backup Manager schedules a *full* (i.e. non-
incremental) backup pass for that package. Also added the state-file
handling for distinguishing to the target between the full and incremental
backup requests.
Author: Christopher Tate <ctate@google.com>
Date: Mon May 4 16:38:11 2009 -0700
IBackupService now passes ParcelFileDescriptors rather than int fds
The outlines of backup state file / data file handling are now in place as well
in the BackupManagerService.
Author: Christopher Tate <ctate@google.com>
Date: Thu Apr 30 12:40:19 2009 -0700
Hide the backup stuff for now
Also adjust based on comments:
+ changed service intent string to conform to usage guidelines
+ only publish the IBackupService binder when invoked with the right
intent action
+ docs tweaks
Also adjust based on comments:
+ changed service intent string to conform to usage guidelines
+ only publish the IBackupService binder when invoked with the right
intent action
+ docs tweaks
Also tweak the dataChanged() api to have the client supply a package name. We
don't necessarily TRUST this, but we use it to narrow the set of packages requesting
a backup pass, no longer blithely scheduling a pass for all packages associated
with the caller's uid.
This change adds a sketched outline of the backup system architecture, with
all of the major pieces represented other than client-side helpers for
specific types of data. IBackupManager and BackupService are public so that
we can write test apps against SDK-domain symbols from the outset.
What code exists in this change hasn't been tested and may crash. It's the
beginnings of the real implementation but of course is barely begun.
