summaryrefslogtreecommitdiff
path: root/packages/SettingsProvider/src/com/android/providers/settings/SettingsHelper.java
Commit message (Collapse)AuthorAgeFilesLines
* Only set locale in config for updating localeRiddle Hsu2022-10-201-1/+1
| | | | | | | | | | | | | | | | | | | To update locale, it doesn't need a full configuration because system only applied the diff of config from non-undefined fields. IActivityManager#getConfiguration actually gets the configuration according to the pid, which is process configuration. And process configuration can be overridden by the activity running in its process. So the returned value shouldn't be used to update the system persistent configuration. Therefore it is enough to use a new Configuration instance with setting the necessary fields. This is also more efficient that saves a binder call to system. Bug: 253386061 Test: atest LocaleManagerTests Change-Id: Icdce437fcf1a3bef0562cfc4dd5ad3ba52ea08ef
* Implement backup & restore for the device state based auto rotation settingChristian Göllner2022-05-061-0/+10
| | | | | | | | | - Adds the setting to DeviceSpecificSettings so that it is only restored on the same device - Prevents the non-device state based setting to be restored if device stated based settings are enabled Fixes: 196933725 Test: atest SettingsHelperTest Change-Id: I58163cb70e8136104370ae7c1cdaaa8b7124b853
* Restore long press power behaviour settingJernej Virag2022-03-221-0/+71
| | | | | | | | The LPP setting is a bit special - the behaviour is configured by the config.xml and can then be modified via user setting to invoke Assistant if available. When restoring this value we need to be careful to not clobber default config.xml device settings if the user can't change it later. We strongly prefer to rely on config.xml device value in any case. Bug: 215540406 Test: atest SettingsProvider Change-Id: I8898a52a5d28f0957f44f3075498b1139c8ce831
* Improve restore of QS_AUTO_ADDED_TILESFabian Kozynski2021-08-131-6/+23
| | | | | | | | | | | | | | | | | | | | | In order to prevent race conditions and effects happening before restore happens, this CL implements the following changes: * QS_AUTO_ADDED_TILES is restored right after QS_TILES * Writes of QS_AUTO_ADDED_TILES are marked as overrideable by restore. That way, the restore will happen even if tiles are auto-added before the restore happens. * If/when the restore happens. Any tiles that had been auto-added and manually removed in the source device are removed from the set of current tiles. * If/when the restore happens, QS_AUTO_ADDED_TILES is resolved to be the merge of the value before and after restore. Test: atest SystemUITests Test: manual restore Fixes: 168687572 Change-Id: Iad151e8310f1a5b099125d20bb673703030501b6
* Add configurable mapping between color modesChristine Franks2021-01-261-0/+22
| | | | | | | | | | | | | | | | | | | There are two categories of color modes: the standard color modes, which are defined and implemented in AOSP, and a reserved range of vendor color modes, which are defined and implemented by the vendor. Currently, there is no way to distinguish between two vendor's color modes that use the same value within the reserved range. This will allow OEMs to specify a hint as to which vendor's color mode definitions were used on the original device. If the hint from the restored device matches the hint on the new device, the color mode from the restored device can still be considered valid for the new device if it is within the vendor reserved range. If it does not match, the restored device's color mode value is invalid on the new device, and must be replaced by the default on the new device. Bug: 167449433 Test: builds Change-Id: Ie5ac0a2d783e1ea703e0342f5cdb41dca07d04d4
* Fixes magnification settings did not restoreRhed Jao2020-08-041-0/+1
| | | | | | | | | | | | | | - A redundant a11y button migration was called during the period of enabled accessibility services restoring. It rewrited the settings of a11y button targets which is restored. - User could enable a11y services in the SUW. Merges previous vales for a11y button targets after it's restored to avoid settings are lost. Bug: 160752945 Test: atest AccessibilityShortcutTest Test: Manual restore from SUW Change-Id: If55f4839c6ab0c648a35d47c9032e4b9954c0d5c
* Merge "Store original values of replaced settings in Settings.Secure" into ↵Ruslan Tkhakokhov2020-06-161-1/+3
|\ | | | | | | | | | | | | | | rvc-dev am: f2fd74fbdb am: 62bdcabed5 am: 8be850ea7d am: b0a56d98c6 Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/11867444 Change-Id: Ib585917b16fb8413824d60d59c92e8f699ecde3f
| * Store original values of replaced settings in Settings.SecureRuslan Tkhakokhov2020-06-151-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Bug: 153940088 Test: atest SettingsProviderTest:SettingsHelperTest Writing new settings to Settings.System is only available to privileged callers. Move the storage of the original values of replaced settings to Settings.Secure. See the attached bug for more context on replaced settings. Change-Id: I8f1e8e88da4766b5fca9362cdbe88d93b964db9b
* | Merge "Fix Magnification Settings didn't restore via D2D transfer" into ↵Ryan Lin2020-06-011-0/+1
|\| | | | | | | | | | | rvc-dev am: ca83d45538 am: 75d943ca32 am: 152ba9c311 am: f953adcd15 Change-Id: I4a6162e90a7710d948e334907c54acda39b53978
| * Fix Magnification Settings didn't restore via D2D transferryanlwlin2020-05-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACCESSIBILITY_DISPLAY_MAGNIFICATION_NAVBAR_ENABLED is replaced with ButtonTargets setting value. We address it in data migration but not in D2D Consider D2D, we restore it to ButtonTargets value when the restored sdk version of the received intent is below R. Bug: 155943759 Test: manual test 1. prepare an Android Q device and an Android R device 2. backup settings value of Android Q device by the google account. 3. Launch setupwizard to restore it by the google account. Change-Id: I5df070dd1ef880ac1ee5c0867b42e88782348a1b
* | Merge "Remove MASTER_MONO from replaced settings" into rvc-dev am: ↵Ruslan Tkhakokhov2020-05-051-2/+1
|\| | | | | | | | | | | 951d75d4f8 am: 7d866818da am: ac85fd254b am: 7eafac2d6c Change-Id: If75c4852e0555a3d3d57f766120307d0ab306c31
| * Remove MASTER_MONO from replaced settingsRuslan Tkhakokhov2020-04-301-2/+1
| | | | | | | | | | | | | | | | | | | | | | Bug: 153940088 Test: build In ag/11078633 we added logic for special-casing B&R of temporarily replaced system settings. Remove Settings.System.MASTER_MONO from that list as it won't be replaced anymore. Change-Id: I27e519c58b9d621465c882d8ed2532bfda884d02
* | Merge "Merge "Special-case backup/restore of replaced settings" into rvc-dev ↵Automerger Merge Worker2020-04-291-1/+32
|\| | | | | | | | | | | am: c3a77a143c am: ade7fb33fd" into rvc-d1-dev-plus-aosp am: ce96fd7acc am: e421fb2671 Change-Id: Icdf25109cca61f92341b77d52f59400fc765219a
| * Special-case backup/restore of replaced settingsRuslan Tkhakokhov2020-04-271-1/+32
| | | | | | | | | | | | | | | | | | Bug: 153940088 Test: atest SettingsProviderTest:SettingsHelperTest Values for some settings might be changed temporarily. If a backup happens at that moment, we want to backup the real values instead of the temporary ones. If a restore happens at that moment, we don't want to restore values for modified settings. See https://b.corp.google.com/issues/153940088#comment2 for context. Change-Id: I4866f56376ffa393220bbef828a4b876d586146b
* | Set attributionTag for noteOp(WRITE_SETTINGS) callsPhilip P. Moltmann2020-04-211-1/+2
|/ | | | | | | Test: atest FrameworksNetTests Bug: 136595429 Change-Id: I33f787644c44d7b0e5ce17a433820cfcd985cdfb Exempt-From-Owner-Approval: Merge from AOSP
* Migrate dark theme settingsJay Aliomer2020-03-121-0/+3
| | | | | | | | | | | When restoring settings from a different phone, UiModeManager did not update the new settings. Now, the settings are loaded from local storage and changes applied when the SettingsHelper restores a value of interest Bug: 138671559 Test: manual test: reset phone1, setup, used data transfer tool to restore from phone2, check dark mode is the same as phone 2 Change-Id: I861bec342b3284e0f398c8610fcc6881c27601a5
* Remove deprecated Settings APIs.Soonil Nagarkar2019-03-131-25/+3
| | | | | | Bug: 128348646 Test: manual Change-Id: I40dbfc78ee983ffacc56a68d2c5ba2aefb16357f
* Change the more appropriate exception class for sound settingschenedward2018-05-101-2/+2
| | | | | | | | | IllegalArgumentException is more appropriate than InvalidParameterException, because this isn't security exception Bug: 78330382 Test: atest FrameworksCoreTests:SettingsBackupTest Change-Id: I2219f08cb8bc7604e74074b3f81fd7d887cd2154
* Merge "Remove unused critical accessibility settings from backup/restore"Annie Meng2018-05-081-2/+0
|\
| * Remove unused critical accessibility settings from backup/restoreAnnie Meng2018-05-031-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACCESSIBILITY_SPEAK_PASSWORD was deprecated in O and is forced true with a default. UI_NIGHT_MODE was removed from being backed up since M. This is to clean up the critical accessibility settings check. Bug: 78227065 Test: 1) atest SettingsBackupTest 2) atest SettingsValidatorsTest 3) manual: d2d does not restore ACCESSIBILITY_SPEAK_PASSWORD or UI_NIGHT_MODE Change-Id: I50478fc8a476817301cce7187165a79b249ee31a
* | Backup and restore default alarm sound setting.chenedward2018-05-081-7/+24
|/ | | | | | | | | | As currently we don't backup/restore the selected alarm sound (alarm_alert), but both notification sound and ringtone did, we add the feature to completed backup/restore sound setting. Bug: 78330382 Test: atest FrameworksCoreTests:SettingsBackupTest Change-Id: I83321b5cdab4b7b13c46fa4f32785750e3824fc1
* Add navbar magnification to critical accessibility checkAnnie Meng2018-05-031-0/+1
| | | | | | | | | | | | | | | | If a user enables navbar magnification on their new device and the setting was disabled on their old device, we don't want to overwrite this setting and disable it on their new device during d2d restore. Bug: 79189332 Test: 1) atest SettingsHelperRestoreTest 2) manual: - Source device setting off -> target device turns setting on in SUW -> d2d restore does not overwrite - Source device setting on -> target device does not turn setting on in SUW -> d2d restores setting properly Change-Id: I58648010a9d4d3380c1c01cdaaab03828e3ea2c4
* Fix accessibility_display_magnification_scale restoreAnnie Meng2018-04-261-6/+8
| | | | | | | | | | | | | | | | | accessibility_display_magnification_scale has a default value set, so the current check to see if it was already configured during restore always falsely returned true. Now, we compare it to the default value and only say it's configured if different from the default. Bug: 72737403 Test: 1) Manual d2d restore: a) Set non-default value on source -> correctly restores on target b) Default value on source -> correctly has default value on target c) Set non-default value in SUW during restore -> correctly does not override with value from source 2) Unit: atest SettingsHelperRestoreTest Change-Id: Ie0670aac7b4ce806ac7b8baef4eb15a7c40d5919
* Don't backup/restore screen brightnessAnnie Meng2018-04-051-8/+1
| | | | | | | | | | | | | | | We no longer want to backup and restore screen brightness as it could leave the new device in an unusable state and doesn't make sense cross-device. Test: 1) atest SettingsBackupTest 2) atest SettingsValidatorsTest 3) Manual: - Old backup set that has screen brightness does not restore with change - Screen brightness does not backup or restore with change Bug: 77583401 Change-Id: I8a6d950717e6aeb9bf6773c14708ee70069f9df0
* Stop restoring ENABLED_INPUT_METHODSYohei Yukawa2018-02-071-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL logically reverts the following CL to stop restoring Settings.Secure.ENABLED_INPUT_METHODS during the new device/user setup. * If0104151b3526da6ecc669adde3119a239ecafeb 7b9a28c7f0a7b88ed1ea777edc05002d2d2b38b7 This CL also partially reverts the following CL because part of that CL is no longer necessary. * I94b4039c9f54c341aec72b62579be3dd8bd84dbb 964943ab98874a91be04f9ea2137861c93f6ffd3 In theory we should have been able to revert most of the following CL, but other team it is already used by other projects so we cannot revert it right now, unfortunately. * I01f5fafbbcfe3e3f5313829162ec011eaf2ad991 2028ddaa5024dfc9844376f2032115aee360155a Reason for revert: At high level, we doubt restoring Settings.Secure.ENABLED_INPUT_METHODS still benefits restore experience for the user. * Anecdotally almost all IMEs maintain enabled languages with their per-app settings such as SheredPreference. This observation leads us to think that we should focus more on stabilizing per-app backup/restore scenario at least for IME migration scenarios. * The code is not that simple and cost to maintain it is not that low. If we reverted this code, we could spend our resources for other tasks, including improving restore experience for the user. * Stopping restoring ENABLED_INPUT_METHODS reduces chances to conflict with what the device policy says [1]. * We have had a strict rule about what IMEs can be enabled automatically, and the rule has been that only pre-installed IMEs can be automatically enabled by the system, unless some system components that have WRITE_SECURE_SETTINGS permission overrides it. Mechanically enabling an IME just because it was enabled in the previous device does not fit this model well. * Since Android O MR1, we also backup/restore user languages specified in the global settings [2]. The default selected IME should be able to automatically enable language support based on the restored system locales. [1]: DevicePolicyManager#setPermittedInputMethods() [2]: I1e6c7ba5b7abb6bde8b01ce0f647c04a5caa81a6 0f19cc779fb81bca0d00fd0a062f431cedb5f684 Fix: 72978240 Test: atest FrameworksCoreTests:android.provider.SettingsBackupTest Test: atest FrameworksCoreTests:android.provider.SettingsValidatorsTest Test: atest FrameworksCoreTests:com.android.internal.inputmethod.InputMethodUtilsTest Change-Id: I122a8f69b2f75a9af85e14b66db764c5d153040e
* Slider always represents absolute brightnessMichael Wright2018-01-241-9/+2
| | | | | | | | | | | | | | | | | Currently the slider represents a gamma adjustment to the brightness curve when auto brightness is enabled and the absolute screen brightness when it's not. This is a fairly confusing behavior to most people, so this consolidates them to a single behavior: the slider always represents the current brightness and auto-brightness will automatically adjust it. This also moves a bunch of the brightness methods from PowerManager over to DisplayManager, since it's really the DisplayPowerController that's responsible for determining and setting the display brightness. Test: atest com.android.server.display.BrightnessMappingStrategyTest Bug: 69406898 Change-Id: I73b5982809a94cd50d563426a72d7965e923c994
* Deprecate location modesMaggie2018-01-231-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | 1. Mark public fields as deprecated: LOCATION_MODE, LOCATION_MODE_HIGH_ACCURACY, LOCATION_MODE_SENSORS_ONLY, LOCATION_MODE_BATTERY_SAVING, LOCATION_MODE_OFF. 2. Add new public methods to LocationManager: setLocationEnabled(boolean) isLocationEnabled() setLocationProviderEnabled(String, boolean) 3. Remove LOCATION_PREVIOUS_MODE and constant LOCATION_MODE_PREVIOUS. Refactor code that references LOCATION_MODE_PREVIOUS to use LocationManager.setLocationEnabled or LOCATION_MODE_HIGH_ACCURACY. 4. Mark deprecated fields and methods as removed: LOCATION_PROVIDERS_ALLOWED, setLocationProviderEnabled(), isLocationProviderEnabled() 5. Refactor logic in Settings app and Quick Settings to call LocationManager.setLocationEnabled() instead of setting location mode. Bug: 70990911 Test: Manual Change-Id: Ia49b385f8b6a358b62291983eb0146af0ecf8e02
* Add extra about SDK version that system restore happened fromMichal Karpinski2017-08-141-2/+3
| | | | | | | | to ACTION_SETTING_RESTORED intent Test: manual (system restore from N-MR1 and O) Bug: 64232609 Change-Id: I142df7acb11309bc4f5f185e45a1f91f86d0334a
* Restore device locale from backup.Seigo Nonaka2017-07-101-33/+90
| | | | | | | | | | | | | | | | | | | | | | The locales are merged with following policy. - Don't change UI locale. - Don't add unsupported locales. - Don't add duplicated locales. Bug: 35391006 Test: com.android.providers.settings.SettingsHelperTest Test: Did the following tests manually. 1. Login with Google account during SUW. 2. Set locale to "zh-TW,en-US" 3. adb shell bmgr backupnow com.android.providers.settings 4. fastboot flash userdata && fastboot reboot 5. adb reboot bootloader 6. fastboot flash userdata && fastboot reboot 7. Choose "Japanese" as the first menu on the SUW. 8. Backup from cloud with logging in to the Google account. 9. After compete SUW, verify the device locale is "ja-JP,zh-TW,en-US" Change-Id: I1e6c7ba5b7abb6bde8b01ce0f647c04a5caa81a6
* Don't apply locale as part of deferred restoreChristopher Tate2017-06-271-5/+13
| | | | | | | | | | | | Once the user has entered normal usage their locale configuration is essentially guaranteed to be what they intend to use. Don't override it during deferred restore. (We distinguish based on whether the device is already marked as 'provisioned'.) Bug 62224214 Test: manual Change-Id: Icedef6a86a2b8942937b1384b204def88f2238d2
* Merge "Add Save and Restore of BluetoothOn setting" am: bbcc641317 am: ↵Stanley Tng2017-05-101-1/+2
|\ | | | | | | | | | | | | | | 1755a4af45 am: 6682651b2b Change-Id: I6dd36520e8a0cf09c75788eda2e03b4309acea9e
| * Add Save and Restore of BluetoothOn settingStanley Tng2017-05-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | This change will automatically save the Bluetooth On setting when the user chooses to backup the phone settings into the cloud. This setting is restored by the Setup Wizard (SUW) when configuring the phone and this change will enable or disable the Bluetooth based on this restored setting. Bug: 35657817 Test: Manual test with Sailfish Change-Id: Ie4518593af63f96f8c363f98941ca5260a3ec4bb
* | Remove a11y web flags and associated settingsPhil Weaver2017-04-221-1/+0
| | | | | | | | | | | | | | | | | | Bug: 35707622 Bug: 28322375 Test: Ran a11y cts. Updated those tests in linked CL to ignore this feature. Change-Id: I1dccb3ae4e1f4d6bb832ae1b0edd4dad4a54289e
* | Update usage of ActivityManagerNative.Sudheer Shanka2016-11-141-2/+2
|/ | | | | | | | | | | - Remove references to ActivityManagerProxy. - Add isSystemReady to ActivityManager. Bug: 30977067 Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test android.server.cts adb shell am instrument -e class com.android.server.am.ActivityManagerTest,com.android.server.am.TaskStackChangedListenerTest \ -w com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner Change-Id: I07390b6124fb1515821f5c0b37baf6ae74adc8fa
* Refactor display color transformsJustin Klaassen2016-07-141-1/+0
| | | | | | | | | | | - Removed Secure.ACCESSIBILITY_DISPLAY_COLOR_MATRIX, it's not desirable to persist the actual color transformation matrix. - Refactored all SurfaceFlinger transforms to DisplayTransformManager, which allows color transforms to be set independently from the a11y manager service. Bug: 30042357 Change-Id: Iefa477dedb66aac90e1218e327802a3fab6899ed
* Add a VR listener service.Ruben Brunk2016-03-071-1/+2
| | | | | | | | | | | | | | | | | | | Bug: 22855417 Bug: 26724891 Bug: 27364145 - Add an API for VrListenerService, which is bound/unbound from the framework when the system VR mode changes. - Allow only a single bound VrListenerService at a time. - Monitor allowed VrListenerService implementations from VrManagerService and evict services as needed when packages, users, or settings change. - Remove previous VR functionality in NotificationListenerService. - Add component target to Activity#setVrMode to allow explicit selection of the running VrListenerService from the current VR activity. Change-Id: I776335f4441be0e793d3126f2d16faf86a8c621a
* Adds Settings.System.FONT_SCALE observer to ActivityManagerServiceCasey Burkhardt2016-01-241-16/+20
| | | | | | | | | | | | | | Changes to Settings.System.FONT_SCALE were not being handled by any service, which required a device reboot for any changes to take effect. Changes to this field by the Settings app worked as expected only because it is able to poke ActivityManager with an updated configuration, whereas unbundled applications cannot. This also ensures the setting value is backed up and doesn't conflict with a configured value from accessibility onboarding during restore. Bug:23033258 Change-Id: I98d4aed2f9f5893d054e6b10c4dfda406de8eba2
* Add remaining Accessibility Settings to backupAnna Galusza2016-01-081-6/+13
| | | | | | | | | list. Note additional settings that should not be restored if they are already set (on account of the new Setup Wizard, which allows critical Accessibility Settings to be set before restore). Change-Id: I95524abbef20ab12e529a2b1e6165adc7294c3db
* Cleanup OWNER references.Xiaohui Chen2015-09-231-1/+1
| | | | | Bug: 19913735 Change-Id: I2150c6baaab80fe11312e4401394a2a8da52e595
* Cleanup USER_OWNER in SettingsProvider[Test]Xiaohui Chen2015-09-021-1/+2
| | | | | | | | | | | Fixed up the tests and re-enabled it. Still suppressed one test because what it relies on Settings.Bookmarks is broken because Settings query format changed. Fixed a bug in SettingsProvider that the package query is using the wrong user id. Bug: 19913735 Change-Id: Ied86a261defba2706f726a13bc32f385f7d93787
* Back up and restore the set of enabled IMEsChristopher Tate2015-03-231-1/+2
| | | | | | | | | | | | | | | | | The restored set of enabled IMEs/subtypes is merged into the current state of the system, rather than simply replacing it. This is because we do not want to accidentally disable or reconfigure something that the user is currently relying on. There's a certain amount of repetitive activity here, rebuilding the enabled-state data structures in a different format, but it's important for maintainability that the restore code be able to rely on the core InputMethodUtils implementation of reading/writing the settings element. Bug 19822542 Change-Id: If0104151b3526da6ecc669adde3119a239ecafeb
* Merge restored accessibility enable state, don't overwriteChristopher Tate2015-03-161-1/+2
| | | | | | | | | | | We do not want to accidentally disable the user's currently-enabled accessibility service(s); presumably they turned them on during setup for a reason. We now merge the prior + current states rather than simply replacing the current state with the former. Bug 19427367 Change-Id: I96eb47df57318c88066c5da6862f23f656639148
* Notification listener backup & restoreChristopher Tate2015-03-161-17/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Don't backup ringtone on non-telephony devices.Marvin Paul2014-12-231-3/+18
| | | | | | | | | | | | Restoring a device that supports telephony using the backup set of a non-telephony device would cause the ringtone to be set to "None" instead of the default value. This was due to the fact that on non-telephony devices, the ringtone value was being backed up as "_silent" instead of null. Bug: 18777629 Change-Id: Idece1f874438a895169dbba7df1d716adea6660e
* Don't assume languages are 2 letter codes.Narayan Kamath2014-08-011-9/+10
| | | | | | | | | | | | | Also, note that this method never worked. Locale settings were stored with underscores (like Locale.toString) but matched against AssetManager.getLocales() which returned language-tag like output. bug: 10090157 (cherry picked from commit fd138cd81a689ff46e6ae90e46adcdc53f3c5442) Change-Id: Ifc81ac902c297387dba8c40aba0656e18af57c86
* Handle the case where the restore environment doesn't have the ringtoneAmith Yamasani2013-09-111-0/+4
| | | | | | | | | Bug: 10130785 uncanonicalize() can return a null now, so abort restoring the ringtone in that case. Change-Id: I28765818c8d3e1fb3f271afdfe66ebc955cfcefe
* Backup and restore ringtone and notification ringtoneAmith Yamasani2013-09-101-0/+49
| | | | | | | | | | 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
* Add user restrictions for bluetooth, sideloading, usb file transferMaggie Benthall2013-03-271-2/+2
| | | | | | | | Created constants for these in UserManager and current.txt. Also created an accessor for individual user restrictions that takes the restriction key (removing individual methods for particular restrictions). Change-Id: Ibb5517cbcdffadd3925f52cbe67d7d525813faa9
* Add location sharing toggle user restriction.Maggie Benthall2013-02-251-2/+7
| | | | | | And add support for respecting it. Change-Id: Ia5cf9134c5f5741c3f55afadbe54f862da7bfe5b
* Core accessibility settings should not be cleared on restore.Svetoslav Ganov2012-09-121-11/+21
| | | | | | | | | | | | 1. The core accessibility settings required for a blind user to use the device should not be overwritten on restore. There could have been enabled via a global gesture from setup wizard, hence the user definitely needs them. Restoring disabled values for these settings render the device useless unless sighted help is sought. bug:7138401 Change-Id: Idc593889aa61fada65b0407623720517c827df53