* We now check for in-progress backups when asked to perform one, and don't
bother firing off another one concurrently (nor do we adjust the scheduling;
after all, someone asked to do a backup "now" and we're doing one, so we are
in line with expectations). We also defer backup passes while a restore is
in flight, and abort attempts to perform a restore during a backup pass.
* When a backup attempt fails, we now ask the transport how far in the future we
should put our retry. Previously we were simply not bothering to consult with
the transport, so we would wind up retrying backup while network connectivity
was known to be down, etc.
Change-Id: Ic7758010b74e06e90c50d46b7b0dd01b17af7c90
Turning off backup in the Settings UI constitutes an opt-out of the whole
mechanism. For privacy reasons we instruct the backend to wipe all of the data
belonging to this device when the user does this. If the attempt fails it is
rescheduled in the future based on the transport's requestBackupTime()
suggestion. If network connectivity changes prompt the transport to indicate a
backup pass is appropriate "now," any pending init operation is processed before
the backup schedule is resumed.
The broadcasts used internally to the backup manager are now fully protected;
third party apps can neither send nor receive them.
(Also a minor logging change; don't log 'appropriate' EOF encountered during
parsing of a backup data stream.)
return TRANSPORT_NOT_INITIALIZED (in fact that's typically how it comes).
For consistency, make other IBackupTransport methods return int instead of
boolean, and handle accordingly.
Make initializeDevice() its own method instead of a flag on performBackup().
This will be needed when un-checking the settings box anyway, and is
conceptually unrelated to whatever happens to be the first post-initialization
backup we perform. (Note that even if the init is sent separately from the
backup operation, the server will remember that an init has been done and
will *not* return NOT_INITIALIZED for the subsequent backup.)
Fix LocalTransport accordingly (trivial changes).
Handle failures more robustly in BackupManagerService -- most notably,
doQueuedBackups() was ignoring the result code of processOneBackup(), so
a NOT_INITIALIZED error would go past unseen (at least until the next
backup pass). Keep track of error code returns more universally now.
(This includes finishBackup(), of course.)
When attempting a backup, the transport may inform us that the backend is in an
uninitialized state. This typically means that the device's data has been wiped
after a period [e.g. 90 days] of inactivity. This means that we need to
re-store all data subject to backup, and all of our incremental state tracking
on the device is now stale.
In response, we wipe all of our recorded backup state and restart the backup
pass on all participants.
This changes a couple of bits of the Backup Manager's logic around
first-backup-ever handling. First, it uses the same "what we've ever backed up"
handling as the rest of the system for purposes of instructing the backend to do
a wipe when the metadata is initialized for the device, instead of looking at
the presence of the @pm@ file. Secondly, for the time being we won't be using
the saved state produced by agents' doRestore() logic. Until the server is
migrating each restored package's data over to the new dataset, this was
resulting in the client holding an agent state blob for which no data existed on
the server under this device's identity but which the device thought was fully
up to date.
IBackupTransport.performBackup() now takes a flag "wipeAllFirst", which if set
will result in the entire restore set for the current device/account being wiped
clean prior to the storage of the provided package. This ensures that a device
on which backup has just been enabled will not confront potentially-stale
information, nor will the restore set potentially contain mismatched data from
orphaned packages.
The Backup Manager has also been revised to pass this flag when first backing up
its master metadata block (and never pass it thereafter unless something has
caused the backup state tracking to be erased, e.g. the user has opted out of
backup and then later re-enabled it).
Applications can now specify two more aspects of the restore process: whether
they need to run with their own custom Application subclass rather than being
launched in the usual restricted mode during restore, and whether it's okay for
the backup manager to kill the app process once restore has completed. The new
manifest attributes for these are, respectively, android:restoreNeedsApplication
and android:killAfterRestore.
If unspecified in the manifest, restoreNeedsApplication is false, and
killAfterRestore is true.
In order to support kill-after-restore cleanly, this change also adds a new
system-process-only interface to the Activity Manager, which will schedule a
"commit suicide" event on the target app's main thread looper.
The framework backup agents have been given the appropriate new backup
attributes as well.
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.
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.
This is because doing it through the Activity Manager also makes sure that the
app has been shut down first, which is quite a desirable invariant for restore
handling.
When a restore agent throws an exception back into the framework, assume that it
may have left the app's data in an inconsistent state and clear the data for
that app (again -- it was cleared just prior to the attempted restore, too).
When a package is uninstalled we now remove our notion of its having been backed
up, thereby forcing a backup pass if it is reinstalled at some point in the
future. Removal from the log means rewriting it and doing an atomic rename to
the canonical version. The temporary existence used during the rewrite is *not*
written synchronously; there's no need and it keeps the load on the flash part
much lower.
Because we might crash & reboot in the middle of the rewrite operation, there's
now code during init that sanity-checks the contents of the ever-backed-up log
and ensures that it's in a coherent state.
We now schedule a backup pass for any new application we see (at boot or
package-install time) for which we have never performed a backup. The
bookkeeping is a log file with the names of all the packages we've successfully
completed a backup pass on, maintained with synchronous journal-type behavior.
Also, make a bunch of private fields package-scoped to permit cheaper access
from the various worker / binder threads that run under the Backup Manager's
aegis.
This also means we should no longer do explicit calling-identity fiddling in
dump(), relying instead on the usual permission enforcement mechanism to handle
things.
If there's no data to be backed up, we no longer invoke the transport. We *DO*
still require that the agent have emitted a valid new state file, however.
This change also finally uncomments the code that removes the backup data file
after it has been sent to the transport, so there will be no more
packagename.data files lying around in the staging area.
We now log in dataChanged() only when an app is added to the backup set (and
*not* if it redundantly asks to be added after it's already there) and on error.
We now only commit to the pending-backup journal on disk the first time that a
given package is added to the backup set. This avoids a lot of write thrashing
of the disk, particularly since Settings tends to call dataChanged() a great
many times during boot, while the Settings UI is in use, etc.
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.
We need to make sure we stay alive for the duration of a backup or (especially)
restore operation. The existing Handler-based timing system was simply not
properly functional, so it's been retooled to use a repeating alarm delivering a
broastcast PendingIntent to our registered receiver.
We acquire a partial wake lock in the broadcast receiver [i.e. while the Alarm
Manager is holding one for the duration of broadcast delivery] and pass the
wakelock object to the backup thread, which eventually releases it when it's
finsihed operations. A similar pattern is used for the threads handling restore
and clear.
Without the metadata we can't verify the version number or the signatures of the
apps whose data we'd be trying to restore against the apps present on device.
This is not acceptable; we need to refuse to give data to an unauthenticated
app.
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.
This changes the backup service to use the settings provider instead
of system properties, correspondingly making it off by default and
allowing specific devices to define the transport. Also tweaks
the permission checks to use the permission symbol instead of raw
strings.
This requires some corresponding changes in the vendor projects.
We now schedule a periodic check of pending backups; if any apps have requested
a backup since the last check, we perform all of the pending backups. The
periodic backup scheduling matches the enable/disable state of the backup
manager; while backups are disabled entirely there are no periodic wakeups.
The period is set here to one hour. If an external caller (transport, the
'bmgr' command line tool, etc) requests an immediate backup pass, that is
performed and then the periodic backup check is rescheduled using that pass as
the starting point of a new interval.
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.
Ordinarily we wipe the data of apps we are restoring. This is problematic for
packages that expect that their data can never be wiped back to nothing,
especially system packages, so we now respect the android:allowClearUserData
manifest attribute.
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.
Backup transports now provide the Backup Manager with a suggested name with
which it can disambiguate any transport-specific bookkeeping that it needs to
maintain. The Manager keeps separate application backup 'state blobs' for each
transport now, preventing things from getting out of step if the device is
switched among multiple transports.
Also, the metadata backup agent is always invoked now on each backup pass. This
is cheap when there is nothing to do, but also strongly ensures that we never
wind up in a situation where a given transport destination has not been given
all of the metadata necessary for the backup set.
