Fixes issue where summary text would not properly describe the state of
camera based auto rotation when permission is missing or when another state is blocking the feature
Bug: 190095500
Test: locally with flame & make RunSettingsRoboTests -j$(nproc) ROBOTEST_FILTER=SmartAutoRotatePreferenceControllerTest
Change-Id: I7609ca87658e08831f3bc37c839f00f63946ddec
Test: verified intended behavior on crosshatch and no regression on flame, make RunSettingsRoboTests -j$(nproc) ROBOTEST_FILTER=SmartAutoRotatePreferenceFragmentTest
Bug: 181299673
Change-Id: Ic9f44091e95915bc78bc70b86d7f132ba6e159ed
if it is restricted.
- Use the RestrictedPreferenceHelper to check the restricted state.
Fix: 179245126
Test: rebotest and see the UI
Change-Id: I3c0e3bd0f3596d6fa548b6f8f10e4d12e7e50c9a
The brightness bar is a dialog activity. If the shared axis transition
is applied, we'll see an empty page appears with a seek bar on the top,
which is not ideal. Hence, suppress the transition to keep the original
behaviour.
Fixes: 189076430
Test: robotest and test on the brightness level
Change-Id: I1572c31f09d8c6bb3b2c906f6211ed9b97024439
In Screen Timeout Settings, preferences should not be initialized in
onAttach() because the setting style hasn't been loaded yet. This change
defers the initialiaztion of those preferences so that they appear
correctly.
Test: manually tested.
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.display
Bug: 183909540
Change-Id: I86cfe196549d709ed763faa004fff7b631365b1e
Refer to the now centralized Secure setting, instead of local strings
Bug: 188175341
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.display
Change-Id: I5fff84347c369ae94d6c8359cc49dcbcf9b6ee72
- remove the outer circle of the icons
- tint the icons including injected ones
Test: robotest, visual
Bug: 182870640
Change-Id: If72c37152f4f0d68e25149b11d497eef1c7ece91
Step 2 of 2. Move wallet settings from System -> Gestures -> Power
Menu to Display -> Lockscreen. Split the existing sensitivity setting
into two separate toggles to give users better control of their
privacy settings.
Bug: 185597511
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.display
Change-Id: Ifc390945a45258bbcc3c0a6ac67a0c4a3f7a9e91
Preferences shouldn't be initialized at onAttach() because the settings
style hasn't been loaded yet. This change defers the preferences
initialization so that they comply with the settings style.
The change ag/14114425 is reverted due to b/186904496. This change
includes a fix for that issue.
Test: manually
Test: make RunSettingsRoboTests
ROBOTEST_FILTER=com.android.settings.display
Bug: 183909540
Bug: 186904496
Change-Id: I317ce251f4d11e62c6592ee587c2919da4d45db3
This reverts commit 20d1da2b62.
Reason for revert: Based on bisection, this is the likely root cause of b/186904496
Bug: 186904496
Change-Id: I0eaa026b52610d7ef4543c32791531971e68f8e6
The peak refresh rate will not be guaranteed to be integer, but
config_defaultPeakRefreshRate only takes integer into the comparison.
To expose the smooth display is enabled by default in Settings, the
patch corrects the check of peak refresh rate with proper rounding.
Bug: 185102566
Test: Enable smooth display by default in Settings
Change-Id: I658ce22cf0b0a108c4b721e3e5320caf9c379639
Preferences shouldn't be initialized at onAttach() because the settings
style hasn't been loaded yet. This change defers the preferences
initialization so that they comply with the settings style.
Test: manually
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.display
Bug: 183909540
Change-Id: I4dc4503924a1dcd5b8d41f7d27e576befb11f976
The slider and settings need to use the new brightness
api so that:
1) It can work for mutiple-displays that support brightness
2) Can work with high-brightness mode which can dynamically
adjust the brightness min and max.
Bug: 168210311
Test: Verify that slider can go to 100% with HBM on or off.
Test: atest com.android.settings.display
Change-Id: I01029e211f64f0a8598b1388dd3bb535eb0beb69
Changes
* Restore previous timeout behaviour. This
behaviour was modified in Android S and
was previously working on Android R.
* If the selected timeout is less than
the max timeout set by the admin, select
the largest possible timeout.
* If there are no possible timeouts for the
user, disable the preference.
Manual testing steps
* Download CtsVerifier and CtsEmptyDeviceOwner apks
* Set device owner
* Run Policy transparency test > set max time to lock
* Set max time to lock and verify correct value is
shown in Settings. Compare behaviour with Android R.
Bug: 184104507
Test: manual testing
atest com.android.settings.display.ScreenTimeoutSettingsTest
Change-Id: I8d0e66ccce14cca244bcd380fd225a31df0b8999
