summaryrefslogtreecommitdiff
path: root/services/java/com/android/server/BackupManagerService.java
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix restore-agent timeoutsChristopher Tate2011-09-061-231/+397
| | | | | | | | | | | This patch parallels the previous one that fixed backup timeouts. It establishes the same sort of state-machine process for walking through the restore steps solely as events posted to the backup manager's HandlerThread. Fixes the rest of bug 5074923 Change-Id: I122a021cb1e9bb1342de0b71e5d4bc84cc630c58
* Fix backup-agent timeoutsChristopher Tate2011-09-021-205/+445
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Away in the misty span of very-long-ago, it was suggested that spinning a separate thread to run the backup process was wasteful, and that it could just run it inline on the dedicated HandlerThread that the backup manager uses for its own operations. That was indeed true, except that the timeout management was also using delayed messages to that handler. You see where this is going: timeouts were never actually being processed, with the effect that a badly-behaving app's backup agent could lock up the entire backup / restore system until the device was rebooted. This is bad. Backup operations are now driven as an asynchronous state machine: each step (init, call one agent to obtain data, send resulting data to the transport, finalize the backup) is handled as a formal state transition on-looper. No synchronous wait-for-completion or -timeout is performed on any thread. As an additional effect this greatly tightens up the serialization and locking semantics. We no longer have to worry about an in- flight operation involving a standalone thread spinning off on its own; everything is on the HandlerThread and can be coherently manipulated from that perspective. Along the way, this CL tightens up the per-agent error handling logic. Previously a single failed agent would abort the entire backup process, tantamount to a transport-level failure. This could mean that the aforesaid badly-behaving app's agent could in effect starve out other apps whose agents were routinely showing up later in the queue. There's some nondeterminism involved, but in practice it could and did happen. Furthermore, the failure case would reschedule *immediately* in this case, because the transport itself would see that all is well and sure, why not run a backup soon? This, as you might imagine, causes battery-life issues. Now we note that the single agent has failed, mark it for a future repeat attempt, and process the rest of the queue normally, pretending success at the transport level even though we didn't actually send any data for that app. This means that (a) we now finish running backups for everything in the queue, (b) reschedule backups only for those apps whose agents individually failed during this run, and (c) perform the retry after the normal interval [typically on the order of an hour] rather than immediately. NOTE: this CL does not retool the restore code path, just backup. Restore is similarly vulnerable to misbehaving apps, though, so a future CL will address that bug vector. Addresses bug 5074923 Change-Id: I67e3f8d06f322607881eaa4093de6d675b85ff2c
* Properly handle PACKAGE_REPLACED in addition to _ADDED and _REMOVEDChristopher Tate2011-08-301-21/+29
| | | | | | | | | | | | | | | | | Certain kinds of application update generate this broadcast regime rather than the REMOVE / ADD sequence that results from e.g. using the -r option when invoking 'adb install'. We also push the agent classname lookup to the last moment before actually running the backup, rather than caching it as part of the record of what apps need a backup pass in the future. This was causing a bug in which a package reinstall that renamed the app's agent class would wind up with a crash at backup time, trying to load the wrong class. Fixes bug 5156094 / bug 4308977 Change-Id: I4e3e12d86e6ee40809f14fd12ab762116dbee0b5
* Merge "Throw exception on odd length Signatures"Kenny Root2011-08-161-0/+2
|\
| * Throw exception on odd length SignaturesKenny Root2011-08-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The old version of this code would silently truncate odd-length Signatures. However, this masks some bugs. Add a throw of IllegalArgumentException so users can easily see where they're getting bad input for Signatures. Also, go through the existing code and catch this exception or pre-check the input strings so system_server doesn't crash later. Bug: 5092338 Change-Id: I8c672c5eaeb738a92c4581ce0df09baf719980ef
* | Fix partial-read handling during restoreChristopher Tate2011-08-101-28/+50
| | | | | | | | | | | | | | | | | | | | | | ...by once and for all making all of the code deal appropriately with expected partial reads. We also now produce a properly conformant underlying 'tar' EOF sequence [which will be compressed to almost nothing] to doubly bulletproof the end-of-archive logic. Fixes bug 5133658 Change-Id: I24a785574861d64ef10fc727b9f6b235575696b0
* | Fix bug where sometimes the full backup pw would not be validatedChristopher Tate2011-08-051-9/+9
|/ | | | | | | | There was a hole where if no backup pw was supplied and the current pw authentication field was also left blank, it wound up not verifying and just proceeding with the backup. Change-Id: I857d8e83cbb2b3bf6b6b04848c5696ef0cf393a1
* Reduce backup manager logspewChristopher Tate2011-08-011-28/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...with particular attention to boot-time logging. In particular, the following kinds of messages are now cut unless someone turns on the new MORE_DEBUG flag in their local build: 08-01 11:25:32.203 155 223 V BackupManagerService: starting timeout: token=4f52ccd1 interval=30000 08-01 11:25:32.211 155 223 V BackupManagerService: opComplete: 4f52ccd1 08-01 11:25:32.211 155 223 V BackupManagerService: operation 4f52ccd1 complete: finalState=1 08-01 11:25:32.211 155 223 V PerformBackupThread: doBackup() success and 01-01 00:00:19.710 148 162 V BackupManagerService: Adding 9 backup participants: 01-01 00:00:19.710 148 162 V BackupManagerService: PackageInfo{41af0380 android} agent=com.android.server.SystemBackupAgent uid=1000 killAfterRestore=false 01-01 00:00:19.710 148 162 V BackupManagerService: PackageInfo{41aa5068 com.android.browser} agent=com.android.browser.BrowserBackupAgent uid=10005 killAfterRestore=true 01-01 00:00:19.710 148 162 V BackupManagerService: PackageInfo{4199ce28 com.android.nfc3} agent=com.android.nfc.NfcBackupAgent uid=1025 killAfterRestore=true 01-01 00:00:19.710 148 162 V BackupManagerService: PackageInfo{41a6e170 com.android.providers.settings} agent=com.android.providers.settings.SettingsBackupAgent uid=1000 killAfterRestore=false 01-01 00:00:19.710 148 162 V BackupManagerService: PackageInfo{4198ba90 com.android.providers.userdictionary} agent=com.android.providers.userdictionary.DictionaryBackupAgent uid=10000 killAfterRestore=false 01-01 00:00:19.710 148 162 V BackupManagerService: PackageInfo{41a80190 com.android.vending} agent=com.android.vending.VendingBackupAgent uid=10042 killAfterRestore=false 01-01 00:00:19.710 148 162 V BackupManagerService: PackageInfo{41ac2980 com.google.android.calendar} agent=com.android.calendar.CalendarBackupAgent uid=10007 killAfterRestore=true 01-01 00:00:19.710 148 162 V BackupManagerService: PackageInfo{41b14fb8 com.google.android.gm} agent=com.google.android.gm.persistence.GmailBackupAgent uid=10020 killAfterRestore=true 01-01 00:00:19.710 148 162 V BackupManagerService: PackageInfo{41af89b8 com.google.android.inputmethod.latin} agent=com.android.inputmethod.latin.BackupAgent uid=10028 killAfterRestore=false and 01-01 00:00:20.000 148 162 D BackupManagerService: Now awaiting backup for 1 participants: 01-01 00:00:20.000 148 162 D BackupManagerService: + BackupRequest{app=ApplicationInfo{41b15110 android}} agent=com.android.server.SystemBackupAgent 01-01 00:00:20.000 148 162 I BackupManagerService: New app com.android.browser never backed up; scheduling 01-01 00:00:20.015 148 162 D BackupManagerService: Now awaiting backup for 2 participants: 01-01 00:00:20.015 148 162 D BackupManagerService: + BackupRequest{app=ApplicationInfo{41b15110 android}} agent=com.android.server.SystemBackupAgent 01-01 00:00:20.015 148 162 D BackupManagerService: + BackupRequest{app=ApplicationInfo{41ae5cf8 com.android.browser}} agent=com.android.browser.BrowserBackupAgent 01-01 00:00:20.015 148 162 I BackupManagerService: New app com.android.nfc3 never backed up; scheduling 01-01 00:00:20.031 148 162 D BackupManagerService: Now awaiting backup for 3 participants: 01-01 00:00:20.031 148 162 D BackupManagerService: + BackupRequest{app=ApplicationInfo{41b15110 android}} agent=com.android.server.SystemBackupAgent 01-01 00:00:20.031 148 162 D BackupManagerService: + BackupRequest{app=ApplicationInfo{41ae5cf8 com.android.browser}} agent=com.android.browser.BrowserBackupAgent 01-01 00:00:20.031 148 162 D BackupManagerService: + BackupRequest{app=ApplicationInfo{41a47d88 com.android.nfc3}} agent=com.android.nfc.NfcBackupAgent ... [N times] and various other overly-chatty messages that aren't useful for the midrange debugging needs of early testing. Bug 5104300 Change-Id: I2b2afb5ba68059cb1f4cccc07f2833e43cd6fe94
* Require the current backup pw in all backup/restore operationsChristopher Tate2011-07-281-19/+42
| | | | | | | | | Specifically, we now also require the current password to confirm any restore operation. Bug 4901637 Change-Id: I39ecce7837f70cd05778cb7e0e6390ad8f6fe3f3
* Support full-backup encryption and global backup passwordChristopher Tate2011-07-281-152/+594
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the user has supplied a backup password in Settings, that password is validated during the full backup process and is used as an encryption key for encoding the backed-up data itself. This is the fundamental mechanism whereby users can secure their data even against malicious parties getting physical unlocked access to their device. Technically the user-supplied password is not used as the encryption key for the backed-up data itself. What is actually done is that a random key is generated to use as the raw encryption key. THAT key, in turn, is encrypted with the user-supplied password (after random salting and key expansion with PBKDF2). The encrypted master key and a checksum are stored in the backup header. At restore time, the user supplies their password, which allows the system to decrypt the master key, which in turn allows the decryption of the backup data itself. The checksum is part of the archive in order to permit validation of the user-supplied password. The checksum is the result of running the user-supplied password through PBKDF2 with a randomly selected salt. At restore time, the proposed password is run through PBKDF2 with the salt described by the archive header. If the result does not match the archive's stated checksum, then the user has supplied the wrong decryption password. Also, suppress backup consideration for a few packages whose data is either nonexistent or inapplicable across devices or factory reset operations. Bug 4901637 Change-Id: Id0cc9d0fdfc046602b129f273d48e23b7a14df36
* Support for compressed backupsChristopher Tate2011-07-151-5/+86
| | | | | | | | | | | | The backup format now includes a stream header. That header begins with a magic string and version number, then includes a flag stating whether the archive data is compressed, and then in the case of encrypted archives states the password salt used during encryption key stretching. When compression is used, everything following the header is run through a standard zlib "deflate" compressor before being sent downstream. Change-Id: Ica72753e4ef2c3d13e63b45e7722a00652940a55
* Compress the backup output streamChristopher Tate2011-07-131-21/+113
| | | | | | | | | | Zlib compression, with a full flush between each application's data. Encryption will be performed on the already-compressed data once that's implemented. On restore, the streamed data is similarly uncompressed on the fly. Change-Id: I19b65c88e759a66527d10913d18fffa9df0bc011
* Can now restore a subset of apps from historical datasetChristopher Tate2011-07-081-3/+105
| | | | | | | | | | | 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
* Make full backup API available to appsChristopher Tate2011-07-061-24/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | New methods for full backup/restore have been added to BackupAgent (still hidden): onFullBackup() and onRestoreFile(). The former is the entry point for a full app backup to adb/socket/etc: the app then writes all of its files, entire, to the output. During restore, the latter new callback is invoked, once for each file being restored. The full backup/restore interface does not use the previously-defined BackupDataInput / BackupDataOutput classes, because those classes provide an API designed for incremental key/value data structuring. Instead, a new FullBackupDataOutput class has been introduced, through which we restrict apps' abilities to write data during a full backup operation to *only* writing entire on-disk files via a new BackupAgent method called fullBackupFile(). "FullBackupAgent" exists now solely as a concrete shell class that can be instantiated in the case of apps that do not have their own BackupAgent implementations. Along with the API change, responsibility for backing up the .apk file and OBB container has been moved into the framework rather than have the application side of the transaction do it. Change-Id: I12849b06b1a6e4c44d080587c1e9828a52b70dae
* Fix handling of directory entriesChristopher Tate2011-06-081-14/+42
| | | | | | | | | | | Don't emit tar blocks for directories with an invalid nonzero size. Also, if such an entry is encountered during restore, don't actually attempt to treat it as valid and thus skip over the next actual tar entry. This patch also adds tracking of the data actually consumed during restore, and reports a total at the end of stream. Change-Id: I625173f76df3c007e899209101ff2b587841f184
* Fix embedded spaces in tar stream EVEN HARDERChristopher Tate2011-06-071-2/+3
| | | | Change-Id: I97ac586ff3541a05d73e1e53f680517c15e6c662
* Implement shared-storage full backup/restoreChristopher Tate2011-06-071-65/+107
| | | | | | | | | | | | | Every available shared-storage volume is backed up, tagged with its ordinal in the set of mounted shared volumes. This is an approximation of "internal + the external card". This lets us restore things to the same volume [or "equivalent" volume, in the case of a cross-model restore] as they originated on. Also fixed a bug in the handling of files/dirs with spaces in their names. Change-Id: I380019da8d0bb5b3699bd7c11eeff621a88e78c3
* Respect android:allowBackup="false" during full backup & restoreChristopher Tate2011-06-031-21/+118
| | | | | | | | | | | | | | | | Packages with this manifest attribute set 'false' will not be backed up even through the "full device backup" infrastructure. If someone produces an apparent restore file with data for such an application, it will not actually be restored onto the device. When an apk is installed during the course of a restore operation, it is validated against the manifest contents and deleted if there is a mismatch. Also, if the newly-installed app is found to disallow backups, no file content will be processed for that app. Bug 4532159 Change-Id: I59630054584b1394e567de939192e22e597044ee
* Restore from a previous full backup's tarfileChristopher Tate2011-06-011-21/+987
| | | | | | | | | | | | | | | | | | | Usage: adb restore [tarfilename] Restores app data [and installs the apps if necessary from the backup file] captured in a previous invocation of 'adb backup'. The user must explicitly acknowledge the action on-device before it is allowed to proceed; this prevents any "invisible" pushes of content from the host to the device. Known issues: * The settings databases and wallpaper are saved/restored, but lots of other system state is not yet captured in the full backup. This means that for practical purposes this is usable for 3rd party apps at present but not for full-system cloning/imaging. Change-Id: I0c748b645845e7c9178e30bf142857861a64efd3
* FileOutputStream guarantees to open O_TRUNC (unless you explicitly ask ↵Elliott Hughes2011-05-271-3/+0
| | | | | | otherwise). Change-Id: Ibd2f247d8e52b2814729c93442ae197c186660f6
* Full backup tweaksChristopher Tate2011-05-131-7/+6
| | | | | | | | * provide placeholder UI showing backup/restore start/stop/timeout * don't kill the progress UI in mid stream * tidy up the pax extended header data writing a little Change-Id: Ife0cb78e3facb541d8327f1d5ca5fe77faa6cbca
* Full local backup infrastructureChristopher Tate2011-05-101-25/+471
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix deadlock in BackupManagerServiceChristopher Tate2011-04-041-8/+8
| | | | | | | | | | Lock ordering bug. The fix is to avoid having to hold both locks simultaneously in one prong of the deadlock. (Further strengthening: the code path for potentially acquiring both simultaneously now begins at a common method, ensuring that lock ordering is always consistent.) Change-Id: If9433aff8326fec2ba0e97e96ad2d835b01e2cda
* Don't spuriously time out restore sessionsChristopher Tate2011-03-031-0/+4
| | | | | | | | | | | If a restore set lookup took a long time, the client's restore session could be declared timed out even though the client was not at fault. Handle this properly by resetting the timeout clock when control of the session is returned to the client. Bug 3477324 Change-Id: I43afaf1063e8e706ef16b70be77f9eeeea6a321f
* Merge "Print currentDestinationString() for each backup transport" into ↵Fabrice Di Meglio2011-01-131-3/+15
|\ | | | | | | honeycomb
| * Print currentDestinationString() for each backup transportFabrice Di Meglio2011-01-131-3/+15
| | | | | | | | | | | | when doing a "adb shell dumpsys backup" Change-Id: I9a7d080ad50b715f693f3e16cae3d6e5b1189d47
* | Revert "Remove the APIs for the old encryption scheme."Jason parks2011-01-131-13/+8
| | | | | | | | This reverts commit 1125d780a8b61703b8eb28c5c77dac5f3f0022dd.
* | Merge "Remove the APIs for the old encryption scheme." into honeycombJason parks2011-01-131-8/+13
|\ \
| * | Remove the APIs for the old encryption scheme.Jason parks2011-01-121-8/+13
| |/ | | | | | | Change-Id: I55116a5b29b10dfd50015805ec019b485257f68b
* / Turn off debugging logspam for releaseChristopher Tate2011-01-121-1/+1
|/ | | | | | Fixes bug 2679101 Change-Id: I94cf1b1d0b732b2030008118eff3534f0e0608f7
* Don't queue multiple pending backups for the same appChristopher Tate2010-12-141-22/+43
| | | | | | | | | | | | | | Repeated install/replace of an app before it ran its first backup pass would wind up enqueueing multiple backup requests, all of which would run back to back when the time came. This no longer happens. Also, if a backup request is queued for an app that is then uninstalled before that request is honored, we no longer fail in expensive and log- intensive ways; we now fail cleanly, early. Bug 3133212 Change-Id: I745f5b2f966a1c874f34a0107a438ad42fa7f005
* Time out orphaned / unresponsive restore sessionsChristopher Tate2010-12-131-18/+81
| | | | | | | | | | | | | | | | | | An app that fires up a restore session but then crashes or drops its session reference will currently render restore functions totally unavailable until the device is rebooted. This CL introduces an inactivity timeout [currently 60 seconds] on restore sessions, after which the session is shut down and becomes unavailable to the app who nominally still held it. Synchronization between the timeout and the normal asynchronous use of the session by the application is managed by running both the timeout action and the normal teardown process on the backup manager service's handler thread. Bug 3276362 Change-Id: I1f63b83e96e66b0e7eb15a1e20e375049babf06e
* Add a couple of transport-descriptive methods to IBackupManagerChristopher Tate2010-12-091-0/+49
| | | | | | | | | | | | | | | | Privileged callers can now ask the transport for a string describing its current state, and for an Intent that can be passed to startActivity() in order to bring up its exported configuration UI. These will be used in Settings in order to e.g. show the user the currently active account being used for backup, and allow the user to choose an account. The data being funnelled through IBackupManager here are the ones already exposed by the transports in their implementation of the IBackupTransport interface. Bug: 2753632 Change-Id: I2227a2b111d8d0ddf221d63020e20c1316fff55b
* Ensure that the first post-restore backup pass is correctChris Tate2010-11-291-10/+29
| | | | | | | | | | | | | | | | | | Some restore passes bring an ancestral dataset to the application, but others instead act to bring an app back into sync with its own most- recently-saved data. In the latter case the state file written by the app after the restore is a correct basis for generating future backup deltas, but in the former case it is not. The app should not be required to distinguish between these cases; the framework has all the information necessary to handle the saved state correctly following any flavor of restore operation. This patch makes the Backup Manager properly cause a full backup pass following an ancestral-dataset restore. After a current-set restore the saved state file is an accurate description for purposes of continued backup operations, so is preserved. Change-Id: I5982f32c9bb17fb7c953b465673ced11c40b0d95
* Permission fix: don't require BACKUP perm for self-restoresChris Tate2010-11-161-9/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Close some things in system_server that CloseGuard found.Brad Fitzpatrick2010-11-151-0/+1
| | | | Change-Id: I788c022235caddcb1972a34131442a683cd51eb5
* resolved conflicts for merge of 368fdba4 to masterBrad Fitzpatrick2010-10-211-2/+2
|\ | | | | | | Change-Id: I42b7b433c86a71a5da5db67109f056a280077c9d
| * Reduce logging.Joe Onorato2010-10-191-2/+2
| | | | | | | | | | | | | | | | | | | | Remember, the system and main logs are - Shared resources - Primarily for recording problems - To be used only for large grained events during normal operation Bug: 3104855 Change-Id: I136fbd101917dcbc8ebc3f96f276426b48bde7b7
| * DO NOT MERGE. Turn down backup logging for release.Chris Tate2010-10-191-1/+1
|/ | | | Change-Id: Ib9f4fd15981fcf52b5d5912995c1891836303427
* Temporarily turn on backup/restore debug logsChris Tate2010-10-111-1/+1
| | | | | | | Several people are seeing odd behaviors around backup/restore at present. Enable expanded logging to help pin down exactly what is happening. Change-Id: I95ca013017cb07e633f2ba765583de3cf0e056af
* Track client requests through location manager.Dianne Hackborn2010-09-131-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a problem where applications could ask the location manager to do very heavy-weight things (like... say... update location every minute), which would get accounted against the system instead of the application because ultimately it is the system making the heavy calls (wake locks, etc). To solve this, we introduce a new class WorkSource representing the source of some work. Wake locks and Wifi locks allow you to set the source to use (but only if you are system code and thus can get the permission to do so), which is what will be reported to the battery stats until the actual caller. For the initial implementation, the location manager keeps track of all clients requesting periodic updates, and tells its providers about them as a WorkSource param when setting their min update time. The network location provider uses this to set the source on the wake and wifi locks it acquires, when doing work because of the update period. This should also be used elsewhere, such as in the GPS provider, but this is a good start. Change-Id: I2b6ffafad9e90ecf15d7c502e2db675fd52ae3cf
* Don't block in the BackupManagerService.dataChanged() Binder call.Brad Fitzpatrick2010-09-071-44/+72
| | | | | | | This unnecessarily blocks callers. Bug: 2977348 Change-Id: I5267e575cdd5eb2136379f9710126b62a1bd75ad
* am 5827d3ea: Merge "Properly note the current active restore set\'s token" ↵Dianne Hackborn2010-06-241-1/+1
|\ | | | | | | | | | | | | | | | | into froyo Merge commit '5827d3eaf3c53d1dc3ab0d638d935c219a5515a6' into gingerbread * commit '5827d3eaf3c53d1dc3ab0d638d935c219a5515a6': Properly note the current active restore set's token
| * Properly note the current active restore set's tokenChristopher Tate2010-06-241-1/+1
| | | | | | | | | | Bug: 2796780 Change-Id: Iad601ed96ae73cf34910a276350712e6af19bb4e
* | Some ActivityThread/ActivityManager cleanup.Dianne Hackborn2010-06-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | - Move PackageInfo out of ActivityThread, renaming to LoadedApk. - Rename some of the other PacakgeInfo inner classes to better represent what they are. - Rename HistoryRecord to ActivityRecord. - Introduce AppGlobals, to eventually let ActivityThread become package scoped. Change-Id: Ib714c54ceb3cdbb525dce3db9505f31042e88cf0
* | am 7e93aad4: am 36fa4713: Merge "Fix security hole in Google backup ↵Christopher Tate2010-04-211-4/+19
|\| | | | | | | | | | | | | | | | | transport registration" into froyo Merge commit '7e93aad42d5f96e4e3a471e49384e1ce794c9411' into kraken * commit '7e93aad42d5f96e4e3a471e49384e1ce794c9411': Fix security hole in Google backup transport registration
| * Fix security hole in Google backup transport registrationChristopher Tate2010-04-211-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, it was conceivable that a 3rd party application on a non-GED device could publish a service that supported the (hidden) IBackupTransport interface and spoofed the Google backup transport's package and component name. This could allow it to secretly intercept all data moved through the backup mechanism. Fix by ensuring that the package in question exists and is part of the OS itself (FLAG_SYSTEM in its ApplicationInfo description) before binding to it. Fixes bug #2457063 Change-Id: I3487572be45c2014fa209beacfe3ac6f8270f872
* | am 11f759cf: am 5923c971: Fix \'dumpsys backup\'Christopher Tate2010-04-041-2/+4
|\| | | | | | | | | | | | | Merge commit '11f759cf9a2b585c57adf4833ba706fd94e06571' into kraken * commit '11f759cf9a2b585c57adf4833ba706fd94e06571': Fix 'dumpsys backup'
| * Fix 'dumpsys backup'Christopher Tate2010-04-041-2/+4
| | | | | | | | | | | | "for (Type foo : mSetOfType)" doesn't work when mSetOfType is null. Change-Id: Iac667c7309f99b12d3147830e166b542b29cba5f
* | am b3f7fe44: am 22375e4a: Merge "Make ↵Christopher Tate2010-03-301-10/+58
|\| | | | | | | | | | | | | | | | | RestoreSession.getAvailableRestoreSets() asynchronous" into froyo Merge commit 'b3f7fe44f5a3a6a4c04d4102eb61f29edf83129c' into kraken * commit 'b3f7fe44f5a3a6a4c04d4102eb61f29edf83129c': Make RestoreSession.getAvailableRestoreSets() asynchronous
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-13 13:52:37 +0000