History log of /frameworks/base/core/java/android/app/backup/FullBackupDataOutput.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
ee87b96ee572e7245cf7b791e30c51505a8ba2a2 27-Apr-2017 Christopher Tate <ctate@google.com> API: make "what's the quota?" an operation on the backup data sinks

...instead of a method of the BackupAgent lifecycle component, callable
only while a backup is underway.

Bug 37565111
Test: unit

Change-Id: I4a56f93ee164ec499d5621f1641d932f091adf57
/frameworks/base/core/java/android/app/backup/FullBackupDataOutput.java
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/backup/FullBackupDataOutput.java
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/backup/FullBackupDataOutput.java