summaryrefslogtreecommitdiffstats
path: root/services/backup
Commit message (Collapse)AuthorAgeFilesLines
* Track enable/disable of transport componentsChristopher Tate2014-09-121-31/+60
| | | | | | | | | | | | | | | | | For fallback / rollback of backup transport selection we need to handle live enable/disable of legacy or superseded transports. We now watch for component enable state changes in packages that host transports, and rebind as needed. The semantics for selecting the current transport have also been adjusted. We no longer require that the selected transport be live and currently bound in order to be designated as the active instance. This prevents nondeterministic races around upgrade and replacement. Bug 17136637 Change-Id: Idaf45cf4522a23576444e6b11626ee3f7f47c36c
* The transport system API needs to manage binder identityChristopher Tate2014-09-031-8/+18
| | | | | | | | | | | ...around writing settings. It does its own proper permission check; it just needs to make sure not to accidentally crash the caller in strange and wondrous ways because of failing to clear binder identity before writing the result to secure settings. Bug 16542048 Change-Id: I88d1f2dbeebd24eed5d86989f0ca0d834878b054
* Do not require device provisioning to do restore-at-installChristopher Tate2014-08-271-3/+2
| | | | | | | | | | | | | Provisioning is a milestone used for gating *backup* operation, but it's important that restores be possible during the setup process. In particular, some applications such as home apps may be deliberately pushed for install after platform restore, but before the end of the setup process. We need to be able to do install-time restores of such apps. Bug 17288313 Change-Id: Iaff5d9919e6392b2ca5925be4d63a4116cd11f77
* Remember having done full-data as well as key/value app backupsChristopher Tate2014-08-261-2/+4
| | | | | | | | | | | | The "what have we ever succesfully backed up?" log is used to determine whether we can do an install-time restore from the currently-live dataset rather than go back to the ancestral dataset (if any). We now track apps that have gotten a successful full-data backup through the transport, not just key/value backups. Bug 17263823 Change-Id: If21350a8dd8aaa4ed02fb74101617e935920e4ae
* Merge "Fix adb backup for encrypted case" into lmp-devPaul Lawrence2014-08-231-56/+25
|\
| * Fix adb backup for encrypted casePaul Lawrence2014-08-221-56/+25
| | | | | | | | | | | | | | | | | | | | | | | | New behavior. Backup no longer uses the encryption password. This is in part because that is hard with patterns, in part because it is a security issue - the off line backup is much easier to brute force than the phone. Instead, we simply insist on an encryption password if your device is encrypted and locked. Bug: 17159330 Change-Id: Ia22f84722522abf0b569a3ef1e16ead5527c726d
* | Implement API review feedback for JobSchedulerMatthew Williams2014-08-221-3/+1
| | | | | | | | | | | | | | | | BUG: 17005336 Took the opportunity to clean up some back-off logic Change-Id: Ibc8ae34d1d44dd064ba071e4cbad17872f7e38cf
* | Merge "Automatically bind to newly-installed backup transports" into lmp-devChristopher Tate2014-08-221-34/+58
|\ \
| * | Automatically bind to newly-installed backup transportsChristopher Tate2014-08-221-34/+58
| |/ | | | | | | | | | | | | | | | | | | They'll be rebound automatically at boot, but need to be brought up immediately. As always they can only be provided by privileged apps. Bug 16542048 Change-Id: I9f121a5c111a772deb3f0c44166002a2cbb16ad5
* | Move SystemBackupAgent from services.jar to frameworks.jarBrian Carlstrom2014-08-211-185/+0
|/ | | | | Bug: 17168017 Change-Id: I89b98ca839a78eeb7fb43930e0699ee235deafad
* Maintain transport connection through package updatesChristopher Tate2014-08-211-21/+59
| | | | | | | | | | | When a package is updated, existing bindings to that package's services are severed and must be manually re-established. Now that the transport can be updated outside the system per se, make sure that we detect these cases and rebind as needed. Bug 16139912 Change-Id: I5d6fa75bb86484f8f7d4f8e93c9157773995e6a7
* Don't crash good-citizen restore session clientsChristopher Tate2014-08-191-0/+31
| | | | | | | | | | | If an app is trying to do the right thing and end its restore sessions cleanly, but winds up being slow and having the session timed out from under them, don't crash them with an illegal state exception for having appeared to end the session twice. Bug 17133115 Change-Id: I0a0989e2067b156569bddb6626ce045e625c6604
* Minor restore fixesChristopher Tate2014-08-181-5/+9
| | | | | | | | | | | | | | | | | | | | 1. We were missing a 'break' in the session-timeout case of message dispatch, so were falling through into a different case. Oops. Fortunately it was benign; the other case's logic was merely logging "hey it doesn't look like there's anything to do here" and cleanly exiting. 2. After a restore operation finishes we were previously always leaving the session timeout clock running. However, this was not appropriate in the case of restore-at-install, when the restore was a one-shot kicked off by the package manager rather than an operation on an ongoing RestoreSession. That logic now properly tidies up the session timeout when winding up the restore in either situation. Bug 17080648 Change-Id: I51d4a50db4feefc4c355230a3bfb926ea2fb5944
* Tighten restore-at-install behaviorChristopher Tate2014-08-151-2/+10
| | | | | | | | | | | | | | | | 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-17/+14
| | | | | | | | The API was in place but the framework wasn't yet calling it. Bug 16524520 Change-Id: Ie368758c830a7d0ad11e7dd3142a0ed896069944
* Merge "Sanity-check paths of files to be restored" into lmp-devChristopher Tate2014-08-071-0/+16
|\
| * Sanity-check paths of files to be restoredChristopher Tate2014-08-041-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The duplicated implementations are an artifact of an ongoing refactor of the full-data restore code. The adb-specific path will be switched to use the FullRestoreEngine [as has already been done for the 'adb backup' path using the parallel full backup engine], at which point the extra implementation here will be removed, but for now we need to make sure that all bases are covered. Bug 16298491 Change-Id: I9cdb8a1c537939a620208df3cf0e921061b981ad
* | Add event logs for full backup/restore milestonesChristopher Tate2014-08-061-2/+24
| | | | | | | | | | | | Bug 16689703 Change-Id: If870f1b7b9cb3929ac1edc38affc688a37c2acfd
* | Ensure backup schedule file is closed.Michael Wright2014-08-051-3/+10
|/ | | | Change-Id: Ie4a62cda74815c67c62fb08e8df25a71d6102d4c
* Make archive metadata idempotentChristopher Tate2014-07-291-0/+11
| | | | | | | | | | We want to make sure that the manifest and widget metadata blocks are identical, including their in-stream headers, if we regenerate the archive without underlying filesystem changes. Bug 15968355 Change-Id: I828b264545d19e1d865d98d5723915d02fafc012
* Provide outside-facing API for data management intent+labelChristopher Tate2014-07-281-0/+44
| | | | | | Bug 16346320 Change-Id: I3f4c2f4b700c77880ba3d8db7c92cdb404763d0d
* Schedule full backupsChristopher Tate2014-07-282-94/+534
| | | | | | | | | Initial policy: at most daily; backups only run when the device is idle + charging + on an unmetered network. Bug 16485874 Change-Id: I5665d890a943bac765adcef14be79d7dba6ce078
* A couple of restore fixes:Christopher Tate2014-07-241-8/+3
| | | | | | | | | | | | * Fix crasher after transport-level failure attempting to ask for the name of the next package to be restored * Current-dataset single-package restore path no longer requires that the package have its own backup agent. Bug 16548983 Change-Id: Id37f2f0e6075d53c414d9a997bf738bbf0cfff8b
* Handle single-package restores properlyChristopher Tate2014-07-221-41/+48
| | | | | | Bug 16346405 Change-Id: I69e3288f5a9d68d818fad6a2cd4b27ad45c1007e
* Always check restore against the latest backend metadataChristopher Tate2014-07-222-182/+70
| | | | | | Bug 16484934 Change-Id: I472a7db89a94b9804f6ea94c25da206dd111a497
* Tear down agents properly at EOD in full restoreChristopher Tate2014-07-171-1/+18
| | | | | | | | | | | | | | | | The restore engine wasn't tearing down the bound agent after reaching the end of data for the app, and furthermore was allowing the restore operation to resume running the queue before all data had been delivered to the current target. Also make LocalTransport deliver data in 2K chunks rather than 32K, as a first step towards making its timing characteristics more like we'll see in networked situations. Finally, added a bunch of MORE_DEBUG output for finding odd bugs like this. Change-Id: Icdbe6a070af6cc7c708a938ad044108d40ebce9a
* Properly end full restore attempt if getNextFullRestoreDataChunk() failsChristopher Tate2014-07-171-0/+1
| | | | | | Don't just drop the error return on the floor and retry (forever!). Change-Id: I5f0ef2d09ea286d813add69517f865e474341b43
* Add BackupAgent.onRestoreFinished() callbackChristopher Tate2014-07-171-19/+93
| | | | | | | | | | | | | | | | | 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-7/+18
| | | | | | | | 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-141-3/+33
| | | | | | | | | | | | | | | | | | | 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
* Fix NPE in platform restoreChristopher Tate2014-07-081-3/+3
| | | | | | Bug 16061451 Change-Id: I79d7913455886828a493a0c4ea850d259bfeeeab
* Change new file installs to be cluster-based!Jeff Sharkey2014-07-081-1/+2
| | | | | | | | | | | | | | | | Now that all the other pieces are in place, we're ready to start installing new file-based packages as a cluster (the new unified directory-based layout). This greatly simplifies the renaming process. Also add helper methods to ApplicationInfo to give a much clearer mapping between it and internal field names, since we can't change the public API. Add recursive restorecon(). Bug: 14975160 Change-Id: I72a63c5ddbc594c2fec4a91dd59f73ef253fbfd7
* Refactor restore to deal with heterogeneous datasetsChristopher Tate2014-06-302-421/+2229
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Tweak restore APIChristopher Tate2014-06-171-2/+7
| | | | | | | 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-151-330/+603
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add full-backup stream API to BackupTransportChristopher Tate2014-06-021-39/+39
| | | | | | | | | | | | Also started migrating the definition of transport success/failure constants into BackupTransport to make them permanent. The new methods are not yet plumbed in; this is just to allow forward progress against a proposed stable API. Bug 15329632 Change-Id: I27472e09b831350c140b9fa548ebda3af334eb1a
* Move internal libcore.os users over to android.system.Elliott Hughes2014-04-281-4/+3
| | | | Change-Id: I84e1ace19ba3b4e58d7bb24f3ecda1bdf5dc75a5
* Don't crash on null installer package bookkeeping.Christopher Tate2014-04-081-1/+1
| | | | | | Bug 13906859 Change-Id: I926ccc5620abae8b97bd2b7de21b82b7729e78dd
* Back up the preferred home app, if anyChristopher Tate2014-04-042-10/+120
| | | | | | | | | | If the user has stated a preference about their home app, make sure we capture that so that a system restore can return them to that preferred situation. It's built into the system metadata so that we can, if necessary, fast-path configuration of that home app while the rest of the restore operation is in flight. Change-Id: I64dfee8f7a2a9e40f556cd19298d7b367c6aa8dc
* Rejigger the invalid-key checks at backup timeChristopher Tate2014-04-011-4/+46
| | | | | | Bug 13732002 Change-Id: Ic8f71234d1bbc7420eaa8e1762b999d09f308d46
* App widget backup/restore infrastructureChristopher Tate2014-03-201-91/+390
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backup/restore now supports app widgets. An application involved with app widgets, either hosting or publishing, now has associated data in its backup dataset related to the state of widget instantiation on the ancestral device. That data is processed by the OS during restore so that the matching widget instances can be "automatically" regenerated. To take advantage of this facility, widget-using apps need to do two things: first, implement a backup agent and store whatever widget state they need to properly deal with them post-restore (e.g. the widget instance size & location, for a host); and second, implement handlers for new AppWidgetManager broadcasts that describe how to translate ancestral-dataset widget id numbers to the post-restore world. Note that a host or provider doesn't technically need to store *any* data on its own via its agent; it just needs to opt in to the backup/restore process by publishing an agent. The OS will then store a small amount of data on behalf of each widget-savvy app within the backup dataset, and act on that data at restore time. The broadcasts are AppWidgetManager.ACTION_APPWIDGET_RESTORED and ACTION_APPWIDGET_HOST_RESTORED, and have three associated extras: EXTRA_APPWIDGET_OLD_IDS EXTRA_APPWIDGET_IDS EXTRA_HOST_ID [for the host-side broadcast] The first two are same-sized arrays of integer widget IDs. The _OLD_IDS values are the widget IDs as known to the ancestral device. The _IDS array holds the corresponding widget IDs in the new post- restore environment. The app should simply update the stored widget IDs in its bookkeeping to the new values, and things are off and running. The HOST_ID extra, as one might expect, is the app-defined host ID value of the particular host instance which has just been restored. The broadcasts are sent following the conclusion of the overall restore pass. This is because the restore might have occurred in a tightly restricted lifecycle environment without content providers or the package's custom Application class. The _RESTORED broadcast, however, is always delivered into a normal application environment, so that the app can use its content provider etc as expected. *All* widget instances that were processed over the course of the system restore are indicated in the _RESTORED broadcast, even if the backing provider or host is not yet installed. The widget participant is responsible for understanding that these are promises that might be fulfilled later rather than necessarily reflecting the immediate presentable widget state. (Remember that following a cloud restore, apps may be installed piecemeal over a lengthy period of time.) Telling the hosts up front about all intended widget instances allows them to show placeholder UI or similarly useful information rather than surprising the user with piecemeal unexpected appearances. The AppWidgetProvider helper class has been updated to add a new callback, onRestored(...), invoked when the _RESTORED broadcast is received. The call to onRestored() is immediately followed by an invocation of onUpdate() for the affected widgets because they will need to have their RemoteViews regenerated under the new ID values. Bug 10622506 Bug 10707117 Change-Id: Ie0007cdf809600b880d91989c00c3c3b8a4f988b
* Fix build. Silly gits.Christopher Tate2014-03-051-20/+0
| | | | Change-Id: I8f21b7239621da500d9a73eb17d350e06dda9b20
* am 777b8a80: am 422b2656: resolved conflicts for merge of c45ff35f to ↵Christopher Tate2014-03-051-0/+20
| | | | | | | | | klp-modular-dev * commit '777b8a808ee76401429f7210ebb7194632040d45': Adapt to underlying changes in the PBKDF2 implementation Change-Id: Ia68694a03e52693fceaedc6740dbd8e690e21257
* Don't hang installs if the transport disappearsChristopher Tate2014-03-031-10/+19
| | | | | | Bug 12991308 Change-Id: Ie5d3d27fe565dd4014976f5333e37b5707acb707
* Fix build.Narayan Kamath2014-02-111-0/+1
| | | | | | | com.android.server.SystemServer was no longer imported on master. Change-Id: Ie712aa28940953952aa7a99cbb22f74129649249
* am 25df673b: am 1b51c9cb: Merge "Make SystemService constructor take a ↵Jeff Brown2014-02-112-36/+14
|\ | | | | | | | | | | | | Context." into klp-modular-dev * commit '25df673b849de374cf1de40250dfd8a48b7ac28b': Make SystemService constructor take a Context.
| * Make SystemService constructor take a Context.Jeff Brown2014-02-102-36/+14
| | | | | | | | | | | | | | | | | | | | This change simplifies the process of initializing a SystemService by folding the onCreate() step back into the constructor. It removes some ambuiguity about what work should happen in the constructor and should make it possible for services to retain most of their final fields after refactoring into the new pattern. Change-Id: I25f41af0321bc01898658ab44b369f9c5d16800b
* | am a5a93f55: am 7f416631: Merge "Check feature bits before loading optional ↵Adam Lesinski2014-02-062-11/+12
|\ \ | |/ | | | | | | | | | | services" into klp-modular-dev * commit 'a5a93f559d337ad5b79716b05ea43707eb779dc8': Check feature bits before loading optional services
| * Check feature bits before loading optional servicesAdam Lesinski2014-02-052-11/+12
| | | | | | | | | | | | | | | | At startup, we check with PackageManager whether a system service is available before attempting to load it. A system service is available if its associated feature (similar to hardware features) is present. This does not remove unavailable services from the compiled jar. Change-Id: I13571805083aa4e65519a74acb52efd17b9fb3d7
* | Adapt to underlying changes in the PBKDF2 implementationChristopher Tate2014-01-161-84/+169
| | | | | | | | | | | | | | | | | | | | | | We need to specify "PBKDF2WithHmacSHA1And8bit" now in order to get precisely the same output as was previously generated with "PBKDF2WithHmacSHA1". We also now try both when it's ambiguous which was used to generate the archive checksums. Bug 12494407 Change-Id: I5443f31a5e13c24f44445768b6e9a6eea221ede6
generated by cgit v1.1 at 2025-01-16 09:09:25 +0000