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/include/androidfw/BackupHelpers.h
|
43a4a8c777fbb8f71540ac7fbe82674489ef557b |
|
09-Jan-2015 |
Christopher Tate <ctate@google.com> |
Fix redundant file backups We'd observed a bug in which an unchanged file was nevertheless being redundantly transmitted for backup on every backup pass. The underlying issue turns out to have been the FileBackupHelper base implementation's logic for diffing the prior-state file set against the current state, in the case when there had been deletions of prior files. In addition, there was also a parallel bug in which file checksums were not calculated properly in some cases, leading to at least one additional redundant backup of the file in question. Bug 18694053 Change-Id: Ie0dec06486b5fef4624561737019569c85d6b2a0
/frameworks/base/include/androidfw/BackupHelpers.h
|
16c4d154dca43c662571129af31b27433b919a32 |
|
24-Jan-2014 |
Adam Lesinski <adamlesinski@google.com> |
Revert "move libandroidfw to frameworks/native" This reverts commit 84b6292c33d71b5739828d08aa8101d1954577f2.
/frameworks/base/include/androidfw/BackupHelpers.h
|
84b6292c33d71b5739828d08aa8101d1954577f2 |
|
03-Oct-2013 |
Mike Lockwood <lockwood@google.com> |
move libandroidfw to frameworks/native Change-Id: Ic5b8a2742c7141156ab0f00ca29097bfe92bce60
/frameworks/base/include/androidfw/BackupHelpers.h
|
b13b9bdad2baf6ad1ec2e56b6b7598fa20f55fc4 |
|
18-Feb-2012 |
Mathias Agopian <mathias@google.com> |
frameworks/base refactoring. step 2: move libutils headers to their new home: androidfw Change-Id: I14624ba23db92a81f2cb929f104386e1fab293ef
/frameworks/base/include/androidfw/BackupHelpers.h
|