| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |\
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |\|
| |
| |
| |
| |
| | |
rvc-dev am: ca83d45538 am: 75d943ca32 am: 152ba9c311 am: f953adcd15
Change-Id: I4a6162e90a7710d948e334907c54acda39b53978
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |\|
| |
| |
| |
| |
| | |
951d75d4f8 am: 7d866818da am: ac85fd254b am: 7eafac2d6c
Change-Id: If75c4852e0555a3d3d57f766120307d0ab306c31
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |\|
| |
| |
| |
| |
| | |
am: c3a77a143c am: ade7fb33fd" into rvc-d1-dev-plus-aosp am: ce96fd7acc am: e421fb2671
Change-Id: Icdf25109cca61f92341b77d52f59400fc765219a
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/
|
|
|
|
|
| |
Test: atest FrameworksNetTests
Bug: 136595429
Change-Id: I33f787644c44d7b0e5ce17a433820cfcd985cdfb
Exempt-From-Owner-Approval: Merge from AOSP
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Bug: 128348646
Test: manual
Change-Id: I40dbfc78ee983ffacc56a68d2c5ba2aefb16357f
|
| |
|
|
|
|
|
|
|
| |
IllegalArgumentException is more appropriate than
InvalidParameterException, because this isn't security exception
Bug: 78330382
Test: atest FrameworksCoreTests:SettingsBackupTest
Change-Id: I2219f08cb8bc7604e74074b3f81fd7d887cd2154
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
to ACTION_SETTING_RESTORED intent
Test: manual (system restore from N-MR1 and O)
Bug: 64232609
Change-Id: I142df7acb11309bc4f5f185e45a1f91f86d0334a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |\
| |
| |
| |
| |
| |
| |
| | |
1755a4af45
am: 6682651b2b
Change-Id: I6dd36520e8a0cf09c75788eda2e03b4309acea9e
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Bug: 35707622
Bug: 28322375
Test: Ran a11y cts. Updated those tests in linked CL to
ignore this feature.
Change-Id: I1dccb3ae4e1f4d6bb832ae1b0edd4dad4a54289e
|
| |/
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
Bug: 19913735
Change-Id: I2150c6baaab80fe11312e4401394a2a8da52e595
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
Bug: 10130785
uncanonicalize() can return a null now, so abort restoring the ringtone
in that case.
Change-Id: I28765818c8d3e1fb3f271afdfe66ebc955cfcefe
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
And add support for respecting it.
Change-Id: Ia5cf9134c5f5741c3f55afadbe54f862da7bfe5b
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|