872d3b6e19933af6fa9ae65214b9f6df04fc3222 |
|
12-Jan-2016 |
Sergey Poromov <poromov@google.com> |
Quota exceeded API in BackupAgent Should be also implemented in GMS BackupTransport. Bug: 25693504 Change-Id: I6e4b2edb6d62addca0aced3e801d7629fb9394ca
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
9448196076d5a5266b3ae7e4945216b30ee88aa7 |
|
07-Jan-2016 |
Sergey Poromov <poromov@google.com> |
Add BackupManager#isAppEligibleForBackup() method to Backup API. Check is done only in framework. Transport still can deny backup for the package. Bug: 26443192 Change-Id: Ifcde67a4d11725aa4b15ab4f57d740f55ab2b265
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
fe06bf64d204c459699b0bf6465f9fb69208345e |
|
15-Dec-2015 |
Sergey Poromov <poromov@google.com> |
Introduce BackupManager#requestBackup & BackupObserver API Introduces a way to request immediate backup for list of packages and receive callbacks on backup progress. Bug: 25688526 Change-Id: Ib826933d44f4ebf2b981f8be366215b2d37847e2
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
11ae768cf1b8348e761ad9c09e98788da1e591b1 |
|
25-Mar-2015 |
Christopher Tate <ctate@google.com> |
Add payload-size preflight stage to full transport backup We now peform a total-size preflight pass before committing data to the wire. This is to eliminate the large superfluous network traffic that would otherwise happen if the transport enforces internal quotas: we now instead ask the transport up front whether it's prepared to accept a given payload size for the package. From the app's perspective this preflight operation is indistinguishable from a full-data backup pass. If the app has provided its own full-data handling in a subclassed backup agent, their usual file-providing code path will be executed. However, the files named for backup during this pass are not opened and read; just measured for their total size. As far as component lifecycles, this measurement pass is simply another call to the agent, immediately after it is bound, with identical timeout semantics to the existing full-data backup invocation. Once the app's file set has been measured the preflight operation invokes a new method on BackupTransport, called checkFullBackupSize(). This method is called after performFullBackup() (which applies any overall whitelist/blacklist policy) but before any data is delivered to the transport via sendBackupData(). The return code from checkFullBackupSize() is similar to the other transport methods: TRANSPORT_OK to permit the full backup to proceed; or TRANSPORT_REJECT_PACKAGE to indicate that the requested payload is unacceptable; or TRANSPORT_ERROR to report a more serious overall transport-level problem that prevents a full-data backup operation from occurring right now. The estimated payload currently does not include the size of the source-package metadata (technically, the manifest entry in its archive payload) or the size of any widget metadata associated with the package's install. In practice this means the preflighted size underestimates by 3 to 5 KB. In addition, the preflight API currently cannot distinguish between payload sizes larger than 2 gigabytes; any payload estimate larger than that is passed as Integer.MAX_VALUE to the checkFullBackupSize() query. Bug 19846750 Change-Id: I44498201e2d4b07482dcb3ca8fa6935dddc467ca
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
bf1a4a81ebd340a18583f4ca9b5d562a01f55674 |
|
09-Aug-2014 |
Christopher Tate <ctate@google.com> |
Start using cancelFullBackup() when appropriate The API was in place but the framework wasn't yet calling it. Bug 16524520 Change-Id: Ie368758c830a7d0ad11e7dd3142a0ed896069944
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
9679410db578e179c7559e7a52bb21c8082e9631 |
|
28-Jul-2014 |
Christopher Tate <ctate@google.com> |
Add data-management intent + label to BackupTransport API Bug 16346320 Change-Id: Id9e855a1d3cebbf801c27a21e1edc3ffcccfd2e9
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
6a49dd087f29cfca82d55dfabeb97439ef84b508 |
|
17-Jun-2014 |
Christopher Tate <ctate@google.com> |
Tweak restore API We need the transport to tell the system not only what package it's going to deliver data for next, but also what format that data is in. Change-Id: I989cf78febf923a4208acb33ed80ccc7869356f5
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
9ff53a7100b1a40f5d2df3eb19a2f3f2fff39a46 |
|
04-Jun-2014 |
Christopher Tate <ctate@google.com> |
Implement full data backup through transport Currently no timed/scheduled full-data backup operations are performed by the OS, but the plumbing is now in place and can be tested using 'adb shell bmgr fullbackup pkg [pkg2 pkg3 ...]'. The LocalTransport test transport implementation has been augmented to support the new full-data backup API as well. In addition, 'adb backup' now takes the -compress/-nocompress command line options to control whether the resulting archive is compressed before leaving the device. Previously the archive was always compressed. (The default is still to compress, as it will usually reduce the archive size considerably.) Internally, the core implementation of gathering the full backup data stream from the target application has been refactored into an "engine" component that is shared by both 'adb backup' and the transport-oriented full backup task. The archive file header generation, encryption, and compression logic are now factored out of the engine itself instead of being hardwired into the data handling. Bug 15329632 Change-Id: I4a044faa4070d684ef457bd3e11771198cdf557c
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
74318c98a0f67e042815798f85c75eb7f14390e1 |
|
16-May-2014 |
Christopher Tate <ctate@google.com> |
Provide stable concrete wrapper for backup transport API This initial version is a simple pass-through of the existing IBackupTransport AIDL definition. Change-Id: I0f6c9ffc7101f82127ab61ba6cba9f5003af6a0c
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
cefba58d14f9669b57c16b4ea493779d882c43bd |
|
15-Nov-2013 |
Christopher Tate <ctate@google.com> |
Handle backup transport registration dynamically Bug 11369873 Change-Id: I9bbdcc21ce25159c6645690123b5d03c553b0ddc
/frameworks/base/core/java/com/android/internal/backup/IBackupTransport.aidl
|
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
|