| d488bc0ef494718e82a77b2e9433c2480e7383b0 |
|
09-Oct-2012 |
Christopher Tate <ctate@google.com> |
Defer wifi bounce following restore for 1 minute...
...to allow network-reliant restore actions by apps to get underway.
Bug 7304761
Change-Id: Ia1d2321ef86609588efbc7add043c24a12ec6a20
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 3543beb255b30c294283270ede3fcf048dc71b02 |
|
05-Oct-2012 |
Christopher Tate <ctate@google.com> |
Fix settings restore
Now with more fix.
Bug 7249405
Change-Id: Ib8bc2e9c5b054054f4aaacf14af8d5a0d05d6e3a
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 5067685ccf6c294a77a3e7f0577190600a0e6238 |
|
05-Oct-2012 |
Christopher Tate <ctate@google.com> |
Settings (and general) restore fixes
Pro tem, we ignore wifi configuration data when restoring system settings.
This is not ideal, but it *does* mean we do not bounce wifi off and on
again during the extended restore process, which in turn means we don't
interfere with things like the Play Store's download of applications.
We do continue to back up wifi configuration, and will start using that
data again when the new implementation that restores AP configurations
without having to bounce wifi comes to pass.
Also, this CL fixes a longstanding bug in BackupDataInput.skipEntityData()
that was being reproduced reliably once settings restore was skipping
the wifi-related entities in the restore stream.
Bug 7249405
Change-Id: I61520a9a116b66ebdf95734d09d9afd46406df01
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 66488d64df8c3cf8722b8bf282398617cf3c0551 |
|
02-Oct-2012 |
Christopher Tate <ctate@google.com> |
Make settings backup/restore work in the new multi-user world
1) Properly handle restores of settings elements that have been migrated
to the new global namespace
1) Back up and restore the new global settings namespace
3) Make sure to back up / restore the global entity
ENABLE_ACCESSIBILITY_GLOBAL_GESTURE_ENABLED
Bug 7249405
Change-Id: Ibfa9930ea4d0e16c7635697e8c631b155e4c0cb2
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| d71778804c2b0f30c3b7b63997273d54a53e58d7 |
|
08-Sep-2012 |
Christopher Tate <ctate@google.com> |
Log all individual settings restored
Trying to get a handle on bug 7129406
Change-Id: If436c7888f0a8565d83c03024c54ea6ec83e7955
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 8dfe2b9dd7b8b924177a9f67785bcd6d1b0eeada |
|
16-May-2012 |
Christopher Tate <ctate@google.com> |
Merge restored wifi APs, don't overwrite
We now preserve any already-known AP configuration information when
restoring wifi from backup, instead of flatly overwriting the known
definitions with the historical ones. This means that if you are
performing setup while connected to an AP unknown in the restored
dataset, you will retain your connection instead of seeing it drop
partway through the restore process because suddenly the supplicant
"forgot" how to connect to it.
Duplicates are resolved by retaining the currently-defined network
configuration and discarding the historical one.
Bug 6443790
Change-Id: I1f44cc6a01fc4ae7c4b680682a10fcb7a0be65dc
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 4f4f5166c9379a646de887c4d9ae58fc94afb6ed |
|
27-Apr-2012 |
Irfan Sheriff <isheriff@google.com> |
Fetch WifiManager instance at the time of use
Bug: 5340393
Change-Id: Idb0a6dbe969bc3c7955134df43b86f28208c73c3
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 1d8e7d640ad5ed6fe82bca017293dd89169f1c2e |
|
10-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Fix Cursor leak in SettingsBackupAgent.
Bug: 5434060
Change-Id: I805695a30d6778d0c7302e63bcfe3dc1a38488f4
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| a571a5836cdbc71feefb13648004b8ca7fe05dfb |
|
21-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Settings are restored in alphabetical order rather in order of dependency.
Settings were restore in alphabetical order and capturing dependency
among them required keys to be chosen in such a way that after sorting
they apprear in dependency order. Now settings are exported and restored
in the order they are declared in the arrays of settings to backup.
Hence, the order in this array will capture the dependency order.
bug:5343351
Change-Id: I93a40bcdd194943cd6f85aa18f1557d546e38274
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 2efd2dbbac9eac89620683696c6076463c3a1cd6 |
|
20-Jul-2011 |
Christopher Tate <ctate@google.com> |
Support full-backup encryption and global backup password
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 79ec80db70d788f35aa13346e4684ecbd401bd84 |
|
24-Jun-2011 |
Christopher Tate <ctate@google.com> |
Make full backup API available to apps
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| f12fbcd608b8f73901882c305572ac2c1cfe9beb |
|
29-Jun-2011 |
Christopher Tate <ctate@google.com> |
Fix settings restore even harder
Change-Id: If6920743ae92dcf811a87a1eefd357f849c03a23
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 28cdb9e104e03680d61c3e6dd654d1beff51427d |
|
25-Jun-2011 |
Christopher Tate <ctate@google.com> |
Fix settings restore
Also correct the debug-mode logging of error locations in backup data.
Bug 4914182
Change-Id: Ie7dda0192afa819e42490b7ffd2d3db6f11968f6
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 75a99709accef8cf221fd436d646727e7c8dd1f1 |
|
19-May-2011 |
Christopher Tate <ctate@google.com> |
Restore from a previous full backup's tarfile
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 4a627c71ff53a4fca1f961f4b1dcc0461df18a06 |
|
01-Apr-2011 |
Christopher Tate <ctate@google.com> |
Full local backup infrastructure
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 4aeca7c5908387bc7efb0785830aea1053264062 |
|
11-Mar-2011 |
Irfan Sheriff <isheriff@google.com> |
Backup and restore IP and proxy settings
Bug: 4081954
Change-Id: I27266637c6ade0c5c8242792176d1edae0983446
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 7078789a39f51e473bdf864e16202f67ce8ca219 |
|
17-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
More cleanups from CloseGuard reports.
Change-Id: Ib3d5428073563d564fe45475127eb2cec177ab49
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| cc84c69726507a85116f5664e20e2ebfac76edbe |
|
29-Mar-2010 |
Christopher Tate <ctate@google.com> |
API CHANGE: rename BackupHelperAgent => BackupAgentHelper per API Council
Part of bug #2545514
Change-Id: Ic775e3b942c485252149c1b6c15c88517fa4e3e5
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 4528186e0d65fc68ef0dd1941aa2ac8aefcd55a3 |
|
06-Mar-2010 |
Christopher Tate <ctate@google.com> |
Refactor android.backup => android.app.backup
Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 13f4a64ddd0d81ffa04cb2ff4fd4c6500d6d21ed |
|
01-Oct-2009 |
Christopher Tate <ctate@android.com> |
Turn off the last of the STOPSHIP verbose debugging
Change-Id: Id93f4c9e9fb8468a554ae1e5c5c767f72903662c
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 436344ae12c819f58306ceb94241a266141e1218 |
|
01-Oct-2009 |
Christopher Tate <ctate@android.com> |
Turn off most of the backup-related debug logging
The core logging in BackupManagerService and in the Google backup transport are
still enabled at this point.
Change-Id: I10abfa565bbd1097dd3631051b6aca163e4af33a
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 796e0f0ed531b7ff9922cd632d70d8f1da8f5829 |
|
22-Sep-2009 |
Christopher Tate <ctate@android.com> |
Don't restore any setting that we don't think should be backed up
The ad-hoc blacklist has been replaced by a check that whitelists each restored
datum against the set of keys that we actually back up. Keys read from the
restore data which are not found in the whitelist are not applied.
Also adds in some more debugging output, marked to be disabled for ship.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| a286f419084d56217f05a64f1d24c9e07917212e |
|
19-Sep-2009 |
Christopher Tate <ctate@android.com> |
Don't back up / restore certain sync-related settings
In particular, this no longer attempts to back up the on/off state of specific
backend syncing [gmail/contacts/calendar], nor the "background data" toggle.
The former was causing a great deal of spurious trips through backup as the
notification was being tickled during general sync operation, and the latter
makes little sense at restore time.
Fixes these issues:
b/2097613 - frequent "backup_data_changed" messages in event log
b/2131662 - should not backup background data, master sync settings
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 0738e8893540e8f7fac7c193be5fe24b67f04672 |
|
12-Sep-2009 |
Christopher Tate <ctate@android.com> |
Don't backup/restore telephony material from secure settings
* Remove several nonportable telephony settings from the set to be included in
the backed-up dataset
* Explicitly ignore those settings if they're encountered during a restore
operation, so that we don't inadvertently do things like configure a GSM
phone to use CDMA logic.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 2cfab8445851c59f7da07d81645ece8d70e8ce28 |
|
10-Sep-2009 |
Amith Yamasani <yamasani@google.com> |
Save and restore partial supplicant data, not the whole file.
This makes it compatible between different device types with different
wifi chipsets.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| bd022f423a33f0794bb53e5b0720da2d67e4631c |
|
15-Aug-2009 |
Nick Pelly <npelly@google.com> |
Bluetooth: API change.
Split BluetoothDevice into BluetoothDevice and BluetoothAdapter.
BluetoothAdapter: Represents the local BT adapter. Operations on the local
adapter (start a scan, etc).
BluetoothDevice: Represents a remote BT device. Operations on remote devices
(pair, connect, etc).
IBluetoothDevice.aidl -> Bluetooth.aidl
BluetoothDeviceService.java -> BluetoothDeviceService.java
TODO:
Javadoc
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 92c1752175f0880a0e0a05fdca37b54a8fb2b52d |
|
08-Aug-2009 |
Christian Sonntag <cxs@android.com> |
Change WIFI key
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| c5b5b0fb94d078148b5fe5f6b8bb4ee361949f3e |
|
07-Aug-2009 |
Christian Sonntag <cxs@android.com> |
Retain state of wifi connection after restore
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| d158214511a3c04753de04fa6389e46d33135c38 |
|
09-Jul-2009 |
Amith Yamasani <yamasani@google.com> |
Restore audio settings and wifi.
Optimize backups by writing an entity only if the checksum of the data has changed.
Call into the hidden AudioService API to apply changed audio settings.
After restoring wifi data, make sure that the permissions and ownership are set
properly for the supplicant process to access it.
Locale isn't restoring properly - TODO added.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 8823c0a8c68fe669c21c539eef9fc6541f0c7494 |
|
07-Jul-2009 |
Amith Yamasani <yamasani@google.com> |
Backup / Restore locale preference.
Also backup development settings MOCK_LOCATION and USB_DEBUGGING.
Backup and restore more of the Audio settings. Won't work yet without a reboot.
Disable Wifi supplicant restore temporarily. It seems to be disabling Wifi due to
permissions problems.
Don't restore Ringtones.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 70c874ba20b586712a7550b6c5efeb6dc0fdf9fa |
|
06-Jul-2009 |
Amith Yamasani <yamasani@google.com> |
Restore GPS state and ringer/vibrate toggles.
Inform backup manager when sync flags change. Set ringer/vibrate mode.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 16d79e56ca3fe7606c48882d9b1aef6267d69124 |
|
02-Jul-2009 |
Amith Yamasani <yamasani@google.com> |
Backup Wifi supplicant data.
WifiService requests a backup when it writes wifi configuration to disk.
Backup the wifi supplicant file when settings provider runs backup.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
| 220f4d633be1098e7887dbd06f179138bf19f1ad |
|
02-Jul-2009 |
Amith Yamasani <yamasani@google.com> |
System and Secure settings backup.
This backs up the basic system and secure settings. THe restoration doesn't
take effect immediately. You many need to restart the runtime to see all
restored values take effect.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|