Based on the UX alignment in doc and figma, we remove the autobrightness
detailed page to make the consistency with other Vision settings, and
update the brightness preference icons and summaries.
Bug: 377289685
Flag: com.android.settings.accessibility.add_brightness_settings_in_suw
Test: manually
Change-Id: If4038de07dec7eeb38d3c057affba737849e23c9
Add the skeleton of the DisplayScreen
Test: atest DisplayScreenTest
Bug: 368359268
Flag: com.android.settings.flags.catalyst_display_settings_screen
Change-Id: I806504ae839ba0a53320fd94fb4fe21a52dc249b
The AccessibilitySettingsForSetupWizard class should not be responsible for managing the initial
logic of controllers, such as determining which controllers need to be dynamically added or updated
using setInSetupWizard APIs. This logic should be handled directly by the controllers themselves.
Bug: 311093618
Flag: EXEMPT bugfix
Test: atest AccessibilitySettingsForSetupWizardTest
AutoBrightnessPreferenceControllerForSetupWizardTest
AutoBrightnessPreferenceControllerTest
BrightnessLevelPreferenceControllerForSetupWizardTest
BrightnessLevelPreferenceControllerTest
Change-Id: I6065a10e72d002981c0f514543e6933d79c2aa1b
Bedtime is no longer a special case.
Fixes: 361592187
Test: atest com.android.settings.display.darkmode
Flag: android.app.modes_ui
Change-Id: Iddc5d8142d6bc0bb1f5c4ead876ee201c8818b12
Add brightness level and auto brightness preference in
accessibility_settings_for_setup_wizard.xml. Since the flagging has not
be supported yet for non-Manifest resources, for now we add the
preferences by default, and update the preferece availablity status in
each preference controllers based on the flag.
Bug: 311093618
Flag: ACONFIG com.android.settings.accessibility.add_brightness_settings_in_suw DEVELOPMENT
Test: manually
atest AccessibilitySettingsForSetupWizardTest
atest AutoBrightnessPreferenceFragmentForSetupWizardTest
atest AutoBrightnessPreferenceControllerTest
atest BrightnessLevelPreferenceControllerTest
Change-Id: I350d99138bdd14bf28828a39e42f707b5b1066c1
- Read from setting with true as fallback
Bug: 336476693
Test: atest DisplayServiceTests
Test: manual up/downgrade with settings / off
Change-Id: I5279db2b35af9e84057d8f89bbbe9f26c62237c6
- Disable even dimmer settings option if autobrightness is not enabled
on the device
Bug:179428400
Test: manual
Change-Id: I8f7add839022fc7c27694fd8daa83a608cf2736a
Set mPeakRefreshRate in the preference controllers to the highest refresh rate among all the modes of all the displays. It'll then be used to determine two things:
- if the setting is available
- the summary of the setting
This should only be done if the back up smooth display feature flag is enabled. If it's disabled, mPeakRefreshRate is passed to DisplayModeDirector and used for the votes. If the highest refresh rate of one display is 120 and that of the other is 130, we shouldn't set the vote to 130 for both displays. With the flag enabled, DisplayModeDirector figures out the highest refresh rate for each display.
Bug: 310238382
Test: atest PeakRefreshRatePreferenceControllerTest
Test: atest ForcePeakRefreshRatePreferenceControllerTest
Test: atest RefreshRateSettingsUtilsTest
Change-Id: I369927ba22df70958178505d8fc7c5747aaa8fdd
This reverts commit 19d1d3d15d.
Reason for revert: revert it because this is not the root cause.
bug: 316867690
Change-Id: I0f168dbb64044aa720202af7b1040afd4f028c9c
In the previous CL (ag/24838636), we decided to back up Smooth Display and Force Peak Refresh Rate even if the feature flag is off and then just convert the value in DisplayModeDirector based on the state of the feature flag. This was because it wasn't clear how to access the feature flag from the Settings module. This resulted in the feature partially working if the flag is off.
Bug: 313021502
Test: atest DisplayModeDirectorTest
Test: atest ForcePeakRefreshRatePreferenceControllerTest
Test: atest PeakRefreshRatePreferenceControllerTest
Test: atest SettingsBackupAgentTest
Test: atest SettingsBackupTest
Test: atest SettingsValidatorsTest
Change-Id: I3406bc5c5f49fe6102cdfe6934813a9c4073ac6f
This reverts commit cf0501e4d7.
Reason for revert: b/317462033, it seems a flaky but revert it first.
Change-Id: Ie1d5e279cca6477fc17d8c27c1ecda8d7a6b2553
We only require one auth after onStart(), and only for increasing the
timeout.
Test: atest SettingsRoboTests:com.android.settings.display.ScreenTimeoutSettingsTest
Test: also manually tested
Bug: 315937886
Change-Id: If4aed67736cd7545d3a518aadd8253ea6a9fae43
To ensure accurate comparison of peak refresh rates, it is essential
to consider the peak refresh rate after rounding. This eliminates the
risk of unexpected triggers that could activate the Smooth Display
settings UI.
Bug: 312121651
Test: check the settings with Smooth Display
Change-Id: I4cd68efbcf4fdb9d4664c96332901661a23f4f09
- show this footer when there's no footer about work profile
Screenshots:
[without work profile]: https://screenshot.googleplex.com/5pAD2xBvP6QSBvY
[with work profile]: https://screenshot.googleplex.com/7BRd6ToAjFN9QZx
Bug: 300245790
Test: manual
Test: make RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.display.ScreenTimeoutSettingsTest"
Change-Id: I6df018d7758fbec3277179358b17eb11fa1aee34
Switch and SwitchCompat are both CompoundButton.
Using CompoundButton in Java will helps migration in the future.
Bug: 306658427
Test: manual - check Settings pages
Change-Id: If2e08a9a9557ec66a3b31ef18cd2e15943098a59
SwitchPreference and SwitchPreferenceCompat are both TwoStatePreference.
Using TwoStatePreference in Java will helps migration in the future.
Bug: 306771414
Test: manual - check Settings pages
Change-Id: I84e1d7b09451106797c2b23d127855c6976678ca
The new default width for brightness slider UI is half width when in
landscape mode. However for settings we want full width, now settings
will also send a boolean along with the Intent to start brightness
dialog activity, specifying that the width of the brightness dialog
should be full width.
Test: open settings->display. click or press "Brightness Level" and
check that the brightness slider UI takes the full width of the right
hand pane of settings
Fixes: 303633970
Change-Id: Id40112c652e518b14cf000c791b7965bbb0991cd
It's possible that in the future the peak refresh rate setting will have multiple values (e.g. 90, 120). For that reason, we shouldn't convert it to a boolean like in the previous CLs (ag/24604787, ag/24604847).
- set peak/min refresh rate to infinity if it's the highest refresh rate so that when we restore the setting on another device, we also choose the highest refresh rate
- back up peak/min refresh rate and add validators
- upgrade settings in SettingsProvider
- create a utils class - RefreshRateSettingsUtils
Bug: 211737588
Test: atest DisplayModeDirectorTest
Test: atest ForcePeakRefreshRatePreferenceControllerTest
Test: atest PeakRefreshRatePreferenceControllerTest
Test: atest SettingsBackupTest
Test: atest SettingsProviderTest
Test: atest RefreshRateSettingsUtilsTest
Change-Id: Ie1d8cfc76e42c7d98c4a36743463ccaf3ca5d483
