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 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
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
The phone app needs a way to distinguish between (a) numbers that are
definitely emergency numbers, and (b) numbers that *might* result in an
emergency call being dialed, but aren't specifically emergency numbers
themselves.
(The phone app needs this distinction in order to enforce the restriction
that 3rd party apps should not be allowed to make emergency calls using
the ACTION_CALL intent, while still making sure that the in-call UI only
displays the "emergency call" state for numbers that are *definitely*
emergency numbers. See bug 5493790 for the full details;)
So this change adds a full set of "isPotentialEmergencyNumber()" methods
to go along with the "isEmergencyNumber()" methods we've had all along.
The "potential" variants behave identically to the original methods,
*except* that they ultimately use number.startsWith() rather than
number.equals() when comparing against the list of emergency numbers.
TESTED:
- Unit test 'PhoneNumberUtilsTest#testIsEmergencyNumber' passes.
(The PhoneNumberUtilsTest class doesn't pass in its entirety, but it was
broken before this change also.)
- Also see the commit description of change
Ib949fea3c0ce6b341a90e617a03ba3f22c69018b for the exact tests I ran
against the phone app.
This change should be submitted along with
Change-Id: Ib949fea3c0ce6b341a90e617a03ba3f22c69018b
in apps/Phone (but this change must go in first to avoid breaking the
build.)
Bug: 5493790
Change-Id: Ic528cfcc555734cdaf4ca8a18a50199771ba49b1
- Precondition: config_sms_enabled_single_shift_tables is configured as
1 (Turkish) in frameworks/base/core/res/res/values/config.xml
- Cause: There is no consideration for National Language Shift Tables in
SmsMessage::fragmentText function.
- Solution: The header length is calculated properly according to
National Language Shift Table
- modified to add test cases and fix calculation bug (jhamby@google.com)
Bug: 5553544
Change-Id: I9eaefbbd6b3d75f8c41cbf9d0cb03a701cfa1cb3
Refactor framework to support multiple SMSDispatcher objects on
dual-mode devices that require support for both 3GPP and 3GPP2
format SMS messages. Each dispatcher registers to receive events for
the appropriate message format.
Note: All applications which handle incoming SMS messages by processing the
SMS_RECEIVED_ACTION broadcast intent MUST pass the "format" extra from the intent
into the new createPdu() method in android.telephony.SmsMessage that takes an
extra format parameter. This is required in order to correctly decode the PDU on
devices which require support for both 3GPP and 3GPP2 formats at the same time,
such as CDMA/LTE devices and GSM/CDMA world phones.
- moved code to manage device storage events from SMSDispatcher to a
new class, SmsStorageMonitor, which is shared among all dispatchers.
- moved code to monitor per-application outgoing SMS usage from
SMSDispatcher.SmsCounter to a new class, SmsUsageMonitor, which
is shared among all dispatchers.
- fixed a bug that prevented CDMALTEPhone from setting the MCC/MNC
operator numeric value in the telephony provider from the UICC,
as GSMPhone does, when the SIM records have loaded.
Change-Id: I2789ac07b6ca2948138bca7f75481f9b31514f20
If the user asks to format a number that starts with either a hash or a
star symbol, do not further format the phone number since we are not
actually able to parse such a number correctly and current this results
in the star or hash being dropped.
Bug: 5362177
Change-Id: Iff8d317c087d0ca07f2b107459ce8c47882ef367
IMS Module need the MSISDN value for IMS registration.(VZW Requirement)
Change-Id: I8713b6c55788276246ee1c2f91eaf2d3ab8cc813
Signed-off-by: duckyoung.chai <duckyoung.chai@samsung.com>
- Add methods to TelephonyManager to provide access to IMS records on
the ISIM application of the UICC, as well as access to the ISIM
AKA authentication algorithm.
- Add support for the new IMS methods to CDMALTEPhone, using the helper class
ImsUiccRecords to load the IMS records from the ISIM. The same approach
can be used to implement IMS support for UMTS/LTE devices.
- There is a new RIL request, RIL_REQUEST_ISIM_AUTHENTICATION, which is
used to perform IMS AKA authentication using the algorithm on the ISIM
application of the UICC. The challenge nonce and response are both encoded
as Base64 strings.
Change-Id: I73367c7d9bc573d0d883d68adf09891de1319129
Add a function that converts a string with RFC3601 defintion
of pause and wait into android representation.
Change-Id: Id8a17c3a166422d62247acb227506549990ace12
Report out of service if we don't know any better. Sometimes when switching radios
we were finding nulls reported - it crashed some code and highlighted this problem.
If we don't have a service state we're certainly out of service, so this isn't a lie.
bug:4553701
Change-Id: I094798a5f9f39f45c0ba30179aaa8f88f9b3e405
For non-phone device, i.e. tablet doesn't have voice capability,
getDeviceId returns null while getPhoneType returns PHONE_TYPE_NONE.
This behavior is suggested by developer scheme
http://android-developers.blogspot.com/2011/03/identifying-app-installations.html
and enforced by CTS testGetDeviceId.
bug:4464907
Change-Id: Iaa3832b7323a50deccd438cb884c8e776a7a9640
Instead of deriving network identity based on raw subsystem broadcasts,
listen for updates from ConnectivityService. Added atomic view of all
active NetworkState, and build map from "iface" to NetworkIdentity set
for stats tracking.
To avoid exposing internal complexity, INetworkStatsService calls use
general templates. Added TelephonyManager mapping to classify network
types using broad labels like "3G" or "4G", used to drive templates.
Cleaned up Objects and Preconditions.
Change-Id: I1d4c1403f0503bc3635a59bb378841ba42239a91
For non-phone device, i.e. tablet doesn't have voice capability,
getDeviceId returns null while getPhoneType returns PHONE_TYPE_NONE.
This behavior is suggested by developer scheme
http://android-developers.blogspot.com/2011/03/identifying-app-installations.html
and enforced by CTS testGetDeviceId.
bug:4464907
Change-Id: Iaa3832b7323a50deccd438cb884c8e776a7a9640
Add support for ETWS primary notification messages.
Add method for easy concatenation of GSM multi-part broadcasts.
Add test cases for SmsCbHeader, SmsCbMessage and IntRangeManager.
Change-Id: Ifc646a011e79ad6c7eace9afcf84b1216eb42b7a
