This is not perfect and only works if the CC is known via
the GSM radio and is only accurate if there is one time zone
per country. This does nothing to resolve time zone problems
for wifi only devices.
So this is a partial fix for bug 2896745
Bug: 2896745
Change-Id: I78f013836c4e4870b8b1016a8312f5adbe0d31c9
Remove notions of SimCard and RuimCard since they don't make sense
in the world of Uicc cards where each card can have multiple
3gpp and 3gpp2 subscriptions.
This change prepares code for the introduction of Uicc cards.
Change-Id: Ibab13004604f829328b73c177669b89ef97d3f25
Refactor SMS Cell Broadcast support to enable receiving CMAS warning
notifications over CDMA. The CellBroadcastReceiver app must also be
updated with the corresponding change. All cell broadcasts are now
delivered as a Parcelable SmsCbMessage object in the "message" extra
of the SMS_CB_RECEIVED_ACTION or SMS_EMERGENCY_CB_RECEIVED_ACTION,
instead of as a GSM/UMTS "pdu" byte array.
Existing functionality for ETWS and CMAS alerts over GSM/UMTS continues
to be supported using the new radio-technology independent SmsCbMessage
and related objects. Test cases are added to verify that valid and
invalid broadcast data is handled appropriately.
Unit testing discovered a bug in the BitwiseOutputStream utility class
used by the added test cases. When the BitwiseOutputStream object must be
expanded (in the private possExpand() method), the mEnd field is not
updated to the new array size. This causes a new array to be allocated
on every new write, and for all data beyond the original array allocation
to be replaced with zeroes. Fixed by adding a line to possExpand() to
update mEnd. Added a test case to BitwiseStreamsTest to verify the fix.
Besides the test cases, BitwiseOutputStream is only used by BearerData in
two places, both of which allocate a sufficient initial buffer. So the
bug in BitwiseOutputStream is not critical to fix for normal operation,
but should be fixed so that the test cases using it function correctly.
Bug: 5856308
Change-Id: Ie3e6af747976ce9b8a3e71e76fec71709cf86545
The racing condition happens between dial() returns and
the first GET_CURRENT_CALLS query gets handled.
If GET_CURRENT_CALLS gets handled before dial() finishs, the pendingMO can be set
to null in handlePollCalls() so that dial() will return null. This null connection causes
error in PhoneUtils.placeCall().
The Synchronized dial() and handlePollCalls() Methods will make sure the
dial() returns before the first GET_CURRENT_CALLS gets handled.
bug:6028290
Change-Id: I41b024760acb7dd13b342866180dffe3fdbe1c03
We have two sets of constants for network type. One used by the RIL can't
be changed without big pains with OEM/Radio vendors. The other has been published
as part of the framework and can't be easily changed either.
Separate the two so it's clear where one should be used versus the other.
bug:5717664
Change-Id: Ibf21f9165662e75557c7254fc9ad9a4870ba4af9
Backported from master, including a bug fix and a cdma enhancement.
Even if other people are sharing the connection (ie, carrier wants
default and tethered traffic on the same APN) stop using a carrier-
described APN when the tethering stops.
bug:5972599
Change-Id: I25e4831855e6b62c0c3ab3a6f4d4846aaee6ac50
Since CDMA doesn't use APN settings there was no place to say what a cdma
device's DUN connection would support, so by default normal device
originating traffic would be blocked on a tethering single-connection device.
With this change you can (via overlay) say that it supports everything
so mms and on-device browsing/email will still work even when on a dun connection.
The reason to allow both: some carriers will charge per byte for dun access
and so they don't want lots of non-tethering traffic used (costs the user alot)
but other carriers just use a dun connection to limit access to tethering, but
once there give unlimited data, so it makes sense to support everything there.
bug:5972599
Change-Id: I78fd7f3ac63c51a0560b659ed5ec219b10a93f8d
The LTE signal strength level is the smaller one
between lte rsrp level and lte snr level if both
rsrp and snr are valid.
The lte snr mapping are
Four bars: SNR >= 45
Three bars: 10 <= SNR < 45
Two bars: -30 <= SNR < 10
One bars: SNR < -30
No bars: No Service
The invalid value of lte snr is changed to INVALID_SNR
from -1, since -1 is a valid value of lte snr.
bug:5640958
Change-Id: If26aaba0c7fcc0fee3db488b5adfa02922f06715
Up to now, audio focus was implicitly requested and abandoned
when changing the audio mode. This is no longer the case so the
behavior with regards to audio focus can be indepently set by
the CallManager.
The logic implemented here is the same as the one previously used
in AudioService:
- only request audio focus when the ring volume index is > 0
when ringing,
- request focus before setting the audio mode to a mode other
than normal
- abandon audio focus after setting the audio mode to normal
Change-Id: Ia543dc779563dbff09414771fee60e589dfaab9d
In "Change I95ed2aae: Stop using shared DUN APN when tethering stops",
sha1: 8beff9586ff89a1e59469e9820fd9e9d704300d2, an assumption is made
that the msg.obj is always an ApnContext, this is not true for CDMA.
Eventually we plan on removing the destinction between GSM and CDMA but
for now we need to handle it handle it.
Bug: 5904734
Change-Id: I86873dc7aeda5234c14a6fe1e4ec7345ee30e957
In change Ief74d0e4f4f28dff7a435e9dab1fab1ca1d9bfaf with a sha1 of
e81932e92a773538e1ad1ad1d4bfd8f241860c8d it seemed like a good idea
to throw away all TLV's on errors. In retrospect that was probably
not a good idea. For example on the MTN Ghana SIM the error
occurs because of some 0 pad bytes at the end, all of the actual
TLV's are good, so throwing away everything is unreasonable. Instead
accepting what is valid seems a better approach.
Also, add a couple debug lines on error paths.
Change-Id: I4add0c9cd242f46e0ef8700229d0ec755b9e4c4c
Add an optional explanation field and toString to ResultException
Add toString to CommandDetails.
Add add a few more log statements on error paths.
Bug: 5852715
Change-Id: I8594178002a67798aa3fb38ce1ee15c1a41f1854
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
This allows testing of emergency numbers by dialing an emergency
number but having it remapped to another number.
Bug: 5479306
Change-Id: Ia9bb53e2e2e47f78dc9f75d3add6f785d10e4b2a
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
Even if other people are sharing the connection (ie, carrier wants
default and tethered traffic on the same APN) stop using
a carrier-described APN when the tethering stops.
bug:5525764
Change-Id: I95ed2aaed4d79519d233a62cf2945edead8114bc
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
