summaryrefslogtreecommitdiffstats
path: root/services/backup
Commit message (Collapse)AuthorAgeFilesLines
* Stop feeding restore engine if it's already in failed state and exit.rhed_jao2015-11-071-0/+5
| | | | | | | | | b/24518516 modified: services/backup/java/com/android/server/backup/BackupManagerService.java Change-Id: I371b7e87fa7ba408b1255263c6d23821496916a2 Signed-off-by: rhed_jao <rhed_jao@htc.com>
* Fix deadlock between ActivityManager and BackupManager under some race ↵lwan89x2015-11-071-7/+14
| | | | | | | | | | | | | | | | | | | | conditions. Deadlock may happen when bind backup agent under some race condition. If waiting for backup agent timeout, BackupManager will call to ActivityManager's clearPendingBackup with mAgentConnectLock held. During clearPendingBackup process, it will try to lock ActivityManager's main lock. If app started up timeout at the same time, ActivityManager will call to BackupManager's agentDisconnected with main lock held. During agentDisconnected process, it will try to lock mAgentConnectLock. Deadlock happened then. In bindToAgentSynchronous process, move clearPendingBackup out of lock area to fix this issue. Change-Id: Ic1acfe1df8fd83d4acff5ce518d86cea4b2fe18b Signed-off-by: lwan89 <liang.wang@intel.com> Signed-off-by: Zhiquan Liu <zhiquan.liu@intel.com>
* backup: Fix the system server crash fixmyfluxi2015-10-271-1/+1
| | | | | | | | | | | | | | | We still need the firefighters after commit eff323bf. --------- beginning of crash E/AndroidRuntime(649): *** FATAL EXCEPTION IN SYSTEM PROCESS: backup E/AndroidRuntime(649): java.lang.NullPointerException: Attempt to invoke virtual method 'java.io.FileDescriptor android.os.ParcelFileDescriptor.getFileDescriptor()' on a null object reference E/AndroidRuntime(649): at com.android.server.backup.BackupManagerService$PerformBackupTask.operationComplete(BackupManagerService.java:2826) E/AndroidRuntime(649): at com.android.server.backup.BackupManagerService$BackupHandler.handleMessage(BackupManagerService.java:778) E/AndroidRuntime(649): at android.os.Handler.dispatchMessage(Handler.java:102) E/AndroidRuntime(649): at android.os.Looper.loop(Looper.java:135) E/AndroidRuntime(649): at android.os.HandlerThread.run(HandlerThread.java:61) Change-Id: I28a9e8920bb33e687394fd6da6daede31bd77420
* backup: Fix a system server crashSteve Kondik2015-10-271-0/+6
| | | | | | | | | | | | | | | * If we get into a state where the backup data is null, system server will go down in flames. Abort and kill any active agents if this happens. java.lang.NullPointerException: Attempt to invoke virtual method 'java.io.FileDescriptor android.os.ParcelFileDescriptor.getFileDescriptor()' on a null object reference at com.android.server.backup.BackupManagerService$PerformBackupTask.operationComplete(BackupManagerService.java:2820) at com.android.server.backup.BackupManagerService$BackupHandler.handleMessage(BackupManagerService.java:778) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:135) at android.os.HandlerThread.run(HandlerThread.java:61) Change-Id: I65cb3c7d75a417373e8a59b9150a61b5eb1939af
* Crashing the system process is inadvisableChristopher Tate2015-08-281-4/+6
| | | | | | | | | | | When asking for the set of services published by a package, it's quite possible that there are none, in which case the returned List<> is null rather than valid-but-empty. Don't bother looking at it when it's null. Bug 23614440 Change-Id: Ibebb26b9c3f75ec810a95f1b9d2663e884cb98bc
* Make sure to kill restore-at-install full-data targets after restoreChristopher Tate2015-08-201-16/+30
| | | | | | | | | | Specifically: correctly distinguish the "I want to restore my own data" case, in which the app is intentionally not killed, from the single-package restore at install operation. Bug 23357388 Change-Id: Ic50ac39fe942af1f6ec9e04a32d81a39b70a0b2b
* Clean up properly if outcall for doRestoreFinished() failsChristopher Tate2015-08-171-2/+6
| | | | | | | | | | | | The target app crashed at an inopportune time but this shouldn't invalidate the whole ongoing restore operation; it's a problem local to the specific app undergoing restore. Recognize this, clean up the app's possibly-incomplete data, and continue running the restore queue as planned. Bug 23228982 Change-Id: If9a19d2fe6a0ce5339c893630d7a61a5a5ccd9b1
* Fix issues around process teardown after full-data restoreChristopher Tate2015-07-291-2/+12
| | | | | | | | | | | | | | The unified code path for cleanup was mistakenly looking at the android:killAfterRestore manifest attribute even for full-data restore operations. That attribute is only relevant for key/value payload handling. We need to *always* kill after restore in the full-data case because the app will otherwise be allowed to enter normal component lifecycles without its correct Application / ContentProvider state in force. Bug 22704852 Change-Id: Ia63f985a35c28084c734389cfc49d3792173e5c7
* Don't redundantly call transport.finishRestore()Christopher Tate2015-07-281-10/+2
| | | | | | | | | | The RestoreSession is no longer responsible for calling finishRestore(); that happens as part of tidying up after running the restore itself, even in failure cases. Bug 22640096 Change-Id: I0be52af2ae8c2c1ac685e9904ccb8120f7fcf522
* Clean up obsolete pending timeout after restoring package metadataChristopher Tate2015-07-071-1/+4
| | | | | | Bug 22040047 Change-Id: I460dbcc50a45d794392beb9ff4a4358c05c87e07
* Fix dispatch of onRestoreFinished()Christopher Tate2015-06-301-38/+40
| | | | | | | | | | | | The agent instance wasn't properly being conveyed from the generic restore engine implementation to the state machine handling the lifecycles. On top of that, the lifecycle wasn't advancing to the restore-finished callback phase properly in the full-data restore case. Bug 22194736 Change-Id: Ic649d6a196adbd21a4a0f3083c7eed2fff383e52
* Don't run backups in battery-saver modeChristopher Tate2015-06-051-11/+26
| | | | | | | | Defer both full-data and key/value backups while in battery-saver mode. Bug 21563473 Change-Id: I081b7bcd19af21a4c88ebb434d2d3ef4bc93951f
* Adjust key/value backup schedulingChristopher Tate2015-05-301-6/+8
| | | | | | | | | | We now try to perform key/value backups only while charging, proceeding off-charger only after we've waited a full day for the device to be plugged in. Bug 21076663 Change-Id: Ib32c9f8bfaf8a310f5f388907e38a28d3c54bd8e
* Don't erase backup metadata when an app is uninstalledChristopher Tate2015-05-272-77/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | We still retain the data in the backup, in order to support the flow in which a user has the app and its data is stored; then the app is uninstalled; then later the app is reinstalled. We depend on having correct metadata for the data in the datastore in order to evaluate its validity for restore-at-install, so we mustn't forget that metadata just because the app is not currently installed. We also now permit the sentinel pseudopackage name "@pm@" as an argument to dataChanged(), indicating specifically that the metadata should be scheduled for backup without having to be piggybacked on another app's requested backup pass. That lets us now make sure to schedule a backup pass for metadata-update in response to app install activity. Finally, fix a "min instead of max" bug in full backup scheduling that was causing the OS to ignore the transport's inter-package quiet time requirement when multiple packages were overdue for backup. Bug 21471973 Change-Id: I1dbc260edb91b8deadd2744e273dfa9578b9ef2a
* Scan at boot time to detect newly-present full backup candidatesChristopher Tate2015-05-211-66/+99
| | | | | | | | | | OTA or similar might have caused an app to appear without the usual notifications being sent. Make sure we pick up those apps as appropriate for full-data backup. Bug 19462310 Change-Id: Ic17bc72b14cc7599ae8ea540548fda932606b8f2
* Rebind backup transports only when clearly neededChristopher Tate2015-05-191-11/+51
| | | | | | | | | | | | | Significantly narrow the circumstances under which transports will be re-bound. In particular, we now do not unbind + rebind whenever any component in a bound transport's host package changes; rather, we do so only when the transport component itself has changed state, or when there is a state change that might cause a new transport to become available. Bug 19775237 Change-Id: Ib386875df19ffe9f2d3eb9f9788187338360644a
* Fix requestRestore() of an app's own packageChristopher Tate2015-05-061-34/+37
| | | | | | | | The BACKUP permission check was being applied over-zealously. Bug 19336200 Change-Id: Ia52b5c5cc0fd8d19b74ee624be85113d1b8dca7e
* Add full backup criteria to android manifestMatthew Williams2015-05-031-1/+1
| | | | | | | | | | | | 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
* Add system API for querying the available restore dataset for a packageChristopher Tate2015-04-092-1/+10
| | | | | | Bug 20123585 Change-Id: Ife6e77a224b5d4175178aacdb7c285e9944b9eab
* Back up / restore preferred app configurationChristopher Tate2015-04-061-0/+1
| | | | | | Bug 19848104 Change-Id: I84cdfcc44b48a9732984955d7eedf745b5586bdd
* Fixes to full-backup scheduling edge casesChristopher Tate2015-03-302-37/+81
| | | | | | | | | | | | If a scheduled full-data backup was attempted but the device had not yet run the primary key/value backup pass, the full-data backup scheduler would wind up in a bad state and potentially never retry until reboot. We now properly reschedule a future retry, using the key/value scheduling batch quantum as a backoff to be sure to give it a chance to run before the next time full data is attempted. Change-Id: Ic7eb7a7940fe6380f40d04813a46fc336e95815e
* Respect the transport's requestFullBackupTime() backoffChristopher Tate2015-03-271-8/+25
| | | | | | | | | | | | | We now make sure to pause by at least requestFullBackupTime() between full-data backup operations, to give the transport the ability to apply traffic control while we're running the queue of eligible packages. Also, we now reset a package's queue position whenever a full-data backup for that package is run explicitly via adb. Bug 19732890 Change-Id: I6cf24495ad18eebd55557f229d11c703e5b7f529
* Add payload-size preflight stage to full transport backupChristopher Tate2015-03-262-68/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Switch to new userActivity and package install APIsChristopher Tate2015-03-241-15/+23
| | | | | | | | Tracking the deprecation of older API variants and switching to the new and more informative versions. Also tidying up a few unused variables along the way. Change-Id: I282a18525f9db838f4e0a77c90403b8b904e4fd7
* Don't run full backups until package metadata has been pushedChristopher Tate2015-03-121-0/+10
| | | | | | Bug 19692849 Change-Id: I13615db7408b5c6fbc787c4773103c052e70f0b2
* Don't run full backups on stopped packagesChristopher Tate2015-03-111-0/+8
| | | | | | | | | | We already decline to run key/value backup passes for (participating) apps that are in the 'stopped' state. Now we also properly avoid full-data backup passes on such apps. Bug 19684052 Change-Id: Ieafc07b5531a91a243d57238c53db41ad3459140
* Don't enqueue allowBackup=false apps for full backup attemptsChristopher Tate2015-03-051-9/+38
| | | | | | | | | | | | | | | | | | | | | | | | We are correctly refusing to actually process apps for backup if they have declared android:allowBackup="false" in their manifests, but we're still wasting bookkeeping & a certain amount of work in tracking them as part of the full backup queue. Fix that; now we recognize that they shouldn't be in the queue in the first place. When reinflating the queue at boot time we also re-verify the participation of each mentioned app so that we properly drop ones that have been uninstalled or altered such that they are no longer full-data backup candidates. Finally, if an app previously implemented key/value backup, so we think we'll be running it in that mode in a future backup pass, but has been updated to use the full-data path instead, we don't want to go ahead and run a key/value pass on it. Added a backstop check and proceed gracefully in this situation. (Also add bit more debug-build logging to LocalTransport) Bug 19462310 Change-Id: I07ab4f2e68e92766d9e8f2595fa763c91193d743
* Use scheduled job rather than periodic alarms for key/value backupsChristopher Tate2015-03-022-49/+148
| | | | | | | | | | | | | Instead of a runs-forever periodic alarm that drives key/value backup passes, we instead schedule-on-demand a trigger job that will kick off the pass after a batching interval. The key semantic change is that we now never wake for key/value backup work unless we've been explicitly asked to do so. We also use a rather longer batching interval than was previously the case. Bug 19536032 Change-Id: Ie377562b2812c9aeda0ee73770dfa94af6017778
* Merge "Don't crash when backup timeout races with agent completion"Christopher Tate2015-02-251-1/+16
|\
| * Don't crash when backup timeout races with agent completionChristopher Tate2015-02-241-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | There's a narrow window of time in which an agent reporting that its operation has completed races with timeouts such that we wind up handling the completion callback just after certain fundamental state has been reset. Detect this race and proceed gracefully instead of crashing. Bug 19498669 Change-Id: I5a475527db1a55a8e567366ddfb10112e427682e
* | Check DUMP permission in the backup service trampolineChristopher Tate2015-02-241-0/+2
|/ | | | | | | | | | Make sure that even if backup is disabled outright (and hence there is no underlying service implementation for the trampoline to delegate to), the DUMP permission exception is thrown as expected. Bug 19422232 Change-Id: I6d1a17c5f85adcfad75af969b521920e786c05a8
* resolved conflicts for merge of 517e0274 to lmp-mr1-dev-plus-aospAlex Klyubin2015-02-111-2/+3
|\ | | | | | | Change-Id: Ic20b6c8851458483dd73a144bd5ae6e8d141e62a
| * Move hidden ApplicationInfo flags into a separate field.Alex Klyubin2015-02-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The public API field android.content.pm.ApplicationInfo.flags can support only 32 flags. This limit has been reached. As a short term workaround to enable new public flags to be added, this CL moves flags which are not public API into a separate new field privateFlags and renames the affected flags constants accordingly (e.g., FLAG_PRIVILEGED is now PRIVATE_FLAG_PRIVILEGED). The new privateFlags field is not public API and should not be used for flags that are public API. The flags that are moved out of ApplicationInfo.flags are: * FLAG_HIDDEN, * FLAG_CANT_SAVE_STATE, * FLAG_FORWARD_LOCK, and * FLAG_PRIVILEGED. NOTE: This changes the format of packages.xml. Prior to this CL flags were stored in the "flags" attribute. With this CL, the public flags are stored in a new "publicFlags" attribute and private flags are stored in a new "privateFlags" attribute. The old "flags" attribute is interpreted by using the old values of hidden/private flags. Change-Id: Ie23eb8ddd5129de3c6e008c5261b639e22182ee5
* | Don't run full-data backups when backup is disabledChristopher Tate2015-01-291-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the scheduled job fires but backup is disabled or the device is not yet provisioned (i.e. has not yet finished going through setup), bow out gracefully without running any backup operations. Also, even if a backup is directly invoked (e.g. via adb), verify again right before we start collecting app data, and abandon the operation in that path as well. (This is redundant; having only the latter test would suffice, but this lets us distinguish in the logging more easily.) Finally, make sure that if we were waiting on setup before permitting backup operations to begin, that we startup the full-data scheduling as well as the [separate] key/value scheduling. Bug 19197062 Change-Id: I3d8fb650c50f946d8ed7ac7170df361c707f2528
* | Don't write widget metadata to backup unless it's new/changedChristopher Tate2015-01-151-11/+80
| | | | | | | | | | | | | | | | | | | | Redundant backup traffic is bad. Don't commit the widget metadata payload (or the deletion operation for it) unless the widget state of the app has actually changed since the last backup. Bug 19003911 Change-Id: I93819173c0e2357b030d9e2b3d2ee57f2410bb57
* | Support single-package backup rejection by the transportChristopher Tate2015-01-061-9/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Remove the "backup_data_changed" event logChristopher Tate2015-01-051-2/+0
| | | | | | | | | | | | | | | | Nowadays it's just spammy and uninformative, so away it goes. Bug 18833115 Change-Id: Ic373c596d7a892c4fedc0343e2c03dc1c295225e
* | Correctly parse previous PMBA state during backupChristopher Tate2014-12-041-1/+2
| | | | | | | | | | | | Bug 18628030 Change-Id: Iefa23de50dd9e1b27cfa5d887f117876d57e4083
* | Don't crash if a system restore fails before constructing the PMBAChristopher Tate2014-12-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | If a whole-system restore operation failed at just the wrong point, we'd wind up in the teardown code without a certain vital bit of it having been initialized, and crash on the null pointer. Now we recognize this failure mode and make sure not to do that. Bug 18574450 Change-Id: Ifa2c10ce16bb3c6bc916ed7151c5fd51b7225691
* | Adding method to query backup manager service activity statusZoltan Szatmary-Ban2014-11-121-1/+16
| | | | | | | | | | Bug: 17367491 Change-Id: I9920c07d56c4c0ccb1f3dce637c0fb390902d2ff
* | Enable runtime turndown of backup/restore servicesChristopher Tate2014-11-073-20/+348
|/ | | | | | | | | | | | | | | | | | | | | | 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
* Eliminate race condition around backup completion + resumptionChristopher Tate2014-10-161-1/+4
| | | | | | | | | | | | | Ensure that the callback always sees the current-operation state in sync with the various other bits of internal backup-operation state. Previously only the current-operation state was managed inside the critical section; this resulted in a slim race window where a callback could see an ongoing operation as still valid, but after the internal state on which that operation depended had already been cleared. Bug 17931760 Change-Id: Ia032668e7a9d22f1029c57fc98db9e86484d5719
* Fix spurious restore session timeoutsChristopher Tate2014-10-161-0/+15
| | | | | | | | | | | | | | | | | The restore-session idle timeout should not be ticking while we're doing legitimate restore work. We now explicitly stop the timeout ticker [a delayed message on our handler thread] whenever we undertake a valid restore operation. The timer is already correctly resumed when restore operations conclude. (In practice we need to suspend the timeout tracking at exactly those times when we're entering the wakelock-protected restore flow. The timeout is reestablished when the wakelock is released; this part is already in the code.) Bug 17990544 Change-Id: I7318020ce30fd9c35bc3a644f8c101fd3d063c8b
* Fix bug 17931760 - spurious timeout leads to mayhemChristopher Tate2014-10-091-0/+5
| | | | | | | | We know a priori that the PMBA metadata package's backup pass doesn't need to be tracked for timeout, because it's run inline rather than as an asynchronous separate-process operation. Change-Id: Ifd21ab3a016917f5e557a38c1c88f8d8ac1337d2
* Actually tell the widget service that restore is startingChristopher Tate2014-10-081-0/+5
| | | | | | | | | Before beginning a full-system restore we need to tell the widget service, so that it can properly start remapping IDs from the ground state. Bug 17869323 Change-Id: I152257563f5b52cae67244e936bc2c44ced7618d
* adb backup/restore fixesChristopher Tate2014-10-031-6/+12
| | | | | | | | Bug 17811327 : teach adb restore about the new widget metadata entries Bug 14165872 : -nosystem should not act like -onlysystem Change-Id: I39da0ba80df7c5309a78ec1fa38016cebd80aa5f
* 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
generated by cgit v1.1 at 2024-11-01 04:33:04 +0000