On the SIM details page, the preference leading to a page for
configuring wifi calling will appear based on the results of the
MobileNetworkUtils#isWifiCallingEnabled helper function. That helper
uses the ImsManager to check several conditions, among them both
isWfcEnabledByPlatform and isWfcProvisionedOnDevice.
The page for configuring wifi calling has a tabbed UX, with one tab for
each active subscription that supports it. The WifiCallingSettings class
gets a list of the active subscriptions to determine which tabs to show,
and removes any that don't support wifi calling, but was only using the
isWfcEnabledByPlatform test to do so. This is a problem because the code
for showing the contents inside the tab, in WifiCallingSettingsForSub,
includes a sanity check of isWfcProvisionedOnDevice and calls finish()
if that returns false.
What this meant in practice is that if you happened to have 2
subscriptions where one returns true for both isWfcEnabledByPlatform and
isWfcProvisionedOnDevice, but the other only returned true for
isWfcEnabledByPlatform, then you'd never be able to succesfully use the
wifi calling page at all because the tab for the subscription you
*aren't* trying to configure would always call finish() early.
The right long term solution to this problem is probably to remove the
tabbed UX entirely from this page, since we probably don't need it given
the overall new multi-SIM UX. But there may still be legacy uses and
that is likely a bigger change than we want to make right now.
As a stopgap, this CL just adds a check of isWfcProvisionedOnDevice to
the code for filtering out ineligible subscriptions from the tabbed
interface, which we should have always had anyway.
Fixes: 135591718
Test: make RunSettingsRoboTests
Change-Id: I656c3d3fb30cb6fabcb86685eae38c5f0cd0c6f2
We don't rely on FooterPreferenceMixinCompat
to create footer preference in dashboard fragment.
Instead, declare a FooterPreference explicitly in
xml of screen.
Test: visual, robotest
Bug: 124129485
Change-Id: I4c5b60c3926583eb0d9f0d4cd6996bf169d6408c
- We didn't reset reset radio button state when user click back
while dialog was popped. Change the UI, when user really accepts the
dialog content, then changes radio button state.
- Migrate TtsEnginePreferenceFragment to RadioButtonPickerFragment
Fixes: 135588938
Test: manual
Change-Id: Ia824e08d59c77a23e6590ff0f5b7d897a73a1ff8
Fixes: 134965754
Test: Verified slice appears when not enrolled.
Test: Verified slice does not appear when enrolled.
Test: Verified slice disappears after clicking on icon and going back
to settings page.
Change-Id: Id1c4458742ab622df8d5881e926fe54684b36843
This reverts commit 43374eabb8.
Reason for revert: No longer needed because we are using whitelist for
SMS permission
Fixes: 135213238
Test: presubmit
Change-Id: I182be4a1136521f325866e70e875439c17816ef2
For some kinds of telephony changes that might happen while we're
already showing one of these dialogs, we already get sent a new intent
for the dialog which we internally convert into a refresh of the dialog
contents instead of stacking a new copy on top of the old one.
But it turns out there are some other cases where the telephony stack
doesn't send a new intent for the dialog but *does* send a change event
through the SubscriptionManager, and we want to respond to those as
well. This CL adds a listener for those events.
Fixes: 135276696
Test: make RunSettingsRoboTests
Change-Id: Ifb93ae95f45fda5831e112306dd9361ccaa5119c
(cherry picked from commit 6a1d7e60ac)
We read from SettingsProvider to decide whether flashlight slice is
available. However, when switching to the second user, FLASHLIGHT_AVAILABLE
will be null. The default was 0 which causes the slice returning null,
so we have to set it to 1 when there is a physical flash unit to be
consistent with system ui.
Fixes: 134734608
Test: robotest
Change-Id: I981461b1b66e6e273e13a9cbcba96e3ccf0aec68
For injected tiles, allow clients to provide dynamic title from
contentproviders similar to dynamic summary.
Fixes: 131837802
Test: robotests
Change-Id: Iacc80db5d003473cf59ede67d88441947a834888
For some kinds of telephony changes that might happen while we're
already showing one of these dialogs, we already get sent a new intent
for the dialog which we internally convert into a refresh of the dialog
contents instead of stacking a new copy on top of the old one.
But it turns out there are some other cases where the telephony stack
doesn't send a new intent for the dialog but *does* send a change event
through the SubscriptionManager, and we want to respond to those as
well. This CL adds a listener for those events.
Fixes: 135276696
Test: make RunSettingsRoboTests
Change-Id: Ifb93ae95f45fda5831e112306dd9361ccaa5119c
- clean up the format of accessibility_settings
- To leverage the existing TtsPreferenceController and
FontSizePreferenceController
- pull out the logic of magnification from AccessibilitySettings
Bug: 135056871
Test: manual, robotest
Change-Id: I414fa7a04fd558d3a3a8b5e157469c198a772732
To reduce the complexity of AccessibilitySettings, we are planning to
create a bunch of preference controllers. First of all, we are converting
lock screen preference to a preference controller. The rest part will be
uploaded soon.
Bug: 135056871
Test: robotest, manual
Change-Id: I6079136f3d08934c9a5363eb4d0e0ade29f8ba99
That is caused by layout xml changes. The radio button was clickable
in old xml resource. But it is not clickable in new xml resource.
Therefore we can't receive click callback. Fixed by changing
Radio button state when preference is clicked.
Fixes: 135285101
Test: manual, make RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.tts"
Change-Id: Idd7bf37d9ccbc1b56d41978d19dc05c8a81cc49a
