summaryrefslogtreecommitdiff
path: root/cmds/bmgr/src
Commit message (Collapse)AuthorAgeFilesLines
* Get OperationType from transportRuslan Tkhakokhov2021-02-241-3/+2
| | | | | | | | | | | | | | | | | | This CL was merged earlier (ag/13484966) and then reverted due to the new behaviour breaking D2D transfers. Merge it again with all changes being controlled by a flag (default off), see UserBackupManagerService:getOperationTypeFromTransport in this CL. View the diff between patchsets 1 and 2 to only see what's changed between the earlier reverted code and the fixed version of it (i.e. with the flag). The flag can be changed via adb for now, we will set it to true by default once other components are ready. Bug: 174216309 Test: atest UserBackupManagerServiceTest Change-Id: I7473c9b4f8d0c4d20155be76930279184ffb17c4
* Revert "Get OperationType from transport"Kapish Goel2021-02-121-2/+3
| | | | | | | | This reverts commit f81af9df21be3f01d4364571085048e668510d9c. Reason for revert: DroidMonitor: Potential culprit for Bug 180089773 - verifying through Forrest before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted. Change-Id: I80d3f3233e40ade3bfa89b236ba114966a137c23
* Get OperationType from transportRuslan Tkhakokhov2021-02-111-3/+2
| | | | | | | | | | | | | | | Earlier we introduced versions of BackupManager#requestBackup() and BackupManager#beginRestoreSession() that take @OperationType as a parameter (i.e. backup or device-to-device migration). Change the logic to determine the operation type from the properties of the transport (BackupTransport#getTransportFlags()). This will help avoid introducing unnecessary APIs and save us from having to ensure consitency between @OperationType passed through to BackupManager and properties of the transport used for that operation. Bug: 174216309 Test: atest UserBackupManagerServiceTest Change-Id: I04a6014087c98efdeb8710fadc620b0856d7554b
* [FSD2D] Add BackupManager API to start restoreRuslan Tkhakokhov2020-08-061-2/+3
| | | | | | | | | Add an API to BackupManager to start restore in migration mode. Bug: 160407842 Test: atest PerformUnifiedRestoreTaskTest BackupManagerServiceTest UserBackupManagerServiceTest Change-Id: I75fdb1c99edc3d11d1264d69e1f20c682d588479
* Add bmgr command to enable/disable auto restoreRuslan Tkhakokhov2019-08-271-0/+29
| | | | | | | | | | | Bug: 139658304 Test: 1. atest AutoRestoreHostSideTest 2. "bmgr autorestore true", verify auto restore enabled via dumpsys "bmgr autorestore false", verify auto restore disabled via dumpsys Change-Id: I1174d2db172d06e90fd79385b9f0c64f4e8f4201
* Differentiate between various error conditions when calling Bmgr methodsnathch2019-07-171-42/+32
| | | | | | | | | | | | | | | Differentiate between 1. when the service is null 2. the service is not activated 3. there is a remote exception 4. we cant get a restore session from the service Bug: 137156961 Test: atest -v CtsBackupTestCases CtsBackupHostTestCases Test: atest -v BmgrTest Change-Id: I63f1005f43d8e3e23bbd629b183f128fa02bbac1
* [Multi-user] Clean up user state stored in the system user directoryChandan Nath2019-04-031-0/+24
| | | | | | | | | | | | | | when user is removed. For non system users, backup state is stored in both the user's own dir and the system dir. When the user is removed, the user's own dir gets removed by the OS. This code change ensures that the part of the user backup state which is in the system dir also gets removed. Bug: 127650374 Test: atest -v CtsBackupHostTestCases:android.cts.backup.MultiUserBackupStateTest Change-Id: I4ea252e8e6da608e36ec3ac335666923d88a8748
* API Review: Internal RestoreSession#restorePackagesRuslan Tkhakokhov2019-03-181-2/+2
| | | | | | | | | | | Bug: 120843781 Test: 1) atest RunBackupFrameworksServicesRoboTests 2) atest CtsBackupTestCases 3) atest CtsBackupHostTestCases 4) atest GtsBackupTestCases 5) atest GtsBackupHostTestCases Change-Id: Ice42aedd702e1c16b074d7a00d7b15d8f4aaf733
* [Multi-user] Disable backup by default in non-system usersAnnie Meng2019-01-241-7/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Key changes in this CL: - Backup is now disabled by default in non-system users unless DPM activates backup for this user AND the system user is activated. This provides gating for the multi-user B&R feature. - Activation is done via an 'activate' file that is per-user (but lives in the system user directory to account for locked users). - isBackupServiceActive() handles both locked and unlocked users. - Added a bmgr command to expose isBackupServiceActive() for testing purposes and enforce appropriate permissions. Future CLs: - Handle future migration to backup on by default for non-system users - Change CTS tests to use the new bmgr command Bug: 121306407 Test: 1) atest TrampolineTest 2) Start system user -> service started; run backup and restore successfully 3) Start non-system user -> ignored; 4) adb shell bmgr --user 0 activate true -> security exception; adb shell bmgr --user 10 activate true -> security exception (work profile); adb shell bmgr --user 11 activate true/false -> creates/deletes activate file and starts/stops the service Change-Id: Ic77db9b8b2e5170dcf89bef863dac4713730797a
* [Multi-user] Change more BackupManager AIDL methods to accept userId in methodsChandan Nath2018-12-181-18/+22
| | | | | | | | | | | | | | | | Bug: 120120742 Test: 1) atest RunFrameworksServicesRoboTests 2) atest $(find \ frameworks/base/services/tests/servicestests/src/com/android/server/backup \ -name '*Test.java') 3) atest CtsBackupTestCases 4) atest CtsBackupHostTestCases 5) atest GtsBackupTestCases 6) atest GtsBackupHostTestCases 7) 'adb shell bmgr' enabled/backupnow flow Change-Id: Ia0641f66dd0a935420f1aee332bb2e21ca03610e
* [Multi-user] Change BackupManager AIDL to accept userId in methodsChandan Nath2018-12-111-5/+6
| | | | | | | | | | | | | | | | | Bug: 120120742 Test: 1) atest RunFrameworksServicesRoboTests 2) atest $(find \ frameworks/base/services/tests/servicestests/src/com/android/server/backup \ -name '*Test.java') 3) atest CtsBackupTestCases 4) atest CtsBackupHostTestCases 5) atest GtsBackupTestCases 6) atest GtsBackupHostTestCases 7) Toggle Backup/'Backup Now' in Settings 8) 'adb shell bmgr' enabled/backupnow flow Change-Id: I5dba38f6a24e07947d1b0948f9caefeca011205d
* add option --user to Bmgr.javaChandan Nath2018-11-211-46/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | Bug: 118480337 Test: 1) atest RunFrameworksServicesRoboTests 2) atest BmgrTest 3) atest CtsBackupTestCases 4) atest CtsBackupHostTestCases 5) atest GtsBackupTestCases 6) atest GtsBackupHostTestCases UsageStatsRestoreHostSideTest fails. I verified locally that this test fails without this change too. 7) flashed device and ran:adb shell bmgr --user 10 backupnow --all Logs and output are as expected since backupservice isnt active for user 10 log: Bmgr : Running backupnow for user:10 output: Error: Could not access the Backup Manager. Is the system running 8) flashed device and ran:adb shell bmgr backupnow --all log: Bmgr : Running backupnow for user:0 output: Running incremental backup for all packages. Package @pm@ with result: Success .... Backup finished with result: Success Change-Id: Icfebe26f36276ea687d15c9f9c361c409313ae9d
* Add adb shell bmgr init TRANSPORT... to bmgr helpBernardo Rufino2018-08-221-0/+5
| | | | | | | | | | Wasn't there. Test: adb shell bmgr init android/com.android.internal.backup.LocalTransport, verify it works Test: adb shell bmgr, check help message Change-Id: Icceb78eac8c73128897f64a3d7c72fd27ff269dc
* Add --monitor to bmgr backupnowBernardo Rufino2018-08-091-11/+185
| | | | | | | | | | And --monitor-verbose. For debugging. Test: adb shell bmgr backupnow --monitor <packages> and verify output Test: adb shell bmgr backupnow --monitor-verbose <packages> and verify output Change-Id: I6c0a46a6b642063c37e548e181f4659dd46426a5
* Merge "Disable bmgr if BMS is not running"Annie Meng2018-06-061-3/+22
|\
| * Disable bmgr if BMS is not runningAnnie Meng2018-06-051-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If BMS is not running, we should not run any bmgr commands and print an error. This can occur after a device with a lockscreen reboots and has not unlocked yet, as the backup service is not active before unlocking. Bug: 80691476 Test: 1) Device with lock + adb reboot -> run any 'adb shell bmgr' command -> prints error 2) Device with no lock + adb reboot -> run any 'adb shell bmgr' command -> success Change-Id: I101b61d18a637cdb945ffc4a5e989a5dd270ee32
* | Remove adb shell bmgr restore <package>Bernardo Rufino2018-06-061-30/+4
|/ | | | | | | | | | | | Also put comment on RestoreSession saying that it doesn't kill the app in the end. Bug: 29255593 Test: Builds adb shell bmgr help, verify usage adb shell bmgr restore android, verify no-op Change-Id: I89304149ea6c03a80937e321cf3a46fd173308e2
* Bmgr about running backupsBernardo Rufino2018-02-281-1/+5
| | | | | | | | | Says that backups can be canceled if one already running. Put message for running backups in dumpsys for checking. Bug: 72484277 Test: Triggered backup, checked dumpsys and bmgr backupnow Change-Id: I028cf663858e374389f50175aaf5a3e8c9d45e42
* Binding on-demand #8: Miscellaneous usagesBernardo Rufino2018-01-051-12/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | Migrate usages of the transport binder to binding on-demand: * getDestinationString() * isAppEligibleForBackup() * dump() For getDestinationString() we'll be introducing an invisible bug for people that haven't updated GMSCore to include the usage of updateTransportAttributes() API introduced in earlier CL. The bug is that that text won't change, it'll remain constant. It's invisible because currently only place that uses that method is Settings in some circumstances that depend on the transport, and those circunstances don't happen with our transports. Check http://ag/1831025. For isAppEligibleForBackup(), a new filterAppsEligibleForBackup() is created and there we bind on-demand. Change-Id: Idc9e31f0e8eda8531e204c05a84fafdaf0247d08 Ref: http://go/br-binding-on-demand Bug: 17140907 Test: adb shell dumpsys backup, observe destination of transports Test: adb shell bmgr backupnow --all, observe only eligible apps got backed-up Test: Force-loaded settings screen and observed destination string Test: m -j RunFrameworksServicesRoboTests
* Add 'bmgr' command to synchronously init transportsChristopher Tate2017-06-201-18/+93
| | | | | | | | | | | | bmgr init TRANSPORT [...] will run an init operation on each named transport, blocking until the operations have all completed. Bug 62253989 Test: manual Change-Id: I7dbd94293738d5ecf195764f5b28905253819791
* Extend "Transport rejected package" message in BmgrMichal Karpinski2017-06-081-1/+2
| | | | | | Test: read it twice :) Bug: 36705040 Change-Id: I4eda5d2688b5f58f5a07131c5e6d6dafd6250570
* "bmgr restore" really should wait until operation finishes.Makoto Onuki2017-04-121-0/+6
| | | | | | | Test: manual test Bug 37246838 Change-Id: Ice381dc250e2d2a59cff48152dd3c8d6897d0804
* BackupManager#cancelBackups() APIShreyas Basarge2017-02-141-0/+24
| | | | | | | | | | | | | | | | Introduces a cancelBackups() API for BackupManager. When this function returns, it is guaranteed that currently running backup operations won't interact with the active transport. Bug: 34760860 Ref: https://docs.google.com/document/d/18MnfwkDfKNtXQBPRmL8vpVgfLgSWJsDja1Nm1QV5hOw/edit#heading=h.9p6yo0wx44k3 Test: GTS tests at ag/1893365 Change-Id: I67f78699bbe763ea71c85937fbc01a5b48694eed
* Add instrumentation for BackupManager during restore.Stefanot2017-02-101-5/+9
| | | | | | | | | | | | | | This CL adds more instumentation to backup/restore operation in the BackupManager. For more details please point to: https://docs.google.com/document/d/1sUboR28LjkT1wRXOwVOV3tLo0qisiCvzxIGmzCVEjbI/edit# This first Cl introduces 3 events that we sent to the monitor. The base cl is ag/1835775 Test: TODO BUG: 34873525 Change-Id: I127fe739a7522078eecce2ae689a4607203a98da
* Add monitoring to backup in BackupManager.Stefanot2017-02-101-1/+3
| | | | | | | | | | | | | | This is the first CL of many that will add instumentation to backup/restore operation in the BackupManager. For more details please point to: https://docs.google.com/document/d/1sUboR28LjkT1wRXOwVOV3tLo0qisiCvzxIGmzCVEjbI/edit# This first Cl introduces 3 events that we sent to the monitor. Test: ag/1858962 (same topic) BUG: 34873525 Change-Id: I6c338b6fd9f4d7c8670dac201897250b6b170677
* API to select backup transportShreyas Basarge2017-01-241-6/+65
| | | | | | | | | | | | | | | | | | | This cl adds an API to select a backup transport by its component name and receive a callback when BackupManager is bound to the transport. Calling this API will make BackupManager bind to the transport if it isn't already bound to it. Also fixes the issue where BackupManager would detect only one transport per package. Ref: go/backup-transport-switching Bug: 33616220 Test: Manually tested. GTS tests will be put up shortly. Change-Id: I8c23bdbb84ceb05eb1fad9b3a8b9c4441cb06c74
* Non incremental backup flag for requestBackupShreyas Basarge2017-01-191-8/+20
| | | | | | | | | | | | | | This cl adds a new requestBackup API to BackupManager that takes in an int flag to indicate whether the caller wants the entire key value set to be passed to the transport and not just a diff. Change-Id: Ia225797a58c4431fe742f2f116b257d006b30cd1 Bug: 33749084 Ref: go/request-backup-api-changes Test: GTS Test at ag/1774002
* Let bmgr inspect the set of whitelisted transportsChristopher Tate2016-06-151-0/+19
| | | | | | | | Needed for compliance testing. Bug 29072466 Change-Id: I025058ab9197f9e2db062bf0074e79f1cd04b443
* Update bmgr tool.Sergey Poromov2016-02-101-18/+79
| | | | | | | | Add support to QUOTA_EXCEEDED error output. Command "backupnow --all" without parameters now starts backup of all eligible packages. Change-Id: I563be35d575346d3dfb45a6dd254b387053c7ab7 (cherry picked from commit d5d68528bc7a7c1edb4691b5a40e37955128e73b)
* Update bmgr cmd line tool to use requestBackup() API in BackupManagerSergey Poromov2016-01-221-0/+95
| | | | | | | The new command works as "bmgr backupnow [list of packages]" This change should be submitted after ag/834173 Change-Id: Ie1cdd18a38653dd71a1d499620dd2afec3cbbb24
* Teach bmgr that "android" is a valid package nameChristopher Tate2014-11-131-1/+1
| | | | | | Bug 18379037 Change-Id: I4d6da2893f83e672920bbda9447aa4cbd1ecec7b
* Add 'fullbackup' to bmgr's usage statementChristopher Tate2014-06-241-4/+11
| | | | | | | | Also make it handle the list of packages to be backed up as a single multiple-app argument to fullTransportBackup() rather than N calls each backing up one app. Change-Id: I9fe4d5caca54fafef70ffe9af4c26e3941dc5d26
* Implement full data backup through transportChristopher Tate2014-06-151-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently no timed/scheduled full-data backup operations are performed by the OS, but the plumbing is now in place and can be tested using 'adb shell bmgr fullbackup pkg [pkg2 pkg3 ...]'. The LocalTransport test transport implementation has been augmented to support the new full-data backup API as well. In addition, 'adb backup' now takes the -compress/-nocompress command line options to control whether the resulting archive is compressed before leaving the device. Previously the archive was always compressed. (The default is still to compress, as it will usually reduce the archive size considerably.) Internally, the core implementation of gathering the full backup data stream from the target application has been refactored into an "engine" component that is shared by both 'adb backup' and the transport-oriented full backup task. The archive file header generation, encryption, and compression logic are now factored out of the engine itself instead of being hardwired into the data handling. Bug 15329632 Change-Id: I4a044faa4070d684ef457bd3e11771198cdf557c
* Harden against transiently unavailable backup transportsChristopher Tate2013-11-191-6/+13
| | | | | | | | | | | | The init & clear operations are particularly important to ensure delivery when at all possible, so we retry those periodically if the transport is unavailable when we first attempt them. Now with 100% less build break. Bug 11716868 Change-Id: I2af4e93788068cfac97c0a48d3568c561eefa23d
* Trying to unbreak build...Sascha Prueter2013-11-191-13/+6
| | | | | | | | Revert "Harden against transiently unavailable backup transports" This reverts commit 8f98252afea3fd0e68693635ec21b6004a52fa69. Change-Id: I3aabb80f1a5932d530bce6b82d4b30c6cd1cdd5a
* Harden against transiently unavailable backup transportsChristopher Tate2013-11-181-6/+13
| | | | | | | | | | The init & clear operations are particularly important to ensure delivery when at all possible, so we retry those periodically if the transport is unavailable when we first attempt them. Bug 11716868 Change-Id: I4860fe3d4e99618b2cd194c83162bd7cbd5a83a9
* Can now restore a subset of apps from historical datasetChristopher Tate2011-07-081-6/+26
| | | | | | | | | | | Adds the ability to filter a restore of an historical dataset so that it only restores certain apps' data regardless of what is actually present in the dataset. This is currently only used by the bmgr command-line tool, for debugging / developer support. Bug 2021590 Change-Id: I7685e5d609b0f5506f71d70c26410602bb387659
* Full local backup infrastructureChristopher Tate2011-05-101-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Permission fix: don't require BACKUP perm for self-restoresChris Tate2010-11-161-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Don't crash bmgr if there are no available restore setsChris Tate2010-11-011-5/+7
| | | | | | | | | | Properly guard against a null set of available restore sets when validating the token passed to 'bmgr restore TOKEN' against what's known to exist on the backend. Fixes bug 3153986 Change-Id: I74bdd4c6242f682833c1633baa4fefccb2b165a7
* Fix bug #3055578 ("adb shell bmgr list sets" generates NPE and cannot be run ↵Fabrice Di Meglio2010-10-011-1/+4
| | | | | | | | | again when device has no account setup) - fix NPE - code cleaning Change-Id: Ieb30b666d995de8cbd27ee6d17e2178e7ea670f6
* Fail gracefully if the user fails to supply necessary args to bmgrChristopher Tate2010-06-091-0/+10
| | | | | | Fixes bug #2755355 Change-Id: I4690756bb5077a6b4bbbfb232cd852cad43cef77
* Fix 'bmgr restore'Christopher Tate2010-04-061-1/+1
| | | | | | Zero means success. Fixes bug #2573785 Change-Id: I11bd4d85aa2b3a061aa37e085790ee8cd52d50a2
* Make RestoreSession.getAvailableRestoreSets() asynchronousChristopher Tate2010-03-301-6/+21
| | | | | | | | | | | | | This transaction can involve the transport having to query a remote backend over the wire, so it can take a Long Time(tm). Make it main-thread-safe by making it asynchronous, with the results passed as a callback to the invoker's RestoreObserver. We also make the IRestoreObserver callback interface properly oneway. Bug #2550665 Bug #2549422 Change-Id: If18a233a0a3d54c7b55101715c9e6195b762c5a0
* API CHANGE: Backup/restore API changes requested by the API CouncilChristopher Tate2010-03-261-2/+2
| | | | | | | | | | | | | | | * @hide the android.app.backup.RestoreSession class and functionality * Provide a public method on android.app.backup.BackupManager that apps can use to request a restore pass of their last-known-good dataset. The new method is called requestRestore(). * Provide the name of the package being restored, not just its ordinal, in the RestoreObserver's onUpdate() callback. Part of bug #2545514 Change-Id: I9689bf8d6e2b808b4ee412424a36a835be0a5ca8
* Refactor android.backup => android.app.backupChristopher Tate2010-03-051-4/+4
| | | | Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
* fix hex parsing of bmgrChristian Sonntag2010-03-041-1/+1
|
* Add single-package restore to Bmgr feature setChristopher Tate2010-02-261-17/+64
| | | | | | | | | Also sanity-check the package name on the Backup Manager side, failing gracefully if the given package is not a backup/restore participant. Bug: 2293977 Change-Id: I3575046ffcaa3cf45c1c602824baeadd64082f70
* Add single-package restore from an app's most-recent dataChristopher Tate2010-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Renamed the RestoreSession performRestore() method to restoreAll(), and added a new restorePackage() method that only restores the single specified app. In order to restore an app other than itself, the caller must hold the android.permission.BACKUP permission. This change also introduces dataset tracking: the Backup Manager persistently remembers both the current backup dataset's identity and that of the "ancestral" dataset, i.e. the one most recently used for a whole-device restore such as performed by SetupWizard. When a single package is restored via restorePackage(), the selection of most-recent dataset to use is this: 1. The data from the currently-active backup dataset, if such exists. An app that has ever backed up data will therefore get its last- known-good data. 2. The app's data from the ancestral dataset, if such exists. This covers the case of a factory reset followed by reinstallation of an app at a later time. The app had not yet backed anything up post-wipe, but the old data is in the ancestral dataset and should be brought forward when the app reappears. 3. If neither 1. nor 2. exist, there is no data to restore, so just skip it and return failure. Note that the infrastructure to automatically attempt a restore after an application has been installed does not yet exist; that's coming. Change-Id: I0ba170df9885128000c46ed28d3dddda3a63a143
* Don't let bmgr leave a restore session hanging on errorChristopher Tate2009-08-111-8/+10
| | | | | | | | | | | Specifically, don't wait for the RestoreObserver to be informed that the restore has completed unless performRestore() ran. We were winding up in a case where bmgr was hanging forever waiting on a nonexistent restore process instead of calling endRestoreSession(). Also improve the documentation, explicitly calling out the need to call endRestoreSession() even if previous operations on the session were unsuccessful.
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-14 23:37:08 +0000