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/android/app/IBackupAgent.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/android/app/IBackupAgent.aidl
|
2e40d115ca4332d88424d1b591fdd8d5f78d1831 |
|
15-Jul-2014 |
Christopher Tate <ctate@google.com> |
Add BackupAgent.onRestoreFinished() callback The agent's onRestoreFinished() method is called after all available data has been delivered to the app, whether via the key/value restore API or the full-data file-at-a-time API. This gives the app a stable opportunity to do any postprocessing that might be appropriate. Also fixes a lingering bug in the framework's handling of backup agent lifetimes. In cases where an existing agent instances was being rebound, the framework was forgetting to notify the dependent that the agent was available. This was causing timeouts and restore failure. Bug 16241004 Change-Id: I3f52b299312d30d38b0cba63a2cfaeb934991ef2
/frameworks/base/core/java/android/app/IBackupAgent.aidl
|
cba5941c6085dab1566bc047c1ea31f58a2dd4cf |
|
01-Apr-2014 |
Christopher Tate <ctate@google.com> |
Rejigger the invalid-key checks at backup time Bug 13732002 Change-Id: Ic8f71234d1bbc7420eaa8e1762b999d09f308d46
/frameworks/base/core/java/android/app/IBackupAgent.aidl
|
adfe8b86e9178a553b6db9722340fa4ff5201cf1 |
|
05-Feb-2014 |
Christopher Tate <ctate@google.com> |
App widget backup/restore infrastructure Backup/restore now supports app widgets. An application involved with app widgets, either hosting or publishing, now has associated data in its backup dataset related to the state of widget instantiation on the ancestral device. That data is processed by the OS during restore so that the matching widget instances can be "automatically" regenerated. To take advantage of this facility, widget-using apps need to do two things: first, implement a backup agent and store whatever widget state they need to properly deal with them post-restore (e.g. the widget instance size & location, for a host); and second, implement handlers for new AppWidgetManager broadcasts that describe how to translate ancestral-dataset widget id numbers to the post-restore world. Note that a host or provider doesn't technically need to store *any* data on its own via its agent; it just needs to opt in to the backup/restore process by publishing an agent. The OS will then store a small amount of data on behalf of each widget-savvy app within the backup dataset, and act on that data at restore time. The broadcasts are AppWidgetManager.ACTION_APPWIDGET_RESTORED and ACTION_APPWIDGET_HOST_RESTORED, and have three associated extras: EXTRA_APPWIDGET_OLD_IDS EXTRA_APPWIDGET_IDS EXTRA_HOST_ID [for the host-side broadcast] The first two are same-sized arrays of integer widget IDs. The _OLD_IDS values are the widget IDs as known to the ancestral device. The _IDS array holds the corresponding widget IDs in the new post- restore environment. The app should simply update the stored widget IDs in its bookkeeping to the new values, and things are off and running. The HOST_ID extra, as one might expect, is the app-defined host ID value of the particular host instance which has just been restored. The broadcasts are sent following the conclusion of the overall restore pass. This is because the restore might have occurred in a tightly restricted lifecycle environment without content providers or the package's custom Application class. The _RESTORED broadcast, however, is always delivered into a normal application environment, so that the app can use its content provider etc as expected. *All* widget instances that were processed over the course of the system restore are indicated in the _RESTORED broadcast, even if the backing provider or host is not yet installed. The widget participant is responsible for understanding that these are promises that might be fulfilled later rather than necessarily reflecting the immediate presentable widget state. (Remember that following a cloud restore, apps may be installed piecemeal over a lengthy period of time.) Telling the hosts up front about all intended widget instances allows them to show placeholder UI or similarly useful information rather than surprising the user with piecemeal unexpected appearances. The AppWidgetProvider helper class has been updated to add a new callback, onRestored(...), invoked when the _RESTORED broadcast is received. The call to onRestored() is immediately followed by an invocation of onUpdate() for the affected widgets because they will need to have their RemoteViews regenerated under the new ID values. Bug 10622506 Bug 10707117 Change-Id: Ie0007cdf809600b880d91989c00c3c3b8a4f988b
/frameworks/base/core/java/android/app/IBackupAgent.aidl
|
79ec80db70d788f35aa13346e4684ecbd401bd84 |
|
24-Jun-2011 |
Christopher Tate <ctate@google.com> |
Make full backup API available to apps New methods for full backup/restore have been added to BackupAgent (still hidden): onFullBackup() and onRestoreFile(). The former is the entry point for a full app backup to adb/socket/etc: the app then writes all of its files, entire, to the output. During restore, the latter new callback is invoked, once for each file being restored. The full backup/restore interface does not use the previously-defined BackupDataInput / BackupDataOutput classes, because those classes provide an API designed for incremental key/value data structuring. Instead, a new FullBackupDataOutput class has been introduced, through which we restrict apps' abilities to write data during a full backup operation to *only* writing entire on-disk files via a new BackupAgent method called fullBackupFile(). "FullBackupAgent" exists now solely as a concrete shell class that can be instantiated in the case of apps that do not have their own BackupAgent implementations. Along with the API change, responsibility for backing up the .apk file and OBB container has been moved into the framework rather than have the application side of the transaction do it. Change-Id: I12849b06b1a6e4c44d080587c1e9828a52b70dae
/frameworks/base/core/java/android/app/IBackupAgent.aidl
|
75a99709accef8cf221fd436d646727e7c8dd1f1 |
|
19-May-2011 |
Christopher Tate <ctate@google.com> |
Restore from a previous full backup's tarfile Usage: adb restore [tarfilename] Restores app data [and installs the apps if necessary from the backup file] captured in a previous invocation of 'adb backup'. The user must explicitly acknowledge the action on-device before it is allowed to proceed; this prevents any "invisible" pushes of content from the host to the device. Known issues: * The settings databases and wallpaper are saved/restored, but lots of other system state is not yet captured in the full backup. This means that for practical purposes this is usable for 3rd party apps at present but not for full-system cloning/imaging. Change-Id: I0c748b645845e7c9178e30bf142857861a64efd3
/frameworks/base/core/java/android/app/IBackupAgent.aidl
|
4a627c71ff53a4fca1f961f4b1dcc0461df18a06 |
|
01-Apr-2011 |
Christopher Tate <ctate@google.com> |
Full local backup infrastructure This is the basic infrastructure for pulling a full(*) backup of the device's data over an adb(**) connection to the local device. The basic process consists of these interacting pieces: 1. The framework's BackupManagerService, which coordinates the collection of app data and routing to the destination. 2. A new framework-provided BackupAgent implementation called FullBackupAgent, which is instantiated in the target applications' processes in turn, and knows how to emit a datastream that contains all of the app's saved data files. 3. A new shell-level program called "bu" that is used to bridge from adb to the framework's Backup Manager. 4. adb itself, which now knows how to use 'bu' to kick off a backup operation and pull the resulting data stream to the desktop host. 5. A system-provided application that verifies with the user that an attempted backup/restore operation is in fact expected and to be allowed. The full agent implementation is not used during normal operation of the delta-based app-customized remote backup process. Instead it's used during user-confirmed *full* backup of applications and all their data to a local destination, e.g. via the adb connection. The output format is 'tar'. This makes it very easy for the end user to examine the resulting dataset, e.g. for purpose of extracting files for debug purposes; as well as making it easy to contemplate adding things like a direct gzip stage to the data pipeline during backup/restore. It also makes it convenient to construct and maintain synthetic backup datasets for testing purposes. Within the tar format, certain artificial conventions are used. All files are stored within top-level directories according to their semantic origin: apps/pkgname/a/ : Application .apk file itself apps/pkgname/obb/: The application's associated .obb containers apps/pkgname/f/ : The subtree rooted at the getFilesDir() location apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent apps/pkgname/r/ : Files stored relative to the root of the app's file tree apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored. For each package, the first entry in the tar stream is a file called "_manifest", nominally rooted at apps/pkgname. This file contains some metadata about the package whose data is stored in the archive. The contents of shared storage can optionally be included in the tar stream. It is placed in the synthetic location: shared/... uid/gid are ignored; app uids are assigned at install time, and the app's data is handled from within its own execution environment, so will automatically have the app's correct uid. Forward-locked .apk files are never backed up. System-partition .apk files are not backed up unless they have been overridden by a post-factory upgrade, in which case the current .apk *is* backed up -- i.e. the .apk that matches the on-disk data. The manifest preceding each application's portion of the tar stream provides version numbers and signature blocks for version checking, as well as an indication of whether the restore logic should expect to install the .apk before extracting the data. System packages can designate their own full backup agents. This is to manage things like the settings provider which (a) cannot be shut down on the fly in order to do a clean snapshot of their file trees, and (b) manage data that is not only irrelevant but actively hostile to non-identical devices -- CDMA telephony settings would seriously mess up a GSM device if emplaced there blind, for example. When a full backup or restore is initiated from adb, the system will present a confirmation UI that the user must explicitly respond to within a short [~ 30 seconds] timeout. This is to avoid the possibility of malicious desktop-side software secretly grabbing a copy of all the user's data for nefarious purposes. (*) The backup is not strictly a full mirror. In particular, the settings database is not cloned; it is handled the same way that it is in cloud backup/restore. This is because some settings are actively destructive if cloned onto a different (or especially a different-model) device: telephony settings and AndroidID are good examples of this. (**) On the framework side it doesn't care that it's adb; it just sends the tar stream to a file descriptor. This can easily be retargeted around whatever transport we might decide to use in the future. KNOWN ISSUES: * the security UI is desperately ugly; no proper designs have yet been done for it * restore is not yet implemented * shared storage backup is not yet implemented * symlinks aren't yet handled, though some infrastructure for dealing with them has been put in place. Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
/frameworks/base/core/java/android/app/IBackupAgent.aidl
|
4528186e0d65fc68ef0dd1941aa2ac8aefcd55a3 |
|
06-Mar-2010 |
Christopher Tate <ctate@google.com> |
Refactor android.backup => android.app.backup Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
/frameworks/base/core/java/android/app/IBackupAgent.aidl
|
44a2790374bf27116cbd91060d4f096ca5999709 |
|
28-Jan-2010 |
Christopher Tate <ctate@google.com> |
Make backup/restore asynchronous and enforce timeouts Callouts to app backup agents are now asynchronous, and timeouts are applied if they take too long, hang, etc. The initial timeouts are set to 15 seconds on backup, 60 seconds on restore. These operations typically run at background priority, so it's necessary to give them ample time to run. As part of setting up this asynchronicity, the Backup Manager's internal thread management has been overhauled. It now spins off a single HandlerThread at startup, and runs backup/restore/etc operations *synchronously* in that thread, applying timeouts as appropriate. This means we're no longer spinning up new threads all the time, and furthermore it ensures that we can never have more than one operation in flight at once. Later CLs will remove the now-redundant logic that previously ensured that operations didn't stomp on each other. Bug: 2053560 Change-Id: Ie4315c219c7ff6dd8f51f2ad6c0872595b18cff1
/frameworks/base/core/java/android/app/IBackupAgent.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/app/IBackupAgent.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/app/IBackupAgent.aidl
|