45e6fec2cfdb148b48100e65d9e7e207b8cdcf64 |
|
20-May-2016 |
Paul Stewart <pstew@google.com> |
Don't remove existing EAP configurations When merging backed-up configurations with the current supplicant configuration, we read both configurations into a instance of WifiNetworkSettings. No EAP configurations should be restored as per b/25725016, however existing EAP configurations that already reside in wpa_supplicant.conf (presumably configured in SUW) should not be removed in the process. This CL adds a parameter to the "readNetworks" method to allow it to select whether or not EAP configurations should be read in. It is used to allow the "restoreWifiSupplicant" method to copy in EAP configurations from the existing wpa_supplicant.conf, but not out of the backup data. BUG: 28873992 Change-Id: I8b3e0c1a6629b3f1ca5055b1b2190e6b3ca4c033
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
f61a847881ad251593e15e322dae39cc9bd1cd10 |
|
10-Feb-2016 |
Ritesh Reddy <riteshr@google.com> |
Merge "Enabled Network Policy Backup/Restore." into mm-wireless-dev am: d9c4bc0c4d * commit 'd9c4bc0c4db7a8b16d8ea0f58ed0615efc167f47': Enabled Network Policy Backup/Restore.
|
70cffc57e5e3884054080e0066fa7fc34243daec |
|
10-Feb-2016 |
Ritesh Reddy <riteshr@google.com> |
Merge "Enabling SoftAP Configuration Backup." into mm-wireless-dev am: c4a1188afd * commit 'c4a1188afd81b4b773e30ec184839bc1a82b355d': Enabling SoftAP Configuration Backup.
|
adca34a0d6b5955f0cbc931dd0834b25fe3759b9 |
|
04-Feb-2016 |
Ritesh Reddy <riteshr@google.com> |
Enabled Network Policy Backup/Restore. Added Backup Restore specific NetworkPolicySerializer to NetworkPolicy Class and related classes. Change-Id: I2a11e2afae8dd9e0ee0c3356e669a73f6a1361af
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
aeb4c0601330f5f30fe0026a714ff59f0fe90abf |
|
26-Jan-2016 |
Ritesh Reddy <riteshr@google.com> |
Enabling SoftAP Configuration Backup. SoftAp Conf is backed up as a serialized WifiConfiguration object. Change-Id: Ib7f4d130600313a67b710b45df274e15f0baad24
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
2400d27a6571cee35f87eeb7577b31b7f4a4de74 |
|
02-Feb-2016 |
Ritesh Reddy <riteshr@google.com> |
Constrained allowable backup versions Constrained the version on an incoming backup set to the highest version that the SettingsBackupAgent can handle. This is to deal with either corrupted backup sets or newer backup sets (when modifiying/downgrading the SettingsBackupAgent). Change-Id: I4d666e8d4541c0b86e656a73744837d03318c4ae
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
33117feb6be2da63e3cb660d3912af1730b32c64 |
|
01-Feb-2016 |
Ritesh Reddy <riteshr@google.com> |
Revert "Enabled SoftAP Configuration Backup" This reverts commit 188ae9dc22e0ecc0612c8bfe1efdb0e22acdc43e. Change-Id: I37e517d0e7a9a17614fa1b6890e1854346fd0138
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
6b7f0f30619fd4468844abfce4d34232707cd4a2 |
|
01-Feb-2016 |
Ritesh Reddy <riteshr@google.com> |
Revert "Enabled NetworkPolicy backup and restore." This reverts commit 9f548b00dcdd89e8d557223b8b99269ca7362c2e. Change-Id: If0081fa34333339e36f9e8b9a34a2e3a84e4638f
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
9f548b00dcdd89e8d557223b8b99269ca7362c2e |
|
09-Dec-2015 |
Ritesh Reddy <riteshr@google.com> |
Enabled NetworkPolicy backup and restore. Backing up NetworkPolicy through NetworkPolicyManager API Bug: 17857156 Change-Id: I2363e66a1b27f50b2454b4550a241a3d84bf4b7c
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
188ae9dc22e0ecc0612c8bfe1efdb0e22acdc43e |
|
24-Nov-2015 |
Ritesh Reddy <riteshr@google.com> |
Enabled SoftAP Configuration Backup Backing up SoftAP Configuration through WifiManager API. Bug: 5343116 Change-Id: If17effb98c3489246d817fa3612f3f11b9ead9ab
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
9bc2f472e9cf204c737025b5d7101ba16c43b356 |
|
18-Nov-2015 |
Christopher Tate <ctate@google.com> |
Don't back up / restore EAP network definitions Bug 25725016 Change-Id: Idfef9dd53f2403bbe4c950493a0ab8fa66a3b7d4
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
45dc0d03fdcc649f56bfd3a67a1334ced1e2789f |
|
08-Aug-2015 |
Christopher Tate <ctate@google.com> |
Fix wifi disable during restore The main looper needs to run freely for a moment after disabling wifi in order for various signals (content observers, broadcast) to propagate to all the listeners that need to take action for the wifi stack to shut all the way down. This patch breaks up the disable-and-rewrite-config sequence of wifi AP restore in to two distinct operations separated by a moment so as not to block those necessary messages. Bug 22979342 Change-Id: I271766cad0e454669a194652fb67f835bb022cd1
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
907e01eb7083c54aa1e840ea4e76a6518a028a72 |
|
07-Aug-2015 |
Christopher Tate <ctate@google.com> |
Wait a bit longer for wifi to shut down before rewriting the config We've seen case of it taking longer than 1500ms for the wifi system to actually shut down after the triggering settings element is written, so extend the wait time a bit. We've seen it take more than 1500ms but not more than 2500ms, so that's the new heuristic. This will of course all become happily obsolete once we start applying restored AP definitions programmatically rather than by filesystem-level operations. Bug 22979342 Change-Id: I6acf1baac23d4100124093128b82abf242b11a0e
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
8150d2a2a12b38598fd55d8ae3c3b5662ec3520f |
|
17-Apr-2015 |
Adrian Roos <roosa@google.com> |
Require explicit userId in LockPatternUtils Bug: 18931518 Change-Id: Ib03f37df9135f0324a998c62d165d8eea46328c8
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
6597e3435f8abfedbb9a4f1bfb10cc17ea7f38bf |
|
17-Feb-2015 |
Christopher Tate <ctate@google.com> |
Notification listener backup & restore We now back up & restore the set of enabled notification listeners. Post- restore, a listener that had been enabled on the ancestral device will be enabled on the current device as soon as it's installed, matching the user's previous configuration. After this has happened the enable/disable state for that app is not "sticky"; disabling it again will work as expected. The infrastructure for accomplishing this is general: it can be leveraged by any ManagedServices derivative. There's a bit of extra wiring in the settings provider to support the restore-time information flow as well. This is because ManagedServices -- like many other parts of the system -- monitors writes to the settings provider and does work in response to new writes of the elements that it cares about. Unfortunately this means that there is no way to use the BackupAgent's restoreFinished() hook to post- process the restored data: by the time it is run, the ManagedService's observers have already executed and culled any unknown components from the description that was just pushed into settings. As of this patch, the settings provider's restore logic knows that a particular settings element will require a message to interested observers about the restore-driven change. The message is delivered as a broadcast, and is sent after the new value has been committed to the settings db. Adding other system ManagedService handling that parallels this will only require adding a new corresponding entry to the table of individual settings for which the relevant "this settings element is being restored" broadcast is sent, found in SettingsHelper. (It isn't sent for all settings elements because very few settings elements have semantics that require it; 3rd party code won't be running yet during platform restore anyway; and sending up to hundreds of broadcasts during setup & restore is far from ideal.) Bug 19254153 Change-Id: Ib8268c6cb273862a3ee089d2764f3bff4a299103
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
072543f58037697772663ed34ee26317e9d662c5 |
|
13-Feb-2015 |
Amith Yamasani <yamasani@google.com> |
Backup/restore owner info from locksettings Backup the owner info string and whether or not owner info is to be shown on the lockscreen. Watch for changes to the two settings in LockSettingsService and inform backup manager. Bump up version numbers for the new entity. Bug: 19300363 Change-Id: I35485c961d18b26be68873f4d5eeedc5ae513cc8
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
8561ff98cdcfcc930630c72b2dc876cc5c1a8cb2 |
|
18-Feb-2015 |
Christopher Tate <ctate@google.com> |
am 32f216c3: am 8cd95aba: am 56238eaa: am 129ea76a: Fix wifi AP backup * commit '32f216c359540219905bbe0295da31e594d83f5f': Fix wifi AP backup
|
129ea76a4a129fb3e8e997e8c604c0712e8a9d73 |
|
18-Feb-2015 |
Christopher Tate <ctate@google.com> |
Fix wifi AP backup An OutputStream buffers only by explicit contract. OutputStreamWriter buffers internally, always. Do not get these behaviors confused. Bug 19341967 Change-Id: I0610ed625b0175620083dd286f3a73c24956b171
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
683914bfb13908bf380a25258cd45bcf43f13dc9 |
|
15-Jan-2015 |
Svetoslav <svetoslavganov@google.com> |
Rewrite of the settings provider. This change modifies how global, secure, and system settings are managed. In particular, we are moving away from the database to an in-memory model where the settings are persisted asynchronously to XML. This simplifies evolution and improves performance, for example, changing a setting is down from around 400 ms to 10 ms as we do not hit the disk. The trade off is that we may lose data if the system dies before persisting the change. In practice this is not a problem because 1) this is very rare; 2) apps changing a setting use the setting itself to know if it changed, so next time the app runs (after a reboot that lost data) the app will be oblivious that data was lost. When persisting the settings we delay the write a bit to batch multiple changes. If a change occurs we reschedule the write but when a maximal delay occurs after the first non-persisted change we write to disk no matter what. This prevents a malicious app poking the settings all the time to prevent them being persisted. The settings are persisted in separate XML files for each type of setting per user. Specifically, they are in the user's system directory and the files are named: settings_type_of_settings.xml. Data migration is performed after the data base is upgraded to its last version after which the global, system, and secure tables are dropped. The global, secure, and system settings now have the same version and are upgraded as a whole per user to allow migration of settings between these them. The upgrade steps should be added to the SettingsProvider.UpgradeController and not in the DatabaseHelper. Setting states are mapped to an integer key derived from the user id and the setting type. Therefore, all setting states are in a lookup table which makes all opertions very fast. The code is a complete rewrite aiming for improved clarity and increased maintainability as opposed to using minor optimizations. Now setting and getting the changed setting takes around 10 ms. We can optimize later if needed. Now the code path through the call API and the one through the content provider APIs end up being the same which fixes bugs where some enterprise cases were not implemented in the content provider code path. Note that we are keeping the call code path as it is a bit faster than the provider APIs with about 2 ms for setting and getting a setting. The front-end settings APIs use the call method. Further, we are restricting apps writing to the system settings. If the app is targeting API higher than Lollipop MR1 we do not let them have their settings in the system ones. Otherwise, we warn that this will become an error. System apps like GMS core can change anything like the system or shell or root. Since old apps can add their settings, this can increase the system memory footprint with no limit. Therefore, we limit the amount of settings data an app can write to the system settings before starting to reject new data. Another problem with the system settings was that an app with a permission to write there can put invalid values for the settings. We now have validators for these settings that ensure only valid values are accepted. Since apps can put their settings in the system table, when the app is uninstalled this data is stale in the sytem table without ever being used. Now we keep the package that last changed the setting and when the package is removed all settings it touched that are not in the ones defined in the APIs are dropped. Keeping in memory settings means that we cannot handle arbitrary SQL operations, rather the supported operations are on a single setting by name and all settings (querying). This should not be a problem in practice but we have to verify it. For that reason, we log unsupported SQL operations to the event log to do some crunching and see what if any cases we should additionally support. There are also tests for the settings provider in this change. Change-Id: I941dc6e567588d9812905b147dbe1a3191c8dd68
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
0c3e78c93f452d2c7ecc7dd72d68e95f866f4ea4 |
|
09-Jan-2015 |
Christopher Tate <ctate@google.com> |
am a97fe138: Merge "Exclude ephemeral networks from wifi backup" into lmp-mr1-dev automerge: 68dabad automerge: f3ac99f * commit 'f3ac99f2e093f851ca52bcd5aefb251046db10fa': Exclude ephemeral networks from wifi backup
|
cab915a3278e52b9ba11d47a69bcbbad1d76a263 |
|
08-Jan-2015 |
Christopher Tate <ctate@google.com> |
Exclude ephemeral networks from wifi backup We compare the set of networks defined in the supplicant with the set of networks described as "configured" by the Wifi Manager. The latter excludes ephemeral networks, so any network definition we find in the supplicant data that we do not also find in the configured network set, we ignore for backup purposes. Bug 18917753 Change-Id: I8e0f258d0cdb72d7bf9482fafe64dc921419fcb2
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
68795557234a4ccfd9e90981ad1d8391fba99270 |
|
16-Dec-2014 |
Marvin Paul <marvinpaul@google.com> |
Buffer SettingsBackupAgent checksum writes Reduce SettingsBackupAgent I/O when writing new checksum by wrapping FileOutputStream in a BufferedOutputStream. Bug: 18674340 Change-Id: Ia8169445d42d032e24d8a395e678295f67841a65
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
7274444b6ea91c8cf765d9236804f962c7f0ae16 |
|
20-Sep-2014 |
Christopher Tate <ctate@google.com> |
Always give wifi a chance to quiet down during restore Not just when the current scan-always setting is on. Bug 17571997 Change-Id: Idc56c9682c18f5e23c0bde98736522a79583af5e
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
cc7b04353f432839ff52a3295a5b8c5374e7c8ad |
|
14-Jan-2014 |
Evan Charlton <evanc@google.com> |
Allow for a configurable WiFi restore bounce delay Allow the post-restore WiFi bounce delay to be configured (for example, allow it to be set to zero). Bug: 9621727 Change-Id: I0b388aadbe3b45eeb4aa00bbe0e6d86f21731449
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
074dc2eb2da23976bc2916cfe7c61dfcd9977e8f |
|
12-Sep-2013 |
Vinit Deshapnde <vinitd@google.com> |
Merge "Don't restore EAP-TLS networks from backup" into klp-dev
|
622bf2220cf7fb9bb526afa39921ee2aa93e32ca |
|
06-Sep-2013 |
Amith Yamasani <yamasani@google.com> |
Backup and restore ringtone and notification ringtone Use the new content provider API to canonicalize Uris. If the provider doesn't support it, don't save the value, unless it's a silent ringtone. Bug: 10130785 Change-Id: Id08bb2812b9b2a7036a25801d1997661b0017629
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
1d1319e3e1c266399ca1805ef1453bca71fdf6ce |
|
07-Sep-2013 |
Vinit Deshapnde <vinitd@google.com> |
Don't restore EAP-TLS networks from backup Since they need certificates that are not backed up/restored; restoring them is not that useful. Bug: 6544151 Change-Id: Ida1a98dc4f01ec1883ce7f76e52f87a27cc814cc
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
87bc7e7082ed2093ac7b5ee241439c54cf71b8f6 |
|
11-Jun-2013 |
Christopher Tate <ctate@google.com> |
Need to explicitly disable scan-always when turning off wifi ... when you want wifi to be really most sincerely off, because settings restore is about to rewrite the conf file. Bug 9032154 Change-Id: I6a3a34ac3f14ec43aa9d9cc0159fca6168ccd0a2
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsBackupAgent.java
|
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
|