When ring volume is separated from notification, a new xml preferece and
controller is needed for it, so that the settings search can show/hide
the slice correctly.
1. Use a separate preference and controller for ring volume (vs ring &
notification combined)
2. Notification slice in settings no longer grays out when ringer mode
is set to mute or vibrate.
3. Introduce an abstract RingerModeAffected preference controller class
to factor out duplicate code among ring, notification, and separate-ring
controller classes.
Bug: b/259084354
Test: make ROBOTEST_FILTER=RingVolumePreferenceControllerTest
RunSettingsRoboTests -j40
make ROBOTEST_FILTER=SeparateRingVolumePreferenceControllerTest
RunSettingsRoboTests -j40
make ROBOTEST_FILTER=NotificationVolumePreferenceControllerTest
RunSettingsRoboTests -j40
make ROBOTEST_FILTER=VolumePanelTest RunSettingsRoboTests -j40
make
ROBOTEST_FILTER=RingerModeAffectedVolumePreferenceControllerTest -j40
Known Issue:
1. When streams are separate and ring volume set to mute/vibrate,
notification is set to zero, but not disabled. So it can be turned on
by user (and in settings the icon will stay mute/vibrate instead of
changing to the normal notification icon).
2. In the above scenario after notification is unmuted in settings,
the notification icon continues to stay vibrate/mute -- should change
to the normal notification icon.
Note: This feature is controlled using a boolean DeviceConfig flag:
systemui/"volume_separate_ring". The default value is 'false', which is
meant to keep the experience the same as before. It will be set to
'true' for teamfood and dogfood. Eventually the flag will be removed and
the code in the 'true' branch will prevail.
Change-Id: Ibec871eafeef4081e96c5e0dd04535565d50a077
This change makes it that the ScreenSaverPreferenceController extends
BasePreferenceController so that it can be readily used and pointed to
from an xml file.
Bug: 261627295
Test: atest ScreenSaverPreferenceControllerTest
Change-Id: I95487f2f49a23422fff46f30b0cfa287582a547b
Settings app must not start an deep link Activity if
1. The deep link Activity is not exported.
or
2. Calling package does not have the permission to
start the deep link Activity.
Bug: 250589026
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SettingsHomepageActivityTest
Change-Id: I9a3bddfa5d9d1d2e924dd6f3e5e07dca6c11664f
Merged-In: I9a3bddfa5d9d1d2e924dd6f3e5e07dca6c11664f
Bug: 244423101
Test: make RunSettingsRoboTests ROBOTEST_FILTER=BluetoothSwitchPreferenceControllerTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=BluetoothDashboardFragmentTest
Test: manual test by test apk
Change-Id: I13562d227e06627fac33239a9d21fd405a18d012
(cherry picked from commit c706aa6108)
Merged-In: I13562d227e06627fac33239a9d21fd405a18d012
Previous default was to disable the feature.
Bug: 260123067
Test: verified locally on device that the default is 1 minute for a new
user
Change-Id: I8f577d62b729eb1c1a0579a7b4eb6b50f7f7f0d8
The flag is enabled by default. And will be disabled on foldable
devices.
Test: locally
Bug: 236249360
Change-Id: I8c90533f6011531a4f00af5f2514579638604067
The summary for screensaver preference is updated to, e.g. "On / Art
gallery".
Bug: 261907383
Test: 'make -j64 RunSettingsRoboTests \
ROBOTEST_FILTER="com.android.settings.dream.DreamSettingsTest"'
Change-Id: I40483f266c42a6e49e513208ba513d469d67f85a
Merged-In: I40483f266c42a6e49e513208ba513d469d67f85a
- The WifiEntry already support multiple security types simultaneously from framework
- For backward compatibility, WifiEntry supports both getSecurity and getSecurityTypes methods
- However, the getSecurity method can only return one type of security, causing NetworkRequest to fail to match another type of security
- WifiEntry: getSecurity:WPA2 // getSecurityTypes:{WPA2, WPA3}
- ReqeustNetwork: getSecurity:WPA3
- Need to use getSecurityTypes to check for matching WifiEntry
Bug: 205943818
Bug: 249713442
Test: manual test
make RunSettingsRoboTests ROBOTEST_FILTER=NetworkRequestDialogFragmentTest
Merged-In: I8848ccd1cb0589284a48ddaa77591f5bf3b41932
Change-Id: I8848ccd1cb0589284a48ddaa77591f5bf3b41932
(cherry picked from commit a88c064842)
Doing this will open the correct screen when clicking on "Shortcuts"
under Settings > Display > Lock screen.
Fix: 258471384
Test: manually verified that clicking on it opens the wallpaper picker
experience with the correct page showing.
Change-Id: I627bcb9c9fac7a834f1c9d9cb36b73a6c8817af5
When developer options switch is off, a user including guest user
can still configure media transcoding settings via slices.
Bug: 244569778
Test: manual
Change-Id: I3d70045c2498e683bf615cbe521e2f98d50b7eec
(cherry picked from commit a94e8d0bc7)
In ag/20427460, we made ControlsTrivialPrivacyPreferenceController, which controls this setting, be UNSUPPORTED_ON_DEVICE if customizable lock screen quick affordances are enabled.
This wrongly removes this setting from the Settings app and there is no new UI where the user can control that anymore. What this means is that, once users upgrade to an Android build with our feature, they will forever be stuck with whatever they last chose for "Control from locked device".
This CL brings that back but changes the behaviour a bit such that, if
the quick affordances feature is enabled, this setting is never
disabled.
Fix: 260722836
Test: Unit tests added. Manually verified that the setting is visible
and enabled if the feature is enabled, even if the current selection
does not include the Home quick affordance and that if the feature is
off, the setting is visible but disabled if the main setting is off (old
behaviour unchanged).
Change-Id: I2e53123b3b7a2896699aeaa13b0c7d5a1c8a9c92
