240c7d2d1fb2944ee6a6f1dee41c7bbd766f8f0d |
|
04-Oct-2011 |
Christopher Tate <ctate@google.com> |
Add -nosystem flag to adb backup This makes it easy to back up everything that belongs to 3rd party apps, but nothing that comes with the system per se. If any system packages are explicitly named on the command line they will be included in the backup even if -nosystem was passed. So, for example, this will back up all 3rd party apps as well as system settings, but nothing else belonging to system-deployed apps: adb backup -all -nosystem com.android.provider.settings Bug 5361503 Change-Id: Iebe04b7d7027ca58b9f55e8eb7f219d6cca69269
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
728a1c4d5ed3b808172013a7f5bb5065d1e964f6 |
|
29-Jul-2011 |
Christopher Tate <ctate@google.com> |
Require the current backup pw in all backup/restore operations Specifically, we now also require the current password to confirm any restore operation. Bug 4901637 Change-Id: I39ecce7837f70cd05778cb7e0e6390ad8f6fe3f3
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
2efd2dbbac9eac89620683696c6076463c3a1cd6 |
|
20-Jul-2011 |
Christopher Tate <ctate@google.com> |
Support full-backup encryption and global backup password If the user has supplied a backup password in Settings, that password is validated during the full backup process and is used as an encryption key for encoding the backed-up data itself. This is the fundamental mechanism whereby users can secure their data even against malicious parties getting physical unlocked access to their device. Technically the user-supplied password is not used as the encryption key for the backed-up data itself. What is actually done is that a random key is generated to use as the raw encryption key. THAT key, in turn, is encrypted with the user-supplied password (after random salting and key expansion with PBKDF2). The encrypted master key and a checksum are stored in the backup header. At restore time, the user supplies their password, which allows the system to decrypt the master key, which in turn allows the decryption of the backup data itself. The checksum is part of the archive in order to permit validation of the user-supplied password. The checksum is the result of running the user-supplied password through PBKDF2 with a randomly selected salt. At restore time, the proposed password is run through PBKDF2 with the salt described by the archive header. If the result does not match the archive's stated checksum, then the user has supplied the wrong decryption password. Also, suppress backup consideration for a few packages whose data is either nonexistent or inapplicable across devices or factory reset operations. Bug 4901637 Change-Id: Id0cc9d0fdfc046602b129f273d48e23b7a14df36
/frameworks/base/core/java/android/app/backup/IBackupManager.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/backup/IBackupManager.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/backup/IBackupManager.aidl
|
f5e1c296370b45503a6c48bdb7da8b829bc0b906 |
|
09-Dec-2010 |
Christopher Tate <ctate@google.com> |
Add a couple of transport-descriptive methods to IBackupManager Privileged callers can now ask the transport for a string describing its current state, and for an Intent that can be passed to startActivity() in order to bring up its exported configuration UI. These will be used in Settings in order to e.g. show the user the currently active account being used for backup, and allow the user to choose an account. The data being funnelled through IBackupManager here are the ones already exposed by the transports in their implementation of the IBackupTransport interface. Bug: 2753632 Change-Id: I2227a2b111d8d0ddf221d63020e20c1316fff55b
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
44ab8453e1c4c46790f792a46d026fa1017d8cfe |
|
17-Nov-2010 |
Chris Tate <ctate@google.com> |
Permission fix: don't require BACKUP perm for self-restores The public API is not supposed to require the BACKUP permission in order for an application to restore its own last-known-good backup data. However, as currently implemented, BackupManager.requestRestore() [the public API in question] depends on private Backup Manager methods that *do* enforce that permission. The net result is that the method cannot be successfully used by third party applications: it will throw an exception if attempted. This CL restructures the permission checking involved. First, the underlying beginRestoreSession() operation can now be passed a 'null' transport name; if this is done, then the restore session is begun on whatever the currently-active transport is. Looking up the name of the active transport is one of the permission-guarded actions that was required with the initial implementation. Second, a package name can now be passed to beginRestoreSession(). If this is done, then the restore session can only be used to perform a single-package restore of that one application. The BACKUP permission is not required if the caller is tying the restore to its own package name. In combination, these changes permit BackupManager.requestRestore() to function without the calling app needing to hold any special permission. The no-permission case is intentionally quite narrow: the caller must hold the permission unless they both (a) pass 'null' for the transport name, thereby accepting whatever the currently active transport is, and (b) pass their own package name to restrict the restore session only to their own app. External bug http://code.google.com/p/android/issues/detail?id=10094 Internal bug 3197202 Change-Id: Ibc9d652323f2da03727d850f991b4096af6520d2
/frameworks/base/core/java/android/app/backup/IBackupManager.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/backup/IBackupManager.aidl
|