summaryrefslogtreecommitdiffstats
path: root/packages/BackupRestoreConfirmation
Commit message (Collapse)AuthorAgeFilesLines
* Import translations. DO NOT MERGEBaligh Uddin2013-09-031-4/+4
| | | | | Change-Id: Ieb610ced7d3f541bc238646988904ed1cb7cee7a Auto-generated-cl: translation import
* Import translations. DO NOT MERGEBaligh Uddin2013-08-282-0/+76
| | | | | Change-Id: I2d9b9480f24eed9e6ec962222d212bbfb1179cde Auto-generated-cl: translation import
* Import translations. DO NOT MERGEBaligh Uddin2013-08-268-0/+304
| | | | | Change-Id: I58312f6de5060de6fdf5815a304c3ba502b717ce Auto-generated-cl: translation import
* Import translations. DO NOT MERGEBaligh Uddin2013-08-1911-0/+418
| | | | | Change-Id: Ib755452de5a0757b20e644634a0cfbec59cdf235 Auto-generated-cl: translation import
* Import translations. DO NOT MERGEBaligh Uddin2013-08-0148-96/+96
| | | | | Change-Id: I400da658acf872787f81dc223a4c3cf40ceb2f50 Auto-generated-cl: translation import
* Import translations. DO NOT MERGEBaligh Uddin2013-07-101-2/+2
| | | | | Change-Id: I3560b16b347b71c61ad1f723d444dbd056ee0d8f Auto-generated-cl: translation import
* Some system apps are more system than othersChristopher Tate2013-06-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | "signatureOrSystem" permissions are no longer available to all apps residing en the /system partition. Instead, there is a new /system/priv-app directory, and only apps whose APKs are in that directory are allowed to use signatureOrSystem permissions without sharing the platform cert. This will reduce the surface area for possible exploits of system- bundled applications to try to gain access to permission-guarded operations. The ApplicationInfo.FLAG_SYSTEM flag continues to mean what it is says in the documentation: it indicates that the application apk was bundled on the /system partition. A new hidden flag FLAG_PRIVILEGED has been introduced that reflects the actual right to access these permissions. At some point the "system" permission category will be renamed to "privileged". Bug 8765951 Change-Id: I6f0fd9cdb9170e076dfc66d83ecea76f8dd7335d
* Import translations. DO NOT MERGEBaligh Uddin2013-04-221-1/+1
| | | | | Change-Id: I6ac969ffc6fbffeb262ec79b14a4155f2123d82d Auto-generated-cl: translation import
* Import translations. DO NOT MERGEBaligh Uddin2013-02-251-3/+3
| | | | | Change-Id: Ie31e6632a217b9b9c7c0ebb79b16747830370db1 Auto-generated-cl: translation import
* Import translations. DO NOT MERGEBaligh Uddin2012-11-271-1/+1
| | | | | Change-Id: I830962076909bd65156b0e56bc8b9a4f44b7b249 Auto-generated-cl: translation import
* Import translations. DO NOT MERGEBaligh Uddin2012-11-221-1/+1
| | | | | Change-Id: I2f901cb989904c4325c2064428e4b8b0b2225d06 Auto-generated-cl: translation import
* Import translations. DO NOT MERGEBaligh Uddin2012-10-031-2/+2
| | | | | Change-Id: Ied34352ea4e79b01a9b8549596a381fe08ee7e06 Auto-generated-cl: translation import
* Import translations. DO NOT MERGEBaligh Uddin2012-09-261-1/+1
| | | | | Change-Id: I8b0d4f8146956bb0569ec01ef0872ad0a7065f0c Auto-generated-cl: translation import
* Import translations. DO NOT MERGEBaligh Uddin2012-09-131-1/+1
| | | | | Change-Id: I819f42df4c6909d695e78420670d76919a497c06 Auto-generated-cl: translation import
* Import translations. DO NOT MERGEBaligh Uddin2012-08-281-5/+5
| | | | | Change-Id: I37cdf72141038d6677c0ffe3f1ef6f65bf6fd78a Auto-generated-cl: translation import
* Import translations. DO NOT MERGEYing Wang2012-08-011-2/+2
| | | | | Change-Id: I4036c81a0a932e366969e9e333bbe3c5d46a9cd8 Auto-generated-cl: translation import
* Import translations. DO NOT MERGEYing Wang2012-07-131-6/+6
| | | | | Change-Id: Iabb056f645a910f3fbaea1e51348c3bef385546e Auto-generated-cl: translation import
* Fix full backup/restore detection of encrypted devicesChristopher Tate2012-04-122-0/+2
| | | | | | | | | | | The confirmation UI did not request the needed permission, so was failing to communicate with the mount service; as a "safe" failure mode, it was assuming the device was encrypted. Fixed; now it presents the correct prompt text for the device's encryption state. Bug 5958195 Change-Id: Ic03db16673b89d3377e0362a09cf51bfb572d78b
* Import revised translations.Eric Fischer2011-11-292-5/+5
| | | | Change-Id: Ie43246df49b8f6ef3daef12e0d8fb5c2f573874e
* Import revised translations.Eric Fischer2011-11-023-2/+78
| | | | Change-Id: I71efb16f2c6b257dfd444728c7e56ada662e6f77
* Import revised translations.Eric Fischer2011-10-259-25/+15
| | | | Change-Id: I5db0a5df334833af2e2109123d05a9f76c745cf6
* Import revised translations.Eric Fischer2011-10-1846-1/+139
| | | | Change-Id: I83ab00ec220b7c0ba0d37e7f4c91e945e35aab39
* Require device encryption password to perform adb backup/restoreChristopher Tate2011-10-132-4/+40
| | | | | | | | | | | | | | This supersedes any backup-password that the user might supply. Per design, the device encryption password is also always used to encrypt the backup archive. The CL introduces two new strings, used for prompting the user for their device encryption password rather than their settings-defined "backup password" when confirming a full backup or restore operation. Bug 5382487 Change-Id: I0b03881b45437c944eaf636b6209278e1bba7a9f
* Import revised translations.Eric Fischer2011-10-073-5/+5
| | | | Change-Id: Id046f8008aef32a1b94b4fa5b57e2beb2f9f2e80
* Import revised translations.Eric Fischer2011-09-3041-574/+287
| | | | Change-Id: Ic8e228878fde375b90797c6e344fcb3114180f1d
* Import revised translations.Eric Fischer2011-09-2045-0/+602
| | | | Change-Id: I5e375bebc8f74d9108a929246f16608427ce9317
* Use string resources instead of inline literals for progress toastsChristopher Tate2011-09-142-5/+16
| | | | | | ...in the full backup/restore confirmation UI. Change-Id: I858a2d7017450f016afe5052aa37161a1c89c281
* Give backup/restore confirmation a proper window titleChristopher Tate2011-09-134-2/+11
| | | | | | | | | | | | Since the confirmation uses the same Activity but different layouts for the backup vs restore cases, we have to do the title in code. Along the way, fix the restore layout's padding [the backup layout was already right]. Fixes bug 5164470 Change-Id: I4d636f666d97fc377e9cf36abf08d1625a05577f
* Import revised translations.Eric Fischer2011-09-121-4/+4
| | | | Change-Id: I6e7f33ff16557f7e9088c0aa66fd1c79ed376c75
* Import revised translations.Eric Fischer2011-09-024-6/+6
| | | | Change-Id: Iac73006cfaf846d210855496f6732cbdc6ad0de8
* Import revised translations.Eric Fischer2011-08-2641-5/+1165
| | | | Change-Id: I51e1fc94b7fa3fec13f7dddad62b978dd9a71d43
* Import revised translations.Eric Fischer2011-08-225-0/+145
| | | | Change-Id: I51335fa15a40d471010dbcc96e228b170f06ce7e
* Handle rotation gracefully in the backup/restore confirmation UIChristopher Tate2011-08-053-29/+67
| | | | | | | | | | | | | | We now don't automatically deny the operation if stopped, but instead allow the activity to be destroyed and recreated as usual. We retain the observer instance across that sequence so we keep getting progress reports etc. The UI now also uses the spiffy new button bar styles, and positions the deny / confirm buttons according to ICS standards. Bug 5115411 Change-Id: Ie760a0c8496c69f9d5881273a63ad5b5b76ff554
* Make backup/restore confirmation UI landscape-friendlyChristopher Tate2011-08-032-58/+100
| | | | | | | | | | | Now the textual content and password fields are placed in scroll view, and the confirm/deny buttons pinned at the bottom of the layout. Previously, in landscape mode on some devices the buttons would be pushed off screen. Bug 5115411 Change-Id: I8bf8fd1516735bf6111893df79636b519dbfb803
* Require the current backup pw in all backup/restore operationsChristopher Tate2011-07-284-23/+66
| | | | | | | | | 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-284-4/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Don't ack/nak backup redundantly at exitChristopher Tate2011-06-071-15/+16
| | | | Change-Id: I7293518bc2fe6c66270a7c8aea3bf0c0829754e4
* Respect android:allowBackup="false" during full backup & restoreChristopher Tate2011-06-031-1/+1
| | | | | | | | | | | | | | | | 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
* Filter backup/restore confirmation buttons when obscuredChristopher Tate2011-06-012-0/+2
| | | | | | | | | I.e. don't let people fake the user out by putting some other UI over the top of it in order to phish for a confirmation. Addresses bug 4521629 Change-Id: I40ae057ebedeb92ed264fb52fa1c7c297c9d3ec2
* Restore from a previous full backup's tarfileChristopher Tate2011-06-011-0/+2
| | | | | | | | | | | | | | | | | | | 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
* Full backup tweaksChristopher Tate2011-05-131-5/+7
| | | | | | | | * 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-106-0/+439
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
generated by cgit v1.1 at 2024-12-25 01:32:22 +0000