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: I201ecbf11607fd200aaae3cbb32561efabf65672
Bearer Independent Protocol (BIP) connections as defined in
ETSI TS 102 223 "Smart Cards; Card Application Toolkit (CAT) (Release 11)"
need to be able to establish data connections even when not provisioned.
This can occur when trying to provision on via and EVDO network.
Bug: 6110632
Change-Id: I85722e0ba2e2606ffcf2516b8f00be6ff5271adf
Previously, the assumption was that only a deletion or an insertion can happen
at a time; but with auto-complete, a deletion and insertion happen at the same time.
Needed for bug 5992672 in the Messaging app and is nice to have in the platform.
Change-Id: I2d80cecc486e7a1ceeaeb34866bcd834074f5ead
[issue 5963659]
Result:
There is no APN information for Cheers
Expected Result:
Mobile internet APN name for Cheers should be displayed
Change-Id: Iab29cfbd06ab15559048ced23136abae1fcab8f3
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
Phone app will use this for actual phone calling, coping with
IccProvider, etc.
Add unit tests for the method, and stripSeparators() which is missing
Bug: 5546664
Change-Id: I49b996abe7a44f7db4301b62f667189281fc40e9
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
Since some RILs use -1 instead of INVALID_SNR as invalid vlue for
LTE SNR, SignalStrength will not use LTE SNR to check if LTE valid.
bug:5970403
Change-Id: Ia948e076f8f5878e081e87680076b187857879c8
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
The new mapping are
Four bars: RSRP >= -95dBm
Three bars: -105 dBm <= RSRP < -95 dBm
Two bars: -115 dBm <= RSRP < -105 dBm
One bars: RSRP < -115 dBm
No bars: No Service
bug:5640958
Change-Id: I9efabaeac33b624ea0a58a4d3760169dff6544f6
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
Adds better documentation to the getBaseStationLatitude() and
getBaseStationLongitude() methods to indicate the units for latitude
and longitude in CdmaCellLocation. Unlike the Android Location API
methods, latitude and longitude in CdmaCellLocation are not in decimal
degrees but instead in 0.25 seconds due to a more obscure 3GPP standard
underlying the Telephony API. The current Javadocs on the Android
developer page (http://goo.gl/hvWo6) do not indicate the units for
latitude and longitude in CdmaCellLocation, making it very difficult
for developers to interpret the output of these methods, especially
since 0.25 seconds is not a commonly used unit for latitude and longitude
in application-level code. This patch adds clear documentation to
these methods so developers can clearly understand the units for
latitude and longitude without having to dig through the Android
platform source code.
Change-Id: I259bfe3b68e3999804877821680fb99a22937651
Signed-off-by: Sean Barbeau <sjbarbeau@gmail.com>
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
