summaryrefslogtreecommitdiffstats
path: root/services/java/com/android/server/BackupManagerService.java
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Fix 'dumpsys backup'Christopher Tate2010-04-041-2/+4
| | | | | | "for (Type foo : mSetOfType)" doesn't work when mSetOfType is null. Change-Id: Iac667c7309f99b12d3147830e166b542b29cba5f
* Make RestoreSession.getAvailableRestoreSets() asynchronousChristopher Tate2010-03-301-10/+58
| | | | | | | | | | | | | This transaction can involve the transport having to query a remote backend over the wire, so it can take a Long Time(tm). Make it main-thread-safe by making it asynchronous, with the results passed as a callback to the invoker's RestoreObserver. We also make the IRestoreObserver callback interface properly oneway. Bug #2550665 Bug #2549422 Change-Id: If18a233a0a3d54c7b55101715c9e6195b762c5a0
* DO NOT MERGEOscar Montemayor2010-03-291-1/+1
| | | | | | | Removing unused features from source tree. Please refer to Bug#2502219. Change-Id: I879c29bfd5ffe933f64bb1082aaae7c956450a5a
* API CHANGE: Backup/restore API changes requested by the API CouncilChristopher Tate2010-03-261-1/+1
| | | | | | | | | | | | | | | * @hide the android.app.backup.RestoreSession class and functionality * Provide a public method on android.app.backup.BackupManager that apps can use to request a restore pass of their last-known-good dataset. The new method is called requestRestore(). * Provide the name of the package being restored, not just its ordinal, in the RestoreObserver's onUpdate() callback. Part of bug #2545514 Change-Id: I9689bf8d6e2b808b4ee412424a36a835be0a5ca8
* API CHANGE: expose the backup-related ApplicationInfo flag masksChristopher Tate2010-03-121-11/+2
| | | | | | | | | | | | | | | | | | | | | | | Fixes bug #2507582 by doing the following: - Un-@hide the FLAG_ALLOW_BACKUP, FLAG_KILL_AFTER_RESTORE, and FLAG_RESTORE_ANY_VERSION mask constants in ApplicationInfo. These correspond, respectively, to the <application> manifest tag's android:allowBackup, android:killAfterRestore, and android:restoreAnyVersion attributes. - Remove the android:restoreNeedsApplication attribute and the corresponding FLAG_RESTORE_NEEDS_APPLICATION constant [which was still marked @hide]. We now always use the application's own Application class when performing a normal restore. In the future when we support an externalized full-filesystem backup/restore operation, we will use an OS-defined agent class with a base-class Application instance, but this will not happen until a future release. Also expands real documentation on the above ApplicationInfo constants; that work is part of bug #2465360 Change-Id: I735d07a963ae80a01343637d83bef84e4c23fdcc
* Refactor android.backup => android.app.backupChristopher Tate2010-03-051-7/+7
| | | | Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
* Switch the services library to using the new SlogJoe Onorato2010-03-011-137/+137
|
* Add single-package restore to Bmgr feature setChristopher Tate2010-02-261-0/+6
| | | | | | | | | Also sanity-check the package name on the Backup Manager side, failing gracefully if the given package is not a backup/restore participant. Bug: 2293977 Change-Id: I3575046ffcaa3cf45c1c602824baeadd64082f70
* Default the auto-restore setting to "enabled."Christopher Tate2010-02-251-1/+1
| | | | Change-Id: I7d8710466214a1b09aabdd71e77b9b34d3d62365
* Fix the buildChristopher Tate2010-02-251-1/+1
| | | | Change-Id: I41616afc75a3366ea7e9e79ac7ea4c46d1863d83
* Start respecting the auto-restore-at-install settingChristopher Tate2010-02-251-3/+4
| | | | Change-Id: I420ff6b4ba72f87bee56f45d8906f086f7a2b114
* Add 'restoreAnyVersion' attr for apps that want to restore "future" dataChristopher Tate2010-02-241-7/+20
| | | | | | | | | | | | | | | | | | | | | | | If a backup-participating app sets android:restoreAnyVersion="true" in its manifest <application> tag, then its agent will be invoked for restore even if the available dataset was created by a later version of the app than is currently installed on the device. This will not typically be a problem for third party applications, since for them the installation and initial data restore are tightly coupled, but it can cause serious problems for applications which are both preinstalled on the system partition and overridden by later updates. The primary difficulty that this new attribute addresses is this: 1. User buys a Nexus One, Market self-updates, and the user installs some apps. At this point the backup data on the server may indicate that the version of Market which originated its bookkeeping is newer than the stock N1 Market app. 2. User loses their phone, and buys a replacement N1. At setup time, Market has not yet had a chance to self-update, so when the restore comes in, it's tagged as being from "the future" and so the restore is refused. No apps get reinstalled. Bug: 2442127 Change-Id: I076a9553dc613e5c3189350e778315718ed1ed2b
* Automatically restore app data at install timeChristopher Tate2010-02-191-33/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an application being installed defines a backupAgent in its manifest, we now automatically perform a restore of the latest-known-good data for that app. This is defined as "data backed up by this app from this handset, if available; otherwise data for this app as it existed when the device was initially provisioned." If neither option exists for the app, no restore action is taken. The CL involves major changes in the Backup and Package Managers... * The Package Manager's act of installing an application has now been split into two separate phases, with a data-restore phase optionally occurring between these two PM actions. First, the details of the install are performed as usual. Instead of immediately notifying install observers and issuing the install-related broadcasts, the in-process install state is snapshotted and the backup manager notified that a restore operation should be attempted. It does this by calling a new API on IBackupManager, passing a token by which it identifies its in-progress install state. The backup manager then downloads [if possible] the data for the newly-installed application and invokes the app's backupAgent to do the restore. After this step, regardless of failure, it then calls back into the Package Manager to indicate that the restore phase has been completed, supplying the token that was passed in the original notification from the Package Manager. The Package Manager then runs the final post-install actions: notifying install observers and sending out all the appropriate broadcasts. It's only at this point that the app becomes visible to the Launcher and the rest of the OS. ... and a few other bits and pieces... * The ApplicationInfo.backupAgentName field has been exposed to the SDK. This can be reverted if there's a reason to do so, but it wasn't clear that this info needs to be hidden from 3rd party apps. * Debug logging of restore set IDs and operation timeout tokens [used during any asynchronous Backup Manager operation] are now consistently in hex for readability. * We now properly reset our binder identity before calling into the transport during restore-set operations. This fixes a permissions failure when a single-app restore was attempted. * The 'BackupTest' test app is no longer lumped onto the system partition by default. Change-Id: If3addefb846791f327e2a221de97c8d5d20ee7b3
* Tone down a non-error log message about lack of ancestral dataset trackingChristopher Tate2010-02-171-0/+4
| | | | Change-Id: I2e5e48c9b695d6225016365907fe8edc73ab2c8e
* API CHANGE: expose backup/restore to the SDKChristopher Tate2010-02-161-8/+0
| | | | | | | | | | | | | | The core backup/restore classes [BackupManager, BackupAgent, RestoreSession, and RestoreObserver] are now published for 3rd party developers, as well as the suite of helper classes that exist so far to aid authorship of backup/restore agents. In conjunction with the API change, the restore-time automatic data wipe has now been removed: applications are responsible for managing the logic of wipe vs merge themselves. If the app's agent onRestore() callback throws, the data is presumed to be incoherent and a wipe is issued via the Activity Manager; otherwise, no automatic action is ever taken. Change-Id: I0b3418b829d4689b58b88be3d9c4ace37a8583a9
* Remove BACKUP_DATA permission and associated checksChristopher Tate2010-02-121-18/+1
| | | | | | | | Any package can now participate in backup/restore, without requiring any manifest-declared permission. *Control* of the backup manager is still guarded by the BACKUP permission, which is signatureOrSystem. Change-Id: I116fcfcd4cd255e3c976330da1c4dea7d4faae9d
* Remember which apps have available restore info in the ancestral datasetChristopher Tate2010-02-081-6/+49
| | | | | | | | | When we perform a full-system restore, remember the set of applications which have data available in our ancestral dataset. This is a key filter for not having to do a round trip to the [remote] storage backend at app-install time unless it is likely to be fruitful. Change-Id: I7c77b490c560c581888d84f02f258b2e2d73bc69
* Rename media resource broadcastsSuchi Amalapurapu2010-02-081-4/+4
| | | | | | Add checks for fwdlocked and updated system apps add more tests remove duplicate adds
* Don't hold the backup queue lock across a backup operationChristopher Tate2010-02-051-11/+16
| | | | | | | | | | | This got lost in the shuffle when the backup process was retooled to run synchronously within a single spun-off HandlerThread. Formerly it was okay to hold the lock around the point in time when the backup service thread was being spun off, but once that became synchronous it wound up locking out apps' calls to dataChanged(), which in turn led to ANRs. Bug: 2421333 Change-Id: Icf378e5733af5f28a689c564494486cd3555eca7
* Add single-package restore from an app's most-recent dataChristopher Tate2010-02-041-9/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Renamed the RestoreSession performRestore() method to restoreAll(), and added a new restorePackage() method that only restores the single specified app. In order to restore an app other than itself, the caller must hold the android.permission.BACKUP permission. This change also introduces dataset tracking: the Backup Manager persistently remembers both the current backup dataset's identity and that of the "ancestral" dataset, i.e. the one most recently used for a whole-device restore such as performed by SetupWizard. When a single package is restored via restorePackage(), the selection of most-recent dataset to use is this: 1. The data from the currently-active backup dataset, if such exists. An app that has ever backed up data will therefore get its last- known-good data. 2. The app's data from the ancestral dataset, if such exists. This covers the case of a factory reset followed by reinstallation of an app at a later time. The app had not yet backed anything up post-wipe, but the old data is in the ancestral dataset and should be brought forward when the app reappears. 3. If neither 1. nor 2. exist, there is no data to restore, so just skip it and return failure. Note that the infrastructure to automatically attempt a restore after an application has been installed does not yet exist; that's coming. Change-Id: I0ba170df9885128000c46ed28d3dddda3a63a143
* Add auto-restore setting and Backup Manager awareness thereofChristopher Tate2010-02-031-0/+17
| | | | | | | | This setting, like BACKUP_ENABLE, should never be set directly in the secure settings database. Instead, it should be manipulated through the new IBackupManager method setAutoRestore(boolean). Change-Id: I5c3226ca85b6148bb756d753d7f9e4ea76e878c4
* Apps on sdcard: Add new broadcastsSuchi Amalapurapu2010-02-021-20/+43
| | | | | | | | | | | | | Add new broadcasts ACTION_MEDIA_RESOURCES_AVAILABLE and ACTION_MEDIA_RESOURCES_UNAVAILABLE that get broadcast by PackageManagerService when sdcard gets mounted/unmounted by MountService so that packages on sdcard get recognized by various system services as being installed/available or removed/unavailable by the system. The broadcasts are sent before the actual package cleanup which includes mounting/unmounting the packages and we force a gc right after so that any lingering file references to resources on sdcard get released.
* Get rid of now-superfluous "backup or restore in progress" trackingChristopher Tate2010-02-021-45/+8
| | | | | | | Now that backup/restore/etc operations are queued and serialized, we no longer need to use external state tracking to prevent overlapping operations. Change-Id: I14f2a5d740cb97ae062aad55a06f49a2be5dd985
* Don't crash on transport unregistration if there is no current transportChristopher Tate2010-01-291-1/+1
| | | | Change-Id: Icd0962254ba224a7be27d408dffb25b634f67863
* Make backup/restore asynchronous and enforce timeoutsChristopher Tate2010-01-291-106/+207
| | | | | | | | | | | | | | | | | | Callouts to app backup agents are now asynchronous, and timeouts are applied if they take too long, hang, etc. The initial timeouts are set to 15 seconds on backup, 60 seconds on restore. These operations typically run at background priority, so it's necessary to give them ample time to run. As part of setting up this asynchronicity, the Backup Manager's internal thread management has been overhauled. It now spins off a single HandlerThread at startup, and runs backup/restore/etc operations *synchronously* in that thread, applying timeouts as appropriate. This means we're no longer spinning up new threads all the time, and furthermore it ensures that we can never have more than one operation in flight at once. Later CLs will remove the now-redundant logic that previously ensured that operations didn't stomp on each other. Bug: 2053560 Change-Id: Ie4315c219c7ff6dd8f51f2ad6c0872595b18cff1
* Move towards a formal public API for backup and restoreChristopher Tate2010-01-251-4/+4
| | | | | | | | | | | | | | This commit makes a few changes towards establishing a formal application interface for interacting with the backup/restore mechanism: 1. Introduce public wrapper classes around the various binder interfaces; 3rd party code will never see the binders directly. 2. Progress update callbacks during a restore sequence now occur on the main thread, not in a binder thread [and not with system-process permissions!]. 3. Rename the BackupManagerService's inner "RestoreSession" class to avoid ambiguity with the new public "RestoreSession" class.
* Don't crash the system process when a backup transport unregistersChristopher Tate2009-12-221-2/+12
| | | | Bug: 2342503
* resolved conflicts for merge of 5a2fdbba to masterDoug Zongker2009-12-071-48/+32
|\
| * move event log tags used by system server into this packageDoug Zongker2009-12-041-48/+32
| | | | | | | | | | | | We can now locate event log tag definitions in individual packages (and java constants for the tag numbers get auto-generated), so move all the tags used by the system server into the package.
* | Encrypted File Systems Project. Installer modifications.Oscar Montemayor2009-11-241-12/+12
|/ | | | Started to modify isntaller for data redirection to a secure location.
* Fix #2176803 - restores from userdebug to user builds not workingChristopher Tate2009-11-041-2/+13
| | | | | | | | | | | | | | | | | | | | | The underlying issue is that ordinarily, the restore mechanism checks the signature block of the package which uploaded the restore data against the signature of the package on-device that will be handling the restore. This is to ensure that the restore goes to the "same" application as the one that uploaded it. However, applications bundled on the system partition as part of the device build are signed not with a permanent, app-identifying signature, but rather with the device's signature block, which is different for each kind of device and potentially between kinds of build for the same device. That renders the stored backup data unusable when changing devices / builds / etc. This change works around the problem by explicitly privileging applications that reside on the system partition: they have been built into the device, and so are trusted to be able to handle data that is marked as coming from its package name. Change-Id: I561011bce2b54cff3e695e82e7544b126b6ac31e
* Use setRepeating() rather than setInexactRepeating() for backup scheduling,Dan Egnor2009-10-301-3/+13
| | | | | | | and add some random fuzz to the scheduling times, to make sure we aren't creating hour-aligned server load spikes. See bug 2226553 for details & Dr. No information.
* Turn off the last of the STOPSHIP verbose debuggingChristopher Tate2009-09-301-3/+3
| | | | Change-Id: Id93f4c9e9fb8468a554ae1e5c5c767f72903662c
* Only re-initialize backup state if @pm@ metadata is missing,Dan Egnor2009-09-301-180/+147
| | | | | | | | | | | | to defensively work around a still-mysterious bug where the list of saved packages ends up being empty even though we still have state pending. If we do re-initialize, then wipe all state to make sure the right thing happens. Don't keep open journal files -- close them after every update. A bit less efficient, but possibly more reliable (again, this is defensive programming here). Also change "rwd" to "rws" mode for fully synchronous operation.
* Better event log tracking for initializeDevice() requests --Dan Egnor2009-09-291-23/+23
| | | | | | | | on success, record "backup_initialize" event; on failure, record "backup_transport_failure" event (and add tags to "backup_transport_failure" events that aren't associated with a particular package -- namely "(initialize)" and "(finish)").
* Add more useful-for-debug info to 'dumpsys backup'Christopher Tate2009-09-291-5/+26
| | | | Change-Id: I52e20bac01ff63feaf28920a79311881992293a3
* Don't forget to clear "backup in progress" state when finishing a passChristopher Tate2009-09-271-0/+9
| | | | | | | | | | | If a backup pass had been skipped (either because the transport was unavailable or -- in a common case! -- because there was simply no work pending when the periodic backup check fired), we were forgetting to reset the "backup currently in progress" flag. Once we'd done that, the device would *NEVER* perform a backup until it was rebooted, since it would forever think that there was one currently in operation that must not be interfered with. Change-Id: I0d6d7375dc6de99b599222a449934e70fe13ebb9
* Disallow concurrent backups; consult transport requestBackupTime()Christopher Tate2009-09-241-14/+44
| | | | | | | | | | | | | | | * We now check for in-progress backups when asked to perform one, and don't bother firing off another one concurrently (nor do we adjust the scheduling; after all, someone asked to do a backup "now" and we're doing one, so we are in line with expectations). We also defer backup passes while a restore is in flight, and abort attempts to perform a restore during a backup pass. * When a backup attempt fails, we now ask the transport how far in the future we should put our retry. Previously we were simply not bothering to consult with the transport, so we would wind up retrying backup while network connectivity was known to be down, etc. Change-Id: Ic7758010b74e06e90c50d46b7b0dd01b17af7c90
* Clear the device's data from the transport when backup is disabledChristopher Tate2009-09-241-18/+236
| | | | | | | | | | | | | | | | Turning off backup in the Settings UI constitutes an opt-out of the whole mechanism. For privacy reasons we instruct the backend to wipe all of the data belonging to this device when the user does this. If the attempt fails it is rescheduled in the future based on the transport's requestBackupTime() suggestion. If network connectivity changes prompt the transport to indicate a backup pass is appropriate "now," any pending init operation is processed before the backup schedule is resumed. The broadcasts used internally to the backup manager are now fully protected; third party apps can neither send nor receive them. (Also a minor logging change; don't log 'appropriate' EOF encountered during parsing of a backup data stream.)
* If backup fails, reenqueue all of the affected packages for next time.Christopher Tate2009-09-221-6/+25
|
* Add parameter for the restore set (device id) data is being restored from to ↵Dan Egnor2009-09-221-1/+1
| | | | the restore_start event
* Make IBackupTransport.finishBackup() also return an int code, since it too canDan Egnor2009-09-211-63/+70
| | | | | | | | | | | | | | | | | | | | | | return TRANSPORT_NOT_INITIALIZED (in fact that's typically how it comes). For consistency, make other IBackupTransport methods return int instead of boolean, and handle accordingly. Make initializeDevice() its own method instead of a flag on performBackup(). This will be needed when un-checking the settings box anyway, and is conceptually unrelated to whatever happens to be the first post-initialization backup we perform. (Note that even if the init is sent separately from the backup operation, the server will remember that an init has been done and will *not* return NOT_INITIALIZED for the subsequent backup.) Fix LocalTransport accordingly (trivial changes). Handle failures more robustly in BackupManagerService -- most notably, doQueuedBackups() was ignoring the result code of processOneBackup(), so a NOT_INITIALIZED error would go past unseen (at least until the next backup pass). Keep track of error code returns more universally now. (This includes finishBackup(), of course.)
* Reset backup tracking in response to transport data-wipe notificationChristopher Tate2009-09-211-6/+70
| | | | | | | | | | | When attempting a backup, the transport may inform us that the backend is in an uninitialized state. This typically means that the device's data has been wiped after a period [e.g. 90 days] of inactivity. This means that we need to re-store all data subject to backup, and all of our incremental state tracking on the device is now stale. In response, we wipe all of our recorded backup state and restart the backup pass on all participants.
* Fix up the first-backup-ever trackingChristopher Tate2009-09-201-19/+24
| | | | | | | | | | | | | This changes a couple of bits of the Backup Manager's logic around first-backup-ever handling. First, it uses the same "what we've ever backed up" handling as the rest of the system for purposes of instructing the backend to do a wipe when the metadata is initialized for the device, instead of looking at the presence of the @pm@ file. Secondly, for the time being we won't be using the saved state produced by agents' doRestore() logic. Until the server is migrating each restored package's data over to the new dataset, this was resulting in the client holding an agent state blob for which no data existed on the server under this device's identity but which the device thought was fully up to date.
* Add an 'init everything' operation to the first backup passChristopher Tate2009-09-201-3/+16
| | | | | | | | | | | | | | IBackupTransport.performBackup() now takes a flag "wipeAllFirst", which if set will result in the entire restore set for the current device/account being wiped clean prior to the storage of the provided package. This ensures that a device on which backup has just been enabled will not confront potentially-stale information, nor will the restore set potentially contain mismatched data from orphaned packages. The Backup Manager has also been revised to pass this flag when first backing up its master metadata block (and never pass it thereafter unless something has caused the backup state tracking to be erased, e.g. the user has opted out of backup and then later re-enabled it).
* Inefficient but correct fix for 2122381: call finishBackup after every ↵Dan Egnor2009-09-171-1/+11
| | | | performBackup
* Be sure to include shared lib path info when dealing with agentsChristopher Tate2009-09-161-5/+15
| | | | | In particular, this ensures that on the client side the full classpath is known and used by the class loader during execution of the agent.
* Expand apps' control over the settings restore processChristopher Tate2009-09-011-4/+33
| | | | | | | | | | | | | | | | | | | Applications can now specify two more aspects of the restore process: whether they need to run with their own custom Application subclass rather than being launched in the usual restricted mode during restore, and whether it's okay for the backup manager to kill the app process once restore has completed. The new manifest attributes for these are, respectively, android:restoreNeedsApplication and android:killAfterRestore. If unspecified in the manifest, restoreNeedsApplication is false, and killAfterRestore is true. In order to support kill-after-restore cleanly, this change also adds a new system-process-only interface to the Activity Manager, which will schedule a "commit suicide" event on the target app's main thread looper. The framework backup agents have been given the appropriate new backup attributes as well.
* Backup participants must now hold the BACKUP_DATA permissionChristopher Tate2009-08-131-2/+21
| | | | | | | | Packages that do not use android.permission.BACKUP_DATA will neither be backed up nor restored. That permission is currently signature-only. In the future if access to the backup/restore infrastructure is made available to arbitrary 3rd party applications, the permission checks (and indeed, the permission itself) can simply be removed.
generated by cgit v1.1 at 2025-03-10 19:25:44 +0000