The PreferredSimDialogFragment did updateDialog after SimDialogActivity
was finished. It caused the settings crash. This is similar to b/184899699
Bug: 220803944
Test: build pass
Change-Id: I9a5964400a63053e362632944b9e7aa8ec1bbea8
(cherry picked from commit 70bf76a436)
The dialog can be dismissed by either the framework automatically (i.e.
when the screen is rotated) or when the subscriptions change.
If both of these things happen while the class is not deleted, then
dismiss() will be called twice and there will be a crash
Bug: 184899699
Test: atest -c SettingsUnitTests
Change-Id: Ibaef59696feb566664a424f65f806396f02497e8
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
