Make it possible to customize the maximum screen timeout.
Added a configurable max timeout value which, if provided, will
limit the predefined timeout values.
Leverage code from aosp.
Flag: EXEMPT bugfix
Bug: 309512299
Test: atest ScreenTimeoutSettingsTest
Change-Id: Ibb180c89489fe890f1929bdefd5ced87a9566f07
Added `display_color_mode` listener to Colors preference. As a result,
it becomes reactive and updates its color mode value summary.
Flag: EXEMPT minor change
Bug: 397659800
Test: changed color mode using `adb` commands and verify that Colors
summary reacts and print correct color mode
Change-Id: I963768e3dbb43b547ec53e6445b2791ec0f57cff
1. Refactor Color Mode by moving color summary functionality to the ColorModeUtils
class.
2. Migrated `ColorModeUtils` from Java to Kotlin.
3. Changed ColorModePreferenceControllerTest according to changes
Bug: 390644464
Flag: EXEMPT refactoring
Test: atest com.android.settings.display
Test: atest -c packages/apps/Settings/tests/robotests/src/com/android/settings/display/colors/ColorModePreferenceControllerTest.kt
Test: atest -c packages/apps/Settings/tests/unit/src/com/android/settings/display/ColorModePreferenceFragmentTest.java
Change-Id: I55ac6129b93e4e35bd58f0313215b711ce954c0a
Elements on the subpage get disabled if there are no enabled shortcut targets for the relevant type.
In the case of A11y button, the items on its fragment become unsearchable when the setting is disabled.
Test: Manually verify conditions described above & in bug
Bug: 349180207
Flag: com.android.settings.accessibility.fix_a11y_settings_search
Change-Id: Id39e2eda6c9d1de4cdbfcbc22b8a1f443e2822d9
Root cause: there's a mismatch in how visibility is determined for
the AutoBrightnessPreferenceControllerForSetupWizard. The
getAvailabilityStatus method and the displayPreference method
(specifically the preference.setVisible call) use different
conditions for showing the preference.
Solution: To ensure consistency, I propose aligning these conditions
by incorporating an aconfig flag check in both places. This will
prevent unexpected behavior and make the logic clearer.
Bug: 389011125
Flag: com.android.settings.accessibility.add_brightness_settings_in_suw
Test: atest AutoBrightnessPreferenceControllerForSetupWizardTest
BrightnessLevelPreferenceControllerForSetupWizardTest
Change-Id: I004bfe8b1e039734356715c971f0bfbe56ffa9db
Let the redirect highlight function work from Turbo app.
NO_IFTTT=Catalyst migration
Test: devtool, atest AutoBrightnessScreenTest
Bug: 390525596
Flag: com.android.settings.flags.catalyst_display_settings_screen
Change-Id: Id7261d8a51368c45b7e23fee911565a226b30779
The EDT toggle will be an subsetting in the DarkTheme settings page
- When the Dark Theme main toggle is on, we check the EDT setting to
decide applying normal DarkTheme or EDT now.
- The EDT preference is disabled when DarkTheme is off
Bug: 368721320
Flag: android.view.accessibility.force_invert_color
Test: atest ToggleForceInvertPreferenceControllerTest
DarkModeSettingsFragmentTest
Change-Id: I64e47f92b14ee24a91f469cb55c7bb1285f05c62
By default if a RestrictedPreference is restricted then the preference
becomes disabled but still visible. But for brightness preferences in
A11y SUW we'd like to hide them if they're restricted and disabled,
since it's meaningless to show disabled items in SUW.
To achieve this, in PreferenceController#displayPreference we check the
whether the preference is RestrictedPreference and restricted, so we can
decide whether to hide it. Besides, if the preference is restricted and
we hide it, in PreferenceController#getAvailableStatis we also return
CONDITIONALLY_UNAVAILABLE to make consistency.
Bug: 384620216
Flag: com.android.settings.accessibility.add_brightness_settings_in_suw
Test: manually
atest AutoBrightnessPreferenceControllerForSetupWizardTest
atest BrightnessLevelPreferenceControllerForSetupWizardTest
Change-Id: Ifb68b4d64fc111d91a23457882a006002173d232
Revert submission 30375632-revert-30294757-catalyst_battery_percentage-RPJNJOPEZI
Reason for revert: the failures is part of the robolectric issue b/378822459. Tested locally that the change is not breaking ClockworkSetupWizardRoboTests.
Reverted changes: /q/submissionid:30375632-revert-30294757-catalyst_battery_percentage-RPJNJOPEZI
Change-Id: I2210002924650cb54c55a41be25d97a3997c065e
Revert submission 30294757-catalyst_battery_percentage
Reason for revert: <Potential culprit for b/378858348 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.>
Reverted changes: /q/submissionid:30294757-catalyst_battery_percentage
Change-Id: I17a124619a1d6c7b6930a1c26c2b84c1a52ce8f7
Migrate the AutoBrightnessPreferenceController to be a Catalyst type preference.
Test: atest AutoBrightnessScreenTest
Bug: 374712065
Flag: com.android.settings.flags.catalyst_screen_brightness_mode
Change-Id: I80d17a4f7fae237825ab84d1f428614affcb9065
The system property is shared within JVM, change system property in a
test case might break test cases in another test class. To address the
issue, introduce SystemProperty helper class to back up and restore the
system properties in tests.
Bug: 373177618
Flag: EXEMPT Test only
Test: atest SettingsRoboTests
Change-Id: I15539ce5ac425f35571d796baa25f259df1b601f
Updates tests that use PosturesHelper to return both
the correct configuration values as well as the values
returned through the DeviceStateManager APIs
Flag: android.hardware.devicestate.feature.flags.device_state_property_migration
Bug: 336640888
Test: atest SettingsRoboTests
Change-Id: I23e7446de719f11c99a4f747e189e11405b203ef
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
- 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
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
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
- 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
- Fix the test case failed in the
ControlsTrivialPrivacyPreferenceControllerTest.
- Use the correct paramter in the PackageManager.resolveActivity API.
Fixes: 300378707
Test: atest ControlsTrivialPrivacyPreferenceControllerTest
Change-Id: Id80dfb95ceffb048461b79d2d5ceb67100f83cd5
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
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
