Toggling the top-level switch is bypassing the disabled
state of the switch and leaving it in an inconsistent and
unrecoverable state.
Bug: 26863852
Change-Id: I9fed626b743fd6aac2c20910493bdec4778cc629
Now that we support webview fallback packages - packages that should be
enabled if and only if no other webview packages are available - we need
to ensure that the Settings UI consistently shows that these packages
cannot be enabled or disabled (e.g. the 'Enable' and 'Disable' buttons
for enabling/disabling them are greyed out).
Also, remove the Dialog that lets a user enable a disabled webview
package from the webview implementation Dev Setting. Instead show a
Toast if the user has chosen an invalid package.
Bug: 26375524, 26375860
Change-Id: I949083d3f7c83cd2e049dd2c5c15ec5ab880fe07
This reverts commit 292b9fd2da.
Will add back later and limit to non-user builds.
Bug: 27295415
Bug: 25276672
Bug: 24815256
Change-Id: Ide230449615318a0d3f4bc607724e7eaaf1d43c4
For devices using A/B update or update-on-boot feature, we need a
Developer option to prevent the system updates from being installed
automatically.
We store the "disabled" status internally to turn on the automatic
update by default. But we show the opposite "enabled" status on screen
based on UX comments.
Bug: 27193001
Change-Id: I36a08a2a08fd1ba0f8f3c4b3ae5a08dc50829cd2
This only removes the option from the Developer Settings screen.
Future changes will need to:
- Remove the localized strings.
- Remove the settings constants in SettingsLib.
Bug: 26991160
Change-Id: I1770bb1c206818317845ff5aa340b2a9a76118b5
You can't choose to use a disabled WebView package as WebView
implementation (this ensures that without interference from the user the
system will always try choose a package which will eventually become
updated, rather than a package that does not receive updates) and there
are cases where a package cannot/should not be enabled (to save e.g.
bandwidth).
Therefore, with this change we no longer show disabled WebView packages
as potential WebView implementations in the WebView implementation
Developer setting.
Bug: 27188851
Change-Id: I19a9b16118703d8a54d8215c186fc99ffefc4b6d
The enabled-state of a package is already being accounted for when
creating an ApplicationInfo from the package manager, so checking it
again in Developer Settings to figure out whether a package is enabled
is unnecessary.
Change-Id: I1b057a28bb33fc2bbc5ea750bfa04a75860ff1d1
NOTE: Original CL updated: Developer-related settings in
res/values/strings.xml are now in SettingsLib .
Bug: 27078729
Change-Id: I8a029baeb25b449446ae9bcc8cb220d5ec8e44a9
Added a toast message to inform the user that the color temperature
setting is applied once the display is off.
Bug:26110238
Change-Id: Ia773581eb441ed2f4ac44b20e611ad3700e8abbf
if the device is OEM unlocked already, disable the OEM
unlocking pref. If it's locked, enable.
Bug: 26039090
Change-Id: I915f3cf57deef8f5775d466dec59c891c1546b1b
Manual merge from mnc-dr1.5-dev.
Add a switch in Developer Settings to enable "cool" color temperature mode.
Bug: 26110238
Change-Id: Id0ab3283c1ee3208287c8dca11298a4bc367b314
When we disable OEM unlocking through developer options, no need
to show the warning dialog.
bug:26285618
Change-Id: I476761aeb850a60f345fc2fd8cbdb4ec730cc2c9
The WebView loading logic will not allow for the user to pick a provider
that is disabled. But in the WebView developer setting for choosing
provider disabled WebView providers are shown. Therefore if the user
wants to use a disabled provider we (with this patch) prompt them to
enable the provider (if they agree we then enable it).
Bug: 26400585
Change-Id: I42476acc54f01cf873b267dd22079c5c50fa07a2
- Before silencing the logs, ensure security logs are whitelisted
- Only touch persist.log.tag properties if they need to be, add
stacking to the property.
- Clear persist.logd.size property when at default setting
Bug: 26178938
Change-Id: I8fdb040062dc9cbb23d7bc3c117d96ff8550c132
The picker in frameworks/base does the simpler job: when called it
returns one locale only, no knowledge of locale lists.
The previous com.android.internal.app.LocalePicker shows a list of
locales based on the localised resources available.
The replacement (LocalePickerWithRegion) shows a more complete list
(a curated subset of all the ICU locales, but still pretty big).
Because of the length of the list the LocalePickerWithRegion splits the
selection in two: you first select the language, and then the region
(where that language is used).
If you need to select one of the locales completely supported by the
system (that have translated UI), continue to use
com.android.internal.app.LocalePicker
They should be compatible: they show some UI and end up selecting a
locale.
Beyond the UI differences, LocalePickerWithRegion will return more
"granular" locales (tens of French, or Spanish, or English locale
variants).
Bug: 25800339
Change-Id: I0371d82302b462b1a633c149df08a39b6d508f58
