We decided to use the list preference after all due to
some devices not supporting various combinations of AP
configurations. This change makes it so that there are
three different UIs depending on the configurations
which are supported.
- 5.0 GHz unsupported: disable the preference and just
set the value to 2.4 GHz
- all supported, no dual mode: allow the user to choose
EITHER 2.4 GHz or 5.0 GHz
- all supported, dual mode: allow the user to choose
2.4 GHz or BOTH 2.4 GHz & 5.0 GHz with 5.0 being
preferred
Test: atest SettingsRoboTests
Bug: 80315296
Change-Id: I888d35811a98b8cf0155a3cb96c42ff762763378
- It retrieves the flashlight status from Settings.Secure.
- It uses the broadcast relay to update flashlight status
without action on the slice.
Test: robotests
Change-Id: Ib4d636541f5166b8634326cce76aed5665989b76
Fixes: 74913192
When we query the package manager for activities that can handle the
web data uri, different capable activities within the same package will
be returned as separate entries. However, when we show the default
browser apps to the user, the entries are simply base on package name.
So, if there are multiple activities within the same package that can
handle the web data, they will be shown as duplicate entries.
When we process the resolved activities, check the corresponding package
name for duplicate entries before adding it to the default browser list.
Change-Id: I4e1f1e1ea22781efe24d791b367246423ca7a3c4
Merged-In: I70c88866eb3d5fe6466554749e23c85f429dd30c
Fixes: 84207432
Test: make RunSettingsRoboTests
When running monkey, the authority in the preference might not have been
properly set. Add a check for valid authority before trying to update
the sync automatically setting.
Change-Id: I59f910565fc9f128e86bd92337135fe46fed12e1
Fixes: 80551551
Test: make RunSettingsRoboTests
When we query the package manager for activities that can handle the
web data uri, different capable activities within the same package will
be returned as separate entries. However, when we show the default
browser apps to the user, the entries are simply base on package name.
So, if there are multiple activities within the same package that can
handle the web data, they will be shown as duplicate entries.
When we process the resolved activities, check the corresponding package
name for duplicate entries before adding it to the default browser list.
Change-Id: I70c88866eb3d5fe6466554749e23c85f429dd30c
Fixes: 84207432
Test: make RunSettingsRoboTests
The full page verion of prevent ringing is still searchable.
- Created a new controller for parent entry.
- On the child controller, inherit the same getAvailabilityStatus() but
override AVILABLE_UNSEARCHABLE to AVAILABLE so it becomes searchable.
Fixes: 72748524
Test: existing robotests for PreventRingingPreferenceController
Change-Id: Id2454db110c81b59fa4a98338602b03de0812f8a
- Share the same set of pref controller between main UI and search
in AccountDashboardFragment.
- Update WorkSoundPreferenceController to actually do something for
updateNonIndexable() method.
- LockscreenDashboardFragment to also suppress "Work notification" header. I
think we just missed it previously.
Change-Id: Ifa6f9b2077c9810ffff33f240929f418d4a8a5aa
Fixes: 62167659
Test: robotests
- Make the entire gesture setting page unsearchable. This is safe
because each row in gesture setting page lead to a child page, we are
only removing duplicates.
- Make the pref controller for System -> gesture return
AVILABLE_UNSEARCHABLE so it's also suppressed.
- Suppres the parent page for adaptive brightness.
Bug: 72748524
Test: manual
Change-Id: Id7317f5f126af88b1bde8d87b8a206d9909df904
Systemui nav buttons set the insensity from launcher and -1 window but
fallback home does not. This causes services to pass the wrong flags to
system ui to apply the incorrect tint that would later be fixed by
launcher and sometimes lead to color flicker.
Fixes: 79776583
Test: use bright color wallpaper (nav dark icons) and reboot phone,
unlock with pin/pass/finger and view nav buttons
Change-Id: I86906cd1b5af5d078499a1392c260aa186b2eee8
WifiCallingPreference Slice Provider:
1. If Wifi calling is not enabled - display message to user
to enable Wifi calling
2. Else if Wifi preference is not editable - return a null
Slice
3. Else provide a slice with rows - first row giving current pref
information, followed by preference items (in each row).
wifi_only is displayed only when it is allowed to display it.
Each row with preference item has specific intent action.
WifiCallingPreference Slice BroadcastReceiver:
1. If only Wifi calling is enabled & Wifi preference is editable &
there is a change in current value modify wifi pref setting
2. And Ask to re-query the slice in one second to display
updated settings if 1 is valid or display appropriate message.
Clean-up:
1. Return null instead of non-actionable slices.
2. Use getText to get string resources.
3. Remove unnecessary extra variables.
Bug: 79548264
Test: Use support-slices-demos-debug.apk to test on device
Change-Id: I186f19be2007c2331eaf6195e70b4a9c635adf9e
Gathered user info to verify that user is not a guest. If user is a
guest (and only a guest: other alternate users may use the feature),
they are not allowed to load the nfc_payment_settings xml file.
Change-Id: I5700b9cd4b639b031b6d464827d16f4ea4cfa03f
Fixes: 80111261
Test: Robotests
This reverts commit 5aab8d9ee1.
Reason for revert: This setting is for internal QC purpose only
Bug: 80007047
Change-Id: Id5f01e5de94ffaa86de1e96f6bde1092b0c586a2
During a run of the setup wizard, a tester one time encountered a case
where the 'Accept Legal terms' screen followed by the Security screen
showed for a second time after already confirming the pattern in the
Security screen. The logs showed a crash in
FingerprintEnrollFindSensor.onActivityResult which could only have
happened if it was called with a requestCode of CONFIRM_REQUEST and a
resultCode of RESULT_OK, but a null Intent.
This isn't an expected flow, and AFAIK we haven't been able to reproduce
the original problem, but it seems reasonable to at least not crash in
settings, so this CL defends against that crash by just calling finish()
in this case, which means the caller who started the
FingerprintEnrollFindSensor will see the default result code of
Activity.RESULT_CANCELLED.
Bug: 80099085
Test: make -j RunSettingsRoboTests
Change-Id: I94401eabe295e4d5396cf7d324fbf1902dc45f6d
Add Slices for Enhanced 4G LTE
Enhanced 4G LTE Slice Provider:
Create slice to display appropriate message with further instructions
Enhanced 4G LTE Slice Broadcast Reciver:
1. Change the setting via ImsManager
2. Ask to requery the slice in one second to display updated settings if 1 is valid or display appropriate message
Bug: 79270171
Test: Robotests
Test: Use support-slices-demos-debug.apk to test on device
Change-Id: I48d412de94d5d9f1ad42a299691ec5cf8001c6a1
