summaryrefslogtreecommitdiffstats
path: root/services/java/com/android/server/BackupManagerService.java
Commit message (Collapse)AuthorAgeFilesLines
* 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
| * 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
generated by cgit v1.1 at 2025-11-28 01:00:54 +0000