summaryrefslogtreecommitdiffstats
path: root/core/java/android/app/backup
Commit message (Collapse)AuthorAgeFilesLines
* FullBackup: Add handling for shared storagePat Erley2016-02-251-0/+15
| | | | | | | | | | This fixes adb backup's '-shared' option by extending tokenToDirectoryPath to find the volume path associated with a volume id. CYNGNOS-2045 Change-Id: If648beb1a73dbd99e508d9d01a5e4460b00e5d3f
* Correctly skip files that are excluded from restoreMatthew Williams2015-08-061-5/+13
| | | | | | | | | | | | 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
* Change MNC codename to just M.Dianne Hackborn2015-07-291-1/+1
| | | | Change-Id: I4281d200ff6560791c47cf9073ceea1cb509361e
* Revert "Backup/restore recents task list"Stefan Kuhne2015-05-181-130/+0
| | | | | | | | | | | | | | | | | | | | Reverts commits 92dd1abef4c0a22db40c5f7bbd100e6b471a1ad3, 18795a2299fefd88ee16393f22324b999ace6ce4, and ac6a3a5e9d90edb533e5b377a4a14ef514be955a which make-up changes required for backing-up and restoring recent tasks from one device to another. The implementation had too many unresolved issues including the ordering of the restored recent tasks which was depending on when the task package is installed on the new device that puts the restored recents list out of order compared to the old device. Bug: 15986349 Bug: 19014377 Bug: 20763296 Change-Id: I06fd35a43036ef0b7260cf4db9c42890df63b95d
* Clarify docs for BackupTransport.initializeDevice()Christopher Tate2015-05-141-1/+10
| | | | | | | | | | | | Explicitly call out that even if the backend is in an undefined state (such as no authenticated account, so there is by definition no work that can be done here), the transport should return TRANSPORT_OK in response to initializeDevice(). Error returns from that method must only be used to indicate that the initialize should be *retried*. Bug 21136957 Change-Id: I41ad115b92c16092b4d931d9c554a44b77945359
* Add full backup criteria to android manifestMatthew Williams2015-05-032-65/+612
| | | | | | | | | | | | 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
* Compress the preferred-app backup payloadsChristopher Tate2015-04-211-1/+1
| | | | | | | | | | | They can be Very Very Large, so take advantage of the new BlobBackupHelper infrastructure to keep them tiny! Also fix an issue in which the restore path wasn't properly passing notification payloads along for processing, and an issue in which the blob helper wasn't handling empty states properly. Change-Id: I11a7ca3cd2e26f634a8971e874ac97385b0b500c
* Infrastructure for notification backup/restoreChristopher Tate2015-04-201-0/+296
| | | | | | | | | | | | Introduce a fairly general "store byte[] blobs as backup keys" helper, and use that to integrate with the Notification Manager. The helper provides all the machinery of managing prior state, compressing the blob on the wire, etc. Bug 19848954 Bug 20105530 Bug 17755700 Change-Id: I4aa808172244af6db0ab2f4440cc266a797655d7
* Remember to skip the no-backup dir during recursionsChristopher Tate2015-04-151-0/+2
| | | | Change-Id: I34c46f9b23cd0ddfa2392e953d8d8cc03bcea5a8
* Avoid zero-payload backups in local transportChristopher Tate2015-04-131-0/+7
| | | | | | | | | | | | | | | | The local debugging transport now implements BackupTransport.checkFullBackupSize() to detect and reject backup attempts for which no actual file content will be committed. The documentation for checkFullBackupSize() has also been expanded to document the transport's responsibilities in this regard. The local transport now lazy-creates the destination file when data is first delivered for an approved backup operation, rather than doing it proactively in performBackup(), to ensure that changes in the datastore are only attempted after the transport has positive confirmation that data is indeed flowing. Change-Id: I6e47a7e72cd938fc0ed31da4bc490540c71f9e65
* Add system API for querying the available restore dataset for a packageChristopher Tate2015-04-092-0/+39
| | | | | | Bug 20123585 Change-Id: Ife6e77a224b5d4175178aacdb7c285e9944b9eab
* Back up / restore preferred app configurationChristopher Tate2015-04-062-1/+17
| | | | | | Bug 19848104 Change-Id: I84cdfcc44b48a9732984955d7eedf745b5586bdd
* Add payload-size preflight stage to full transport backupChristopher Tate2015-03-265-18/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Don't back up / restore the code_cache/ directoryChristopher Tate2015-03-051-2/+9
| | | | | | Bug 19628750 Change-Id: I1f2f5e8083675bf70d17c0c143dc813ca9e04610
* Remove unused imports in frameworks/base.John Spurlock2015-02-281-2/+0
| | | | Change-Id: I031443de83f93eb57a98863001826671b18f3b17
* am 9568307c: am 43a4a8c7: Fix redundant file backupsChristopher Tate2015-01-151-1/+0
|\ | | | | | | | | * commit '9568307cf32c8abc6703dc7a1b0b0fee56c4f8f5': Fix redundant file backups
| * Fix redundant file backupsChristopher Tate2015-01-141-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | am 413ec4a6: am bee49807: Merge "Support single-package backup rejection by ↵Christopher Tate2015-01-071-2/+5
|\ \ | |/ | | | | | | | | | | the transport" into lmp-mr1-dev * commit '413ec4a6573ffa88bf02a796eb8c9dc7dfa839ca': Support single-package backup rejection by the transport
| * Support single-package backup rejection by the transportChristopher Tate2015-01-061-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | We now cleanly handle the case of the transport blacklisting specific packages from key/value backup. Previously we would halt the entire backup pass and reschedule if the transport returned any error from performBackup(pkg). Now, we recognize the TRANSPORT_PACKAGE_REJECTED result from that invocation, and properly drop that package's work but proceed with running the rest of the backup queue as expected. Bug 18694053 Change-Id: Id0dd6d59492bdea9f970540d776f37db0cc5d99c
* | am 15626d3a: am b32a33ce: Merge "Turn debug flag off"Christopher Tate2014-12-161-1/+1
|\ \ | |/ |/| | | | | * commit '15626d3a493b5eb4c1fecb73f8d4fc18547c4c13': Turn debug flag off
| * Turn debug flag offAlan Jeon2014-12-131-1/+1
| | | | | | | | | | Change-Id: Iced1a24ecfc182eccedd3a749fab9dd32dea41da Signed-off-by: Alan Jeon <skyisle@gmail.com>
* | Adjust wallpaper-restore acceptance criteriaChristopher Tate2014-12-031-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously the dimension check had implicit orientation sensitivity. We now make sure to compare the candidate image's width to the smallest screen dimension for acceptance purposes; this fixes cases when we would e.g. get a restored image of (1680x2560) but believe that we needed it to have a max width of 2048, even though it had originated on that same device -- due to current-orientation issues. Bug 18448052 Change-Id: I64ca6a4ed91ce1ccc04f5a9a6851e5cfe511b7c7
* | Merge "Adding method to query backup manager service activity status" into ↵Zoltan Szatmary-Ban2014-11-211-0/+7
|\ \ | | | | | | | | | lmp-mr1-dev
| * | Adding method to query backup manager service activity statusZoltan Szatmary-Ban2014-11-121-0/+7
| | | | | | | | | | | | | | | Bug: 17367491 Change-Id: I9920c07d56c4c0ccb1f3dce637c0fb390902d2ff
* | | Recents backup helperChristopher Tate2014-11-201-0/+114
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Handles backup/restore of recent tasks for the system. Currently the thumbnails are not saved. At restore time the historical task records are placed in a designated separate location rather than directly in the live bookkeeping; this avoids ID duplication issues and makes it easier to deal with lazy adoption of the historical task state as apps are installed on the device post-restore. Bug 17303286 Bug 15986349 Change-Id: Ie156c1e2ab9c9a7e7ac0447b27016fdcef55dded
* | Enable runtime turndown of backup/restore servicesChristopher Tate2014-11-071-0/+12
|/ | | | | | | | | | | | | | | | | | | | | | The heavy implementation of the backup manager service is now sitting behind a lightweight trampoline that actually provides the binder call interface. The indirection allows us now to tear down the implementation on the fly without breaking callers who have cached binder references to the backup services: these callers will simply see their future invocations failing benignly. In addition there is now an API for suitably privileged callers such as device policy management to effect this turndown. Finally, there is now a static system property, "ro.backup.disable", that a product can use to outright remove backup/restore operation from the system's operation. The public APIs will continue to be safely usable on such products but no data will be moved to or from the device. Bug 17367491 Change-Id: I8108e386ef3b5c967938fae483366d6978fe4e04
* Tweak wallpaper restore rejection thresholdChristopher Tate2014-10-101-2/+12
| | | | | | | | | Raise the height ratio threshold slightly in order to start accepting restores of height=1920 images onto height=2560 devices. Bug 17882661 Change-Id: I63b47817fdf754cda9a052bddb62aee764522c6f
* Turn on dimension validation in wallpaper restoreChristopher Tate2014-10-081-1/+1
| | | | | | Bug 17906491 Change-Id: I4c76c3197df95b51a6e44d1fe2d522b6c05284e5
* Accept any restored wallpaperChristopher Tate2014-10-061-20/+34
| | | | | | | | | ...and let the wallpaper service & hosts figure out what to do with it. Bug 17677006 Change-Id: Ie5bfa549af4da178e621ffc42a759a552897d93a
* Tweak wallpaper restore acceptance heuristicsChristopher Tate2014-10-021-20/+20
| | | | | | | | | | We now accept for restore any image that is at least wide enough to fit the screen, and has a height within a comfortable margin of the previously stated target. Bug 17677006 Change-Id: I5937a82ddfbfa0bbb30d568621eb48e4b3533fac
* Fix BackupManager.isBackupEnabled()Christopher Tate2014-09-091-0/+1
| | | | | | | | | | | | It wasn't properly lazy-initializing the service binder, so it always thought the backend service didn't exist, and so always returned false. Also directly validated that every usage of sService in the module is now correctly lazy-initialized. Bug 16661321 Change-Id: If5fbb18aef81bfa8fd70eb40a1f6af54cc96d804
* Correct misleading javadoc for BackupHelperChristopher Tate2014-08-271-4/+3
| | | | Change-Id: I3865cb3bd55f04baadedb55e9f84fc516eae75b4
* Briefly log wallpaper restore outcomesChristopher Tate2014-08-261-2/+2
| | | | | | Bug 17112780 Change-Id: I3e9a23d28c9df4f708eb24b4688322c21a8c8382
* Expose system apis for backup transport migrationarete2014-08-183-2/+9
| | | | | Bug: 16542048 Change-Id: I45e710028316e7b2dc4195700a1e7344afb54691
* Tighten restore-at-install behaviorChristopher Tate2014-08-151-0/+22
| | | | | | | | | | | | | | | | Harden the guarantee that if we're asked about a possible restore, we always ALWAYS report back to the package manager. This involved closing "should never happen" edge cases around provisioning/auto-restore setting that nevertheless were happening. Also, on the auto-restore setting front, make sure to plumb that system API through appropriately, since going behind its back and manipulating the secure setting directly would cause things to get out of step. Bug 17060654 Change-Id: I52ca9c1ffbfc0bd6b57196157500d0868bfc2989
* Start using cancelFullBackup() when appropriateChristopher Tate2014-08-091-0/+5
| | | | | | | | The API was in place but the framework wasn't yet calling it. Bug 16524520 Change-Id: Ie368758c830a7d0ad11e7dd3142a0ed896069944
* A little more system API in RestoreSetObserverChristopher Tate2014-08-081-0/+3
| | | | | | Bug 16542048 Change-Id: I8b773df872e3cc50c42645e3833d40a691edc4e7
* API to tell the transport to cancel a full backup in progressChristopher Tate2014-08-071-0/+19
| | | | | | Bug 16524520 Change-Id: If2cbffd3c8a03bf4eb7b11ff1ae784c437e27e7f
* Mark beginRestoreSession() as system APIChristopher Tate2014-08-071-2/+3
| | | | | | Bug 16874911 Change-Id: Idb06ebf2d0f54bb13af1d2eeacf0d7b06fda68db
* Reify the transport lookup/selection APIChristopher Tate2014-08-075-3/+145
| | | | | | | | | | | | | | | | | Introduce a stable BackupTransport interface class for transport implementations to derive from. Make the interface for viewing/selecting the active backup transport part of the stable API. Make restore-related classes (RestoreSession, RestoreSet) stable API. Express backup manager APIs needed for transport operation as @SystemApi methods in BackupManager. Bug 16661321 Change-Id: I423b87ae8f45c1b77831d4f8ffd97715484c2d2b
* Provide outside-facing API for data management intent+labelChristopher Tate2014-07-281-0/+12
| | | | | | Bug 16346320 Change-Id: I3f4c2f4b700c77880ba3d8db7c92cdb404763d0d
* Add data-management intent + label to BackupTransport APIChristopher Tate2014-07-281-3/+50
| | | | | | Bug 16346320 Change-Id: Id9e855a1d3cebbf801c27a21e1edc3ffcccfd2e9
* Add BackupAgent.onRestoreFinished() callbackChristopher Tate2014-07-171-3/+34
| | | | | | | | | | | | | | | | | 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
* Always call finishBackup() if performFullBackup() succeededChristopher Tate2014-07-161-0/+4
| | | | | | | | Even if we later get an error from sendBackupData() we need to give the transport its teardown callback. This simplifies the transport logic considerably. Change-Id: Ib8c0e210d4a876ee6b083a4d619dfccc462da4e5
* Add Context.getNoBackupFilesDir()Christopher Tate2014-07-142-4/+43
| | | | | | | | | | | | | | | | | | | 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
* Refactor restore to deal with heterogeneous datasetsChristopher Tate2014-06-302-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Transport-based restore now handles both key/value and full-data (stream) data delivery. Also: PMBA now holds metadata for *all* apps, not just those with backup agents. Since we need to consult this for every restore- at-install operation we cache this locally now, tagged per transport and per remote dataset, to avoid having to re-download it as part of every future restore operation. Also fixed a bug in LocalTransport that was preventing restore of key/value datasets, i.e. all of them that were nominally available prior to this change. NOTE: at present there is no automatic full-data backup; if for testing purposes you need to create some to then use for restore, you still need to use 'bmgr fullbackup ...' to push them. NOTE: at present the unified transport restore uses a refactored "engine" implementation to handle stream data that encapsulates the existing "adb restore" implementation. However, the adb restore code path has not yet been refactored to wrap the newly- extracted engine version; it still contains its own copy of all the relevant logic. This will change in a future CL, at which point offline/USB archive restore will simply wrap the same shared stream-restore engine implementation. Bug 15330073 Bug 15989617 Change-Id: Ieedb18fd7836ad31ba24656ec9feaaf69e164af8
* Adjust full restore APIChristopher Tate2014-06-191-10/+23
| | | | | | | | | | | | | | | | | | | | | | | | | Introduces a new constant, BackupTransport.NO_MORE_DATA, defined to be -1. The transport returns this constant when asked for the next chunk of streaming full restore data to indicate that it has reached EOF on the current restore target's archive stream. If the transport returns TRANSPORT_PACKAGE_REJECTED from that same method, then the OS will abort the current target's restore operation and move on to the next package in the overall restore dataset (by calling nextRestorePackage() on the transport). If the transport returns zero when asked for the next chunk of restore stream data, this will be interpreted as meaning that no data is currently deliverable but the restore download is still running properly; the caller will then retry until either data is delivered or the transport reports NO_MORE_DATA (or an error). Also sketched in the implementation of this latest API in the test LocalTransport. Bug 15330073 Change-Id: I81621cb322f831460133b7dced5bb88d2a4124e1
* Tweak restore APIChristopher Tate2014-06-173-35/+182
| | | | | | | We need the transport to tell the system not only what package it's going to deliver data for next, but also what format that data is in. Change-Id: I989cf78febf923a4208acb33ed80ccc7869356f5
* Implement full data backup through transportChristopher Tate2014-06-152-1/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Finish migration of backup transport constantsChristopher Tate2014-06-021-2/+2
| | | | | | | | ...and make sure to fix a couple of lingering Javadoc references. Bug 15329632 Change-Id: I1de7b53a58940834cd2dae2301fd5f65dbb48ba6
generated by cgit v1.1 at 2025-09-15 15:06:58 +0000