- Revert "Allow OEM customizing max screen timeout value."
- Use separate timeout list for screen timeout and lock timeout.
This reverts commit f57f490aa6.
Fixes: 113346164
Test: manual
Change-Id: Ifbb054c232c47455ae82e3ed817f9c1e96f694cf
This means that in some cases RestrictedLockUtils has to be used and in
some RestrictedLockUtilsInternal.
This causes a lot of trivial code changes.
I also updated the ordering of the imports in all affected files.
Bug: 110953302
Test: Built
make -j RunSettingsRoboTests
Change-Id: I9bdf8b89134f853bae4f38c81af436715c73e924
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
- The display timeout dialog will only show values that are allowed by the
admin. If the current display time out is greater than the max timeout set by
admin, it becomes an invalid selection. In this case, instead of not
selecting anything, set the default to the last available item.
- move TimeoutListPreference into display package.
Change-Id: I6c88f72ff2b0afe8605800074fd4626bbb16bee0
Fixes: 110104437
Test: make RunSettingsRoboTests
This is a follow-up for http://ag/3123412
Test: make ROBOTEST_FILTER=LockAfterTimeoutPreferenceControllerTest RunSettingsRoboTests
Test: make ROBOTEST_FILTER=TimeoutPreferenceControllerTest RunSettingsRoboTests
Bug: 63908311
Change-Id: I27631743d52163f3b6d1589b427ba617e74725a9
Change preference keys of duplicate settings between
display and battery to avoid duplication in search.
Bug: 33701673
Test: make RunSettingsRoboTests
Change-Id: I56c82e9e7f163d345065ca478849de9b14c173fe
When updating preferences managed through PreferenceController, the
fragment should skip prefs that are not available.
Bug: 32255863
Test: RunSettingsRoboTests
Change-Id: I2f9b6ddf8c78d40068dc18f07e60672dcba4474a
- Add a ProgressiveDisclosureMixin that contains all logic for collapse
preference list when it's too long
- Refactored PreferenceController's updateState to take a preference
instead of PreferenceScreen, because with progressive disclosure the
preference can either be in screen or the mixin. DashboardFragment is
responsible finding the preference before passing it to controller.
Bug: 32255863
Test: RunSettingsRoboTests
Change-Id: I6713abd61c954ce12732902e5b3ca4d4c0b1563e
- Added a activity-alias pointing to displaySettings as top level
setting item.
- Refactored all preference logic in DisplaySettings into
PreferenceControllers. During fragment onAttach it installs all
controllers, and during onResume it updates preference state. Each
controller listens to its own preference change event.
Bug: 31800242
Test: RunSettingsRoboTests
Change-Id: Ibc9bf200c5acce7c4ae9292340822afee27a3a28
