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
The test here is partly fixed by Change I38c54265. However, the test
itself still needs to be fixed as local numbers in US never starts with
a '1'.
Bug: 5599741
Change-Id: I3a3961331961f4f535d30dec884babdb32e8b67b
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
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
