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/BackupAgent.java
|
b6e73c96705c83db1f45686f2cd735d06ceb468e |
|
31-Jan-2017 |
Shreyas Basarge <snb@google.com> |
BackupAgent#getBackupQuota() API This cl adds a getBackupQuota() method to the BackupAgent abstract class. This can be used by the agent to determine how much data it can back up. Ref: https://docs.google.com/document/d/18MnfwkDfKNtXQBPRmL8vpVgfLgSWJsDja1Nm1QV5hOw/edit#heading=h.unncio2r7de2 Bug: 33750400 Test: GTS test at ag/1850525 Change-Id: I2eb5c0066c99732ec84cae9211f3a1edaad2baf1
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
54de77470de4f605eef7f4b4e01718b301fe275e |
|
12-Jan-2017 |
Elliot Waite <elliotwaite@google.com> |
Fix @links in reference docs. Change-Id: I40cea46efd80c448640ff69753698fe8404da40b
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
da2018efeb4388d43deb378e9b56029606cdd3bc |
|
13-Oct-2016 |
Christopher Tate <ctate@google.com> |
Only full-data back up regular files + directories Ignore every filesystem entity that is not a regular file or directory. In particular, we now ignore not only symlinks but also sockets, pipes, et cetera. Bug 32143362 Change-Id: If51b54df1f7a643af145eb15bf12d389d19f8780
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
91bb0e5cca2612545b3b046f5bb1b3bc747be8af |
|
01-Oct-2016 |
Christopher Tate <ctate@google.com> |
Explicitly close FD binder parameters in backup/restore API calls CloseGuard is grateful. Bug 30893100 Change-Id: Ia6bd4d88204839add59d9d245aad673d67b11bea
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
c5be8f8a4b9946f26f43201a06e7ec3f9b34857e |
|
25-Apr-2016 |
Christopher Tate <ctate@google.com> |
Correct docs about what is ignored in full-data backup You can't back up content in e.g. getNoBackupFilesDir() even if your app explicitly tries to. Bug 28321431 Change-Id: Ifa2a4bc518de03aba4c8809e60d8bb90fce767f8
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
d43879c5e42b715576761f48503bae9313e47ffc |
|
04-Apr-2016 |
Christopher Tate <ctate@google.com> |
API feedback: clarify onQuotaExceeded() documentation Bug 27530914 Change-Id: I5d185cfe9c7e0392a26d84e0e60d210ed6755016
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
8a372a0a280127743ce9a7ce4b6198c7a02d2a4f |
|
16-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
Refactoring FBE APIs based on council feedback. Mostly consists of removing the word "encryption" from most APIs, since we can't actually make promises about the data being encrypted. Bug: 27531029 Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
2c1ba9a961d4f96c26df260ee437655ad9e7c03e |
|
17-Feb-2016 |
Jeff Sharkey <jsharkey@android.com> |
Make BackupManager encryption aware. Backup requires both CE and DE storage to be available, so delay spinning up the backup system until the user is unlocked, since that's when CE storage becomes available. Note that devices without FBE immediately transition USER_SYSTEM into the unlocked state, since their CE is always available. Offer to backup and restore files under both CE and DE. Since DE is effectively the same as CE, most logic is simply duplicated for now, but it could be simplified in the future. Since system apps can force their default storage location to DE, we always build explicit CE and DE paths. Add getDataDir() to give clean access to the top-level private data directory, but disclaim that apps shouldn't create files there. Bug: 26279618 Change-Id: Ic34a4b330223725db93b1d0f5c9dffc88002c61f
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
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/backup/BackupAgent.java
|
85192a1b478b79905d16a285d559f8e3f05c6135 |
|
24-Sep-2015 |
Christopher Tate <ctate@google.com> |
Fix symlink handling during backup Don't canonicalize and *then* check for symlinks. It sort of misses the point.... Bug 22856947 Change-Id: I1c0ffa0dfeba13ca714f43eb7fd9963a0dfbcca3
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
b9ebed56e48e91876215a5c51f4562f1c7b0e49b |
|
06-Aug-2015 |
Matthew Williams <mjwilliams@google.com> |
Correctly skip files that are excluded from restore BUG: 22957980 If a file was present in the backup but excluded on restore, it can result in the restored data being corrupted. Ensure that FullBackup.restoreFile is called with a null destination, which will result in the file not being written to disk, but still properly pulled from the socket. Change-Id: Iac882a961b76e687654535aec352678486a08c39
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
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
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
e32da05d94adba9432610fbb7544e062743af303 |
|
15-Apr-2015 |
Christopher Tate <ctate@google.com> |
Remember to skip the no-backup dir during recursions Change-Id: I34c46f9b23cd0ddfa2392e953d8d8cc03bcea5a8
/frameworks/base/core/java/android/app/backup/BackupAgent.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/BackupAgent.java
|
a8a739f34c4d9c56b113810582801f36381cbc77 |
|
06-Mar-2015 |
Christopher Tate <ctate@google.com> |
Don't back up / restore the code_cache/ directory Bug 19628750 Change-Id: I1f2f5e8083675bf70d17c0c143dc813ca9e04610
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
f0e32ee572746fcd6ba83ad5476045ccfef9f349 |
|
13-Dec-2014 |
Alan Jeon <skyisle@gmail.com> |
Turn debug flag off Change-Id: Iced1a24ecfc182eccedd3a749fab9dd32dea41da Signed-off-by: Alan Jeon <skyisle@gmail.com>
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
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/backup/BackupAgent.java
|
a7835b6b6b00923b608a6bc3194e7840f67de7a8 |
|
12-Jul-2014 |
Christopher Tate <ctate@google.com> |
Add Context.getNoBackupFilesDir() This is an app-private filesystem space exactly like the one reported by Context.getFilesDir(), with one exception: files placed here are never backed up by the full-backup infrastructure. If an app attempts to back up any of its contents via the normal API it's immediately ignored with a logged warning. The restriction is also enforced on the restore side, because apps using support libraries might wind up creating full backup archives containing no_backup subdirs on pre-L devices (via adb backup, Helium, &c.). We check for this before passing the restore data to the app, and drop it if we detect the situation so that the app never sees the bits. Bug 16240573 Change-Id: I11216a391f1d32117ec7ce15aafc9cd93d0337de
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
10596fbcce710a76ffc7e917400df13af5c2ebcb |
|
28-Apr-2014 |
Elliott Hughes <enh@google.com> |
resolved conflicts for merge of 3ce4f3d0 to master Change-Id: Id5c5997ad8f801b32e1dbd97413ea42e38c27210
|
34385d352da19805ae948215e2edbeedd16b7941 |
|
28-Apr-2014 |
Elliott Hughes <enh@google.com> |
Track libcore.os' move to android.system. (This is partial, but should cover everything in AOSP master except for the zygote.) Change-Id: I1042c99245765746a744c44e714095cb2c6cb75d
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
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/backup/BackupAgent.java
|
f85f5b2125461ea664cf67a16d4608a5a9bf2f98 |
|
19-Apr-2013 |
Christopher Tate <ctate@google.com> |
Provide SharedPreferences coherence guarantees for BackupAgent SharedPreferences uses deferred writes internally, and the public API doesn't allow apps to explicitly synchronize with this, so the backup/restore implementation needs to take a little care to make sure that the app process isn't killed before the deferred writes land on disk. This parallels the coherence guarantees around SharedPreference that the Activity and Service lifecycles provide. Bug 8659368 Change-Id: I853e54f9fb0d2d260dbe6e40d640959f998092df
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
7323765bbf13d9638cf2cc1e06113bffcdac46c4 |
|
25-Mar-2013 |
Christopher Tate <ctate@google.com> |
Validate restored file paths against their nominal domain Bug 8460775 Change-Id: Ib16d740a001adf4f9cb9ccaa31066ac7cadfb430
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
294b512ecaa98a6a8ef12285ad14e7a4091b5d57 |
|
19-Feb-2013 |
Christopher Tate <ctate@google.com> |
DO NOT MERGE - 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. (Cherrypicked) Change-Id: I471f6348abcccb7bf1e1710b7beda9f23de53e14
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
5cb5c337d5fe523723b8e5ceb4bdf38dff0cec70 |
|
21-Feb-2013 |
Christopher Tate <ctate@google.com> |
Be cool in backup/restore of apps that can't touch external storage Bug: 8241337 Change-Id: I23f6eeba8448b234a7b18ce50d2ced2ba54b4ebd
/frameworks/base/core/java/android/app/backup/BackupAgent.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
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
61fd1e8d8c3ccf2d6b7d4af1c19e8f0988d5a1ec |
|
26-Oct-2011 |
Joe Fernandez <joefernandez@google.com> |
docs: add developer guide cross references, Project ACRE, round 3 Change-Id: I6125315ecdf0f78dd947c514a9944729d723e95d
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
78be158ce4b95fa537c6cb60a55dbc9161e53ef1 |
|
29-Aug-2011 |
Christopher Tate <ctate@google.com> |
Un-hide the new BackupAgent.onFullBackup() API This is intended to be new public API for ICS, and unbundled app development needs access to it. Change-Id: I091b31ae9ec319850a93efc3d5860b87b68d355e
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
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/BackupAgent.java
|
7926a693c4a4f4d2a2d352343bca23e189c7420d |
|
11-Jul-2011 |
Christopher Tate <ctate@google.com> |
Compress the backup output stream Zlib compression, with a full flush between each application's data. Encryption will be performed on the already-compressed data once that's implemented. On restore, the streamed data is similarly uncompressed on the fly. Change-Id: I19b65c88e759a66527d10913d18fffa9df0bc011
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
b848b7a99c81081723077d7fb2006b2a35760259 |
|
07-Jul-2011 |
Christopher Tate <ctate@google.com> |
Remove unused object Change-Id: I98c55432c26ccc4e8421db46c9f825cb42772508
/frameworks/base/core/java/android/app/backup/BackupAgent.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/BackupAgent.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
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
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/BackupAgent.java
|
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/BackupAgent.java
|
b83a283ac178ab0a72f1d811189d79b26097835e |
|
29-Apr-2010 |
Scott Main <smain@google.com> |
docs: add dev guide for backup Change-Id: I168f6b15d3441c9cbea2cd9699612476c7244530
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
d17da43c82c4edb97514d6138bc208eeba321636 |
|
30-Apr-2010 |
Scott Main <smain@google.com> |
docs: revise and add documentation for backup APIs Change-Id: I0b015a6de16da07ccd31756b8d2329dc2785c2f7
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
4e14a829129feee14ebe453f61a124784c870610 |
|
08-Apr-2010 |
Christopher Tate <ctate@google.com> |
SDK: more backup/restore documentation work Still not complete, but here's a lot more of the necessary documentation. Submitting a checkpoint seems prudent. Bug #2465360 Change-Id: Ifff60d57e4b24cee21f3a34f5f50e290d377c386
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
cc84c69726507a85116f5664e20e2ebfac76edbe |
|
29-Mar-2010 |
Christopher Tate <ctate@google.com> |
API CHANGE: rename BackupHelperAgent => BackupAgentHelper per API Council Part of bug #2545514 Change-Id: Ic775e3b942c485252149c1b6c15c88517fa4e3e5
/frameworks/base/core/java/android/app/backup/BackupAgent.java
|
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/BackupAgent.java
|