Solving the issue that setting preferred APN from GDCT triggers
back APN change event and force unnecessary data call disconnects
and setups.
The new URI is added in Telephony Provider so ContentObserver
callback (results in onApnChanged) will not be triggered.
Bug:5448858
Change-Id: I4c0bcf32cec69cf1d0a0430f7a27495b89e93625
Restores functionallity from Gingerbread. We should tear down when the
enabledcount goes to zero, but we should always notify and attempt to
switch back to default when indicated.
bug:5830081
Change-Id: Ib8469bb5369da21e8cc05fb755b2d7e24c8e02a6
Found that if the type were not lowercase it wouldn't match.
That's silly. Do case-insensitive compares.
bug:5525764
Change-Id: Ibfe6be6c34116e00931594ec317fe192e1756ade
To make it easier to test tethering, have fetchDunApn
return null when the system property
net.tethering.noprovisioning is true.
Change-Id: Id6162967c6b8b25f04380fe009961c150fa714ef
Instead of throwing an exception when the connection between
the DCT and a DC is broken (i.e. its null) it is treated as
an error with a new cause. And thus will be handled as other
typical errors.
Bug: 5798643
Change-Id: I46f1660ae78f118b54ab62504809723ca302b2ef
Put enhancements on data stall polling logic in ICS so that
stall recovery can kick in earler while screen is on.
Bug: 5767897
Change-Id: I4683fc45c0161f4374749c8e5840261c19a48f77
While BIP data call setup is still handled in RIL/Modem,
this patch is adding support of Alpha tag display on UI.
Alpha tag is optionally included in "OPEN Channel", "Close Channel",
"Send Data" or "Receive Data" command.
"Open channel" will be notified via RIL_UNSOL_STK_PROACTIVE_COMMAND
which requires TERMINAL RESPONSE based on user input.
"Close channel", "Send Data" and "Receive Data" commands
are send via RIL_UNSOL_STK_EVENT_NOTIFY just to display
transient notice.
Bug:5165510
Change-Id: I873e55274c860886bc816ce6fb07cb882d339214
Radio state reflects the state of the modem. SIM_READY, RUIM_READY,
NV_READY are subscription states and it is possible that the new cards
have multiple subscriptions. Remove the SIM states from Radio State and
introduce a new VOICE_RADIO_TECH message to identify the exact voice
technology. SIM states will continue to be identified from the
SIM_STATUS messages.
Change-Id: Ia67d54f43b6c3340d9cf5c27fcb6f7ef49ef4d40
Old code would detect we were in a retry loop and ignore other active
connections we could share. We really want live shared connections to
dominate over retrying disconnected ones.
bug:5525764
Change-Id: If93383c52024113eec595b31e46897d1fcabc44c
This looks to fix a problem where the nv_data.bin file
file gets corrupted. When greping a radio log for "md5" if something
like following is seen:
RIL(s) : load_md5_state: MD5 state 1
RIL(s) : check_md5:
RIL(s) : compute_md5: path /efs/nv_data.bin
RIL(s) : check_md5: MD5 fail. orignal md5 '628647a8e5c6cac2d586199417c0103c' computed md5 '58a635cbaf5fe4ffb2797aeaa2b32709' (rild)
RIL(s) : check_md5:
RIL(s) : compute_md5: path /efs/.nv_data.bak
It means that corruption was detected and a back version was used
which is ok. Apparently that backup version can have the default
network type revert to 2G only thus causing the symptoms reported
in b/5695729 where after taking an OTA 2G becomes the default.
By calling setCurrentPreferredNetworkType when the sim is ready we
can reset the the network type to 3G.
Note: I also tried calling setCurrentPreferredNetworkType in
EVENT_RADIO_AVAILABLE but that didn't work and we would see
the response to setPreferredNetworkType failing as the ril wasn't ready.
RILJ : setCurrentPreferredNetworkType: 0
RILJ : [0004]> REQUEST_SET_PREFERRED_NETWORK_TYPE : 0
RILJ : [0004]< REQUEST_SET_PREFERRED_NETWORK_TYPE error: com.android.internal.telephony.CommandException: RADIO_NOT_AVAILABLE
Bug: 5695729
Change-Id: Ibbd29cda0b201a8c08f4dcfa5cec211611e1d599
According to TS 22.030 6.5.2 "Structure of the MMI", the dialing number
can not end with #. The format is like *SC*SI#DN. Correct the mmi pattern
to exclude DN# case. With this fix, processCode() will tread *NNN#DN#,
e.g. *400#16 digit number# in bug 5622718, as USSD and send via
RIL_REQUEST_SEND_USSD.
bug:5622718
Change-Id: Ifc8d0edff4308602a5f3fc651cf116bf6bad3cbc
A request for a DUN connection should only use the carriers requested dun connection. Don't
share another connection unless it matches the carriers settings.
bug:5701374
Change-Id: I75a65fcfce1b218bd9ca4ce2ab85cbe850813321
Don't report that we're disconnected immediately if we're disconnecting when another
disconnect comes in. Remove this behavior from the default handler and add a catch
all "yeah, we're disconnected already" to the inactive state.
bug:5568633
Change-Id: Iff7ccde2069b47f8ad8255f3bca0292b80041388
Secondary nets sometimes come up with no routes, but parsing errors end up with null
routes getting added. Trim that away. Also added some dumpstate logging of the secondary
route tables and rules.
bug:5615697
Change-Id: I94c9d888bab958df44891b9117236436e046cc7f
CallerInfo.doSecondaryLookupIfNecessary() was assuming that SIP addresses
would always contain the character '@', but that's not always true since
the username/domainname delimiter can actually be "%40" (the URI-escaped
equivalent.)
This would cause the in-call UI to crash if you ever called a SIP address
like "xyz%40example.com".
TESTED:
- Make an outgoing call to the SIP address "xyz%40example.com"
==> The call ultimately fails, but the in-call UI no longer crashes when
it first comes up.
Bug: 5637074
Change-Id: I62d15a7ccd509924d38b780b92e657b9efa26125
This change updates isEmergencyNumberInternal() to always return false if
you pass in a SIP address, since the concept of "emergency numbers" is
only meaningful for calls placed over the cell network.
Previously we *did* try to compare SIP addresses against the list of known
emergency numbers, which caused bad behavior with SIP addresses that even
contained "911"/"112"/etc as a substring (since we were filtering out
non-dialable characters before doing the comparison!)
TESTED:
- Before this change, calls to "abc911def@example.com" or
"911abcdef@example.com" were incorrectly detected as emergency
numbers, and fail.
- After this change, SIP addresses like "abc911def@example.com" and
"911abcdef@example.com" work fine.
- Also, confirmed that this change doesn't break the restriction that
3rd party apps shouldn't be able to make emergency calls.
Specifically, I fired off ACTION_CALL intents (using the CallDialTest
activity) for a bunch of numbers *similar* to emergency numbers, and
confirmed that none of them actually resulted in an emergency call
being placed.
The specific ACTION_CALL intents I tested were:
"911" ==> Didn't place the call; brought up dialer instead
"tel:911" ==> Didn't place the call; brought up dialer instead
"911@foo" ==> Tried to start a SIP call (which failed)
"911%40foo" ==> Tried to start a SIP call (which failed)
"tel:911@foo" ==> Tried to start a SIP call (which failed)
"tel:911%40foo" ==> Tried to start a SIP call (which failed)
"911@example.com" ==> Tried to start a SIP call (which failed)
"sip:911" ==> Didn't place the call; brought up dialer instead
"sip:911@foo" ==> Tried to start a SIP call (which failed)
"sip:911%40foo" ==> Tried to start a SIP call (which failed)
Bug: 5515452
Change-Id: I6f9f8690b08564c53c7a76f480654477b475d94d
It may not be called from an app so the app context may not exist.
Check and grab the best one.
Also remove the log that nobody paid attention to if the constructor
is called again from the same process. One context seems to be as
useful as another.
bug:5572369
bug:5622514
Change-Id: Iad23b30c7c8fe5b8d1f81a1e060eaf0cd0e3019d
Fix a NullPointerException when sending a single-part SMS containing
characters in one of the enabled national language tables.
Also added a few log messages for several error cases to help with
debugging any future problems in the SMS dispatcher.
Bug: 5553544
Change-Id: I61c1cbe297b2e222027f0db7c833df6a03c2974a
