When configuring CBRS profiles this dialog / notification will be
dismissed after configuration is done, to avoid confusion.
Bug: 142092510
Test: manual and unittest
Change-Id: Iaf30062f555ec2c119c4aafd6aa013e73b5253f0
Merged-In: Iaf30062f555ec2c119c4aafd6aa013e73b5253f0
When configuring CBRS profiles this dialog / notification will be
dismissed after configuration is done, to avoid confusion.
Bug: 142092510
Test: manual and unittest
Change-Id: Iaf30062f555ec2c119c4aafd6aa013e73b5253f0
Bug: 147206736
Test: make RunSettingsRoboTests ROBOTEST_FILTER=DisabledSubscriptionControllerTest
make RunSettingsRoboTests ROBOTEST_FILTER=MobileNetworkSwitchControllerTest
make RunSettingsRoboTests ROBOTEST_FILTER=SimSelectNotificationTest
Change-Id: If740c2d7ea2c1392d5fe538091ea6e5c4575ad26
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
When the phone is in DSDS mode and the user tries to send an MMS message
from the SIM that isn't the default for data, we need to pop up a
notification letting them know that the action can't succeed unless they
turn on the advanced option to allow data use for MMS messages. This
notification was using the operator name instead of the subscription
display name, so it didn't reflect any renaming the user might have done
to keep track of their SIMs, which is obviously confusing especially if
they have two different SIMs for the same carrier. This CL switches to
using the subscription display name in this notification.
Fixes: 134771858
Test: make RunSettingsRoboTests
Change-Id: I6995bf9dd6d5e9544e26f0d8e30e97c4e73ab783
In Settings, catch the intent from Telephony about SIM combination
warning and show a notification about it.
Bug: 132631355
Test: manual - have two cdma capable subscriptions active, make sure
the notification is sent, and tapping on it leads to the helper page.
Change-Id: Ifd0e13781e4afc3bfd82415b3e51fd10176d9f9d
Adding a notification in SimSelectNotification that will be triggered
when receiving a enable MMS request. Tapping on the notificaiton will
lead to the subscription setting page.
Bug: 130222866
Test: manual -- have a test app that sends the intent when mobile
data is turned off. And verify that the heads-up notificaiton is shown
and that it will lead to subscription setting page.
Change-Id: Ia80e8e5ab20adf78a31647a23cb2ba8dac690e41
The SimDialogActivity is used to ask the user questions about which SIM
card to use for various services like calls, SMS, and data. In some
cases of SIM changes (eg when a SIM is added or removed), the telephony
stack sends a broadcast that SimSelectNotification listens for so it can
pop up a general "SIM cards changed" notification, and we additionally
want to bring up an interruptive dialog to ask the user a specific
question. This might happen for instance when we want to ask the user's
permission to turn on data on a SIM.
Recent DSDS changes in the telephony stack have meant that we
accidentally create several stacked copies of this dialog, because they
send several broadcast updates as information about SIMs asynchronously
changes. For instance, we might initially detect a SIM with a generic
name of "CARD 1", and shortly after discover the actual carrier name. So
what we really want is to put up the dialog, and update it as
information changes.
This CL makes SimDialogActivity use launchMode="singleTop" so that
additional copies of the activity won't be launched. Then it internally
enforces only showing one dialog per type of request (calls, SMS, data,
or preferred sim). If we get a request for a dialog that already exists,
we just update it instead of creating a new one for that type. So there
can still be a stack of more than one dialog, but each one will be
asking a different question.
This also refactors the monolithic, somewhat confusing code for showing
the various types of dialogs into a more clearly separated class
hierarchy, and switches to using DialogFragment for the dialog.
Fixes: 126596081
Test: manual (start with device in DSDS mode with 2 subs, remove SIM
card and re-insert it)
Change-Id: I0dbc41dc3b15015389823a24df10bbff08ec6615
