| a8ddef346cece1ad229e270ac4deebbd41ba6721 |
|
10-Nov-2010 |
Chris Tate <ctate@google.com> |
Add description and configuration methods to the transport interface
It's now possible for the transport to supply a descriptive string to inform
the user about the nature of the backup destination (e.g. telling the user
what account the data is being stored under), and to supply an Intent with
which the system can initiate a configuration Activity supplied by the
transport (e.g. allowing the user to select which account their data is
being stored under).
The transport interface is not public.
Part of bug 2753632 and bug 2987804
Change-Id: I911f70a3ea440daf2a7a04710e9d7e65b61a58db
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| 4528186e0d65fc68ef0dd1941aa2ac8aefcd55a3 |
|
06-Mar-2010 |
Christopher Tate <ctate@google.com> |
Refactor android.backup => android.app.backup
Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| 50c6df04cf17a99c3959c306a4e0e10da6d85c46 |
|
29-Jan-2010 |
Christopher Tate <ctate@google.com> |
Add a method to IBackupTransport to get the current backup set token
This will be used to specifically manage restores of last-known-good data
generated from the current device during its normal provisioned lifetime.
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| 0144516e19b9fd5415a56f8b41191187e2344bb0 |
|
22-Sep-2009 |
Dan Egnor <egnor@google.com> |
Make IBackupTransport.finishBackup() also return an int code, since it too can
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.)
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| d55e18acbe444b74dc9e71eff6ea2c3eaf25fbd0 |
|
21-Sep-2009 |
Christopher Tate <ctate@android.com> |
Reset backup tracking in response to transport data-wipe notification
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.
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| 25a747f5c47f25c1a18961b03507f309b84924fe |
|
20-Sep-2009 |
Christopher Tate <ctate@android.com> |
Add an 'init everything' operation to the first backup pass
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).
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| ee0e78af5af3bf23dd928fe5e0ebeb39157eaf66 |
|
02-Jul-2009 |
Christopher Tate <ctate@google.com> |
Add a "clear backed-up data" method to the backup mechanism
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.
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| 5cb400bd72726c22f641f334951b35ce2ddcfeef |
|
26-Jun-2009 |
Christopher Tate <ctate@google.com> |
Keep track of backup state independently for each transport
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.
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| efe52647f6b41993be43a5f47d1178bb0468cec8 |
|
24-Jun-2009 |
Dan Egnor <egnor@google.com> |
Modify the IBackupTransport API to support bulk restore operations.
Change the BackupManagerService and LocalTransport to support the new API.
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| aa088447baadd2e0bbcfd18cc529645610c13ddc |
|
17-Jun-2009 |
Christopher Tate <ctate@google.com> |
Hold the current transport instantiated all the time.
We no longer instantiate the transport just for the duration of handling a
backup or restore operation. Instead, we hold the object forever (replacing it
if instructed to do so). This makes it easier for transports to watch system
state and help set backup timing policy.
Also fixes up the IBackupTransport documentation a bit.
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| df01deaacff82b918b4f0ba774d5ad3087543629 |
|
10-Jun-2009 |
Christopher Tate <ctate@google.com> |
More restore plumbing, plus add suggested-backoff to transport API
Adds most of the code for a background-thread restore process, structured much
like the backup thread. Broke some common functionality out into a helper
function for doing a synchronous wait for a requested agent to attach.
Added a method to IBackupTransport whereby the transport will be asked for
an opinion on whether this is a good time for a backup to happen. It will
reply with the results of its policymaking around backoff intervals, time-of-day
selection, etc.
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| 9b3905c4a25f2d785ce7535d1f2e1540b46bb561 |
|
09-Jun-2009 |
Christopher Tate <ctate@google.com> |
Revamp IRestoreSession a bit
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.)
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| 8c850b792f2d371fd8a4aff146d9d757ee982539 |
|
08-Jun-2009 |
Christopher Tate <ctate@google.com> |
Add IRestoreSession interface for the restore flow
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.
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| b4a6188a74273611abcae05f3a3b1f0547548301 |
|
08-Jun-2009 |
Christopher Tate <ctate@google.com> |
Add rough-draft restore API set to IBackupTransport
* getAvailableBackups returns the list of backup sets available for restore
* getAppSet() returns the set of apps available from a given backup set
* getRestoreData() streams the full backup data for a given application
(within a given backup set) into a FD; that data will be handed to the
app's backup agent for processing.
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| 7b88128e08ba45b071cd714dad9681ce66920d32 |
|
07-Jun-2009 |
Christopher Tate <ctate@google.com> |
Adjust IBackupTransport interface
Instead of just passing a package name to performBackup, pass the whole
PackageInfo struct, explicitly including the list of signatures for the package.
No need to make each transport look this up individually when it's a necessary
part of the backup payload for each app.
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| 043dadc7516d20c3b3ccbcb20c53aaeef076a237 |
|
03-Jun-2009 |
Christopher Tate <ctate@google.com> |
More backup work
* 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.
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| e10be807872a88f872bef96d1fd5a1d9f78af282 |
|
08-May-2009 |
Christopher Tate <ctate@google.com> |
Sketch out the IBackupTransport api
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
| 487529a70cd1479ae8d6bbfb356be7e72542c185 |
|
29-Apr-2009 |
Christopher Tate <ctate@google.com> |
First baby steps towards settings backup
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.
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|