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
Rather than check for the state of the work profile in
LockScreenNotificationPreferenceController#handlePreferenceTreeClick, do so in
the RestrictedListPreference#performClick.
The drawback of checking the state in handlePreferenceTreeClick is that the
preferences are displayed first and then the requirement to unlock/enable the
work profile is displayed on top of it.
This is rather poor UX, so switch to doing the check in performClick and
returning early if the work profile needs to be unlocked/enabled.
This is similar to Patchset 1 from ag/3805482.
The main difference is that the user is returned to the settings screen
both after enabling the work profile and unlocking it.
Test: Manually with TestDPC
Test: atest SettingsRoboTests:RestrictedListPreferenceTest
Bug: 77408805
Change-Id: Id168911b082fffac193cd7c7a658ab92d6ce2c15
Require that the work profile be started and unlocked before the user
can change the notification settings for the work profile.
That prevents leaking of notifications from the work profile, which
could happen when the user set the work profile notifications to show
even if the profile was unlocked (an example scenario is a family member
of the user using the device while the work profile is locked).
Test: Manually with TestDPC
Bug: 75252682
Change-Id: I300d001b7439c0a1d0130d7dbc9ec4c2430be227
Option to not show notifications is still available for
device-wide locks screen notification settings.
Also s/On lock screen/When work profile is locked/ for work
notifications since it applies not only to lock screen but to
notification shade as well.
Bug: 64829587
Test: make RunSettingsRoboTests
Change-Id: Ie3ec461f4c8887a5a49cd92b5350ea683f701027
- remove duplicate settings
- move recent app list to bottom of the screen
- change dropdown fields to dialogs
Test: manual, make RunSettingsRoboTests
Change-Id: Ia07d56e39be10c7b8be58f9ec35114ca2eab7d5c
Fixes: 72402499
And create PreferenceControllers for each setting
The page is still pretty janky and controllers are invoked manually.
Next CL will clean these up.
Bug: 32953042
Test: TODO
Change-Id: I1d7478324f5de4fdb464d79f89086f7e79c0ee67
The implementations have been imported into SettingsLib. Setting's copy
can now be removed, which this change also does.
Test: Manually check battery status, which uses FooterMixin, looks OK.
make RunSettingsLibRobotTests && make RunSettingsRoboTests
&& make RunSettingsGoogleRoboTests
Change-Id: I6539605fdad80d156ff5ff249e68df4a1c412067
Each time we refresh the security preference page, get the current
summary text from "On the lock screen" and populate to Lock screen
preferences summary.
Bug: 36540633
Test: make RunSettingsRoboTests
Change-Id: I317e3892b35b30981b62f7b7aee9cfdacd04a3ed
When updating preferences managed through PreferenceController, the
fragment should skip prefs that are not available.
Bug: 32255863
Test: RunSettingsRoboTests
Change-Id: I2f9b6ddf8c78d40068dc18f07e60672dcba4474a
- Refactored ConfigureNotificationSettings to be more modular
- And tests
Bug: 31799948
Test: RunSettingsRoboTests
Change-Id: I2ecd8930a6aa501c1e625cab6ed25a46f3437e85
