303650c9cdb7cec88e7ec20747b161d9fff10719 |
18-Apr-2015 |
Matthew Williams <mjwilliams@google.com> |
Add full backup criteria to android manifest BUG: 20010079 Api change: ApplicationInfo now has a fullBackupContent int where -1 is (off) 0 is (on) and >0 indicates an xml resource that should be parsed in order for a developer to indicate exactly which files they want to include/exclude from the backup set. dd: https://docs.google.com/document/d/1dnNctwhWOI-_qtZ7I3iNRtrbShmERj2GFTzwV4xXtOk/edit#heading=h.wcfw1q2pbmae Change-Id: I90273dc0aef5e9a3230c6b074a45e8f5409ed5ce
rc/com/android/sharedstoragebackup/SharedStorageAgent.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
rc/com/android/sharedstoragebackup/ObbBackupService.java
|
7f392defccfae54dc8169e5ad82c2616e0713c8e |
12-Aug-2013 |
Jeff Sharkey <jsharkey@android.com> |
Catch a few extra users of UserEnvironment. Change-Id: I3112773b72c329893e4118ef1c4f4087d899139e
rc/com/android/sharedstoragebackup/ObbBackupService.java
|
ccbf84f44c9e6a5ed3c08673614826bb237afc54 |
09-May-2013 |
Christopher Tate <ctate@google.com> |
Some system apps are more system than others "signatureOrSystem" permissions are no longer available to all apps residing en the /system partition. Instead, there is a new /system/priv-app directory, and only apps whose APKs are in that directory are allowed to use signatureOrSystem permissions without sharing the platform cert. This will reduce the surface area for possible exploits of system- bundled applications to try to gain access to permission-guarded operations. The ApplicationInfo.FLAG_SYSTEM flag continues to mean what it is says in the documentation: it indicates that the application apk was bundled on the /system partition. A new hidden flag FLAG_PRIVILEGED has been introduced that reflects the actual right to access these permissions. At some point the "system" permission category will be renamed to "privileged". Bug 8765951 Change-Id: I6f0fd9cdb9170e076dfc66d83ecea76f8dd7335d
ndroid.mk
|
46cc43c6fa7623820d4ae9149496cf96bb15f8a3 |
19-Feb-2013 |
Christopher Tate <ctate@google.com> |
Full backup/restore now handles OBBs sensibly OBB backup/ restore is no longer handled within the target app process. This is done to avoid having to require that OBB-using apps have full read/write permission for external storage. The new OBB backup service is a new component running in the same app as the already-existing shared storage backup agent. The backup infrastructure delegates backup/restore of apps' OBB contents to this component (because the system process may not itself read/write external storage). From the command line, OBB backup is enabled by using new -obb / -noobb flags with adb backup. The default is noobb. Finally, a couple of nit fixes: - buffer-size mismatch between the writer and reader of chunked file data has been corrected; now the reading side won't be issuing an extra pipe read per chunk. - bu now explicitly closes the transport socket fd after adopting it. This was benign but triggered a logged warning about leaked fds. Bug: 6718844 Change-Id: Ie252494e2327e9ab97cf9ed87c298410a8618492
ndroidManifest.xml
roguard.flags
rc/com/android/sharedstoragebackup/ObbBackupService.java
|
416c39e8d48048fa4a997c09460c262cca871fc4 |
15-Feb-2013 |
Christopher Tate <ctate@google.com> |
Full backup now saves getExternalFilesDir() content with the app data ... instead of only saving it with the enormous "shared storage" generic data blob. In parallel, we no longer store managed app-specific files on external storage as part of the generic shared-storage blob. At restore time we just go ahead and apply such files, though, because they're a priori going to be part of an archive generated by an older version of the platform, so that's how the data is expected to be handled in those circumstances. Bug 6718844 Change-Id: I4410514d368b11d74b3afe6b92d363d4115a3415
rc/com/android/sharedstoragebackup/SharedStorageAgent.java
|
fb2ea43112bdf5a7dc121b59e2ef7e8b411bd019 |
18-Oct-2011 |
Christopher Tate <ctate@google.com> |
Fix full backup of shared storage The manifest said android:allowBackup="false" for vestigal reasons; originally, the incremental and full backup agents were separate, and it was not possible to opt out of full backup. When that got fixed, unfortunately this one manifest was not corrected to the new regime. Bug 5411789 Change-Id: Iafc8f1fdefc312dff59454485604b6c5c400f469
ndroidManifest.xml
rc/com/android/sharedstoragebackup/SharedStorageAgent.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
ndroidManifest.xml
rc/com/android/sharedstoragebackup/SharedStorageAgent.java
|
b0628bfd5aac480a0d412ac96b8af1d97ac01c30 |
03-Jun-2011 |
Christopher Tate <ctate@google.com> |
Implement shared-storage full backup/restore Every available shared-storage volume is backed up, tagged with its ordinal in the set of mounted shared volumes. This is an approximation of "internal + the external card". This lets us restore things to the same volume [or "equivalent" volume, in the case of a cross-model restore] as they originated on. Also fixed a bug in the handling of files/dirs with spaces in their names. Change-Id: I380019da8d0bb5b3699bd7c11eeff621a88e78c3
ndroid.mk
ndroidManifest.xml
roguard.flags
rc/com/android/sharedstoragebackup/SharedStorageAgent.java
|