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