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
Any package can now participate in backup/restore, without requiring any
manifest-declared permission. *Control* of the backup manager is still
guarded by the BACKUP permission, which is signatureOrSystem.
Change-Id: I116fcfcd4cd255e3c976330da1c4dea7d4faae9d
Packages that do not use android.permission.BACKUP_DATA will neither be backed
up nor restored. That permission is currently signature-only. In the future if
access to the backup/restore infrastructure is made available to arbitrary 3rd
party applications, the permission checks (and indeed, the permission itself)
can simply be removed.
Append the date to 3.txt so that we can see if/when backup failures occurred
solely from the device/server state
Note that these files will probably be deleted from the tree immediately, to
be replaced by the ruby versions.
- Add copyright headers
- Allow the user to pass options (like '-s FOO') to adb
- Restart device adb as root if needed
- Make test_restore to infer a restore set
+ 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 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.
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.
