| 8031a3df2fd0c38d85eeae39c1ea2c83e813f4ff |
|
07-Jul-2009 |
Christopher Tate <ctate@google.com> |
Make enable/provisioning of the backup service a two-step process
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.
/frameworks/base/core/java/android/backup/IBackupManager.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/android/backup/IBackupManager.aidl
|
| 6ef58a1509b9d3348a33ca5686917796c2759aa5 |
|
29-Jun-2009 |
Christopher Tate <ctate@google.com> |
Implement persistent enable/disable of the backup manager
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.
/frameworks/base/core/java/android/backup/IBackupManager.aidl
|
| 9171749700853305f3e6abbcdbd9e02f3a71d459 |
|
27-Jun-2009 |
Christopher Tate <ctate@google.com> |
Use system properties to track the current transport
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.
/frameworks/base/core/java/android/backup/IBackupManager.aidl
|
| 5cbbf5652a78902ac3382dc4a3583bc5b0351027 |
|
23-Jun-2009 |
Christopher Tate <ctate@google.com> |
Pass the originating app's versionCode along with a restore set
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.
/frameworks/base/core/java/android/backup/IBackupManager.aidl
|
| ace7f094bf07bbd90cb998b9462e4f2d101a498c |
|
16-Jun-2009 |
Christopher Tate <ctate@google.com> |
Sketch out a 'bmgr' command line tool
Not finished, but eventually will allow adb shell access to the Backup Manager
for testing purposes etc.
/frameworks/base/core/java/android/backup/IBackupManager.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/android/backup/IBackupManager.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/android/backup/IBackupManager.aidl
|
| 181fafaf48208978b8ba2022683ffa78aaeddde1 |
|
14-May-2009 |
Christopher Tate <ctate@google.com> |
Retool the backup process to use a new 'BackupAgent' class
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.
/frameworks/base/core/java/android/backup/IBackupManager.aidl
|
| 46758123868d91e7b186aebb27c4c4988dede43e |
|
06-May-2009 |
Christopher Tate <ctate@google.com> |
Add a Backup Manager interface to request a full backup
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.
/frameworks/base/core/java/android/backup/IBackupManager.aidl
|
| a8bf815c6153290b173f34b071dddb0a0034a115 |
|
30-Apr-2009 |
Christopher Tate <ctate@google.com> |
Add android.backup.BackupManager
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.
/frameworks/base/core/java/android/backup/IBackupManager.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/android/backup/IBackupManager.aidl
|