This is special for VZW requirement. Follow the specificaitons
of assisted dialing of MO SMS while traveling on VZW CDMA,
international CDMA or GSM markets.
Change-Id: I34a531b817095f4ce035f3f49a3bf7d6e2e8bc13
Getting the voicemail number will be done in Telephony instead of in
PhoneNumberUtils which is called by Telecomm.
Bug: 17317190
Change-Id: Ia88a56516b4f57ac62dc5696ae359fd042fec040
* Make context the first argument for isLocalEmergencyNumber and
isPotentialLocalEmergencyNumber
Bug: 15432083
Change-Id: I88b5ace925e3704bd032dc9694b0c2dd871b9cf9
The original change was submitted into lmp-preview-dev and should
not have been auto-merged to master.
This reverts commit 80327f7a31b19213ec48e1ab66e6bdc8e76cb0fe.
Change-Id: I9ff8a868ffa3135583c52ef97b15311107716899
* Make context the first argument for isLocalEmergencyNumber and
isPotentialLocalEmergencyNumber
* Hide DisconnectCause
Bug: 15432083
Change-Id: I88b5ace925e3704bd032dc9694b0c2dd871b9cf9
Unhide the following methods:
PhoneNumberFormattingTextWatcher(String countryCode)
formatNumber(String phoneNumber, String defaultCountryIso)
formatNumber(String phoneNumber, String phoneNumberE164, String defaultCountryISO)
formatNumberToE164(String phoneNumber, String defaultCountryIso)
(The previous 3 formatting methods use an instance of PhoneNumberUtil to do the formatting)
isLocalEmergencyNumber(String number, Context context)
isVoicemailNumber(String number)
replaceUnicodeDigits(String number)
normalizeNumber(String phoneNumber)
Deprecate the following methods. These formatting-related methods don't use
PhoneNumberUtil to perform the formatting, and so are considered broken:
formatNumber(String source)
formatNumber(String source, int defaultFormattingType)
getFormatTypeForLocale(Locale locale)
formatNumber(Editable text, int defaultFormattingType)
formatNanpNumber(Editable text)
formatJapaneseNumber(Editable text)
Change-Id: Ibf854092b7db05f7e3e9401cc909c9f1ed4997b0
For CDMA networks, convert "+" prefix to "011" if the home network
is using the North American Numbering Plan (NANP). New method is
only used for MO SMS messages.
Bug: 11360679
Change-Id: I534e0322b566de3fb49d7333bfcf62cfbfafb78a
This won't be shown in usual condition since in most cases the method
will just use the block just above the logging and return true/false
there. On the other hand this might be useful if the case is truely
exceptional and thus this path is really used.
Bug: 5914560
Bug: 6383850
Change-Id: I2242f93a9b905b5a39d997aa30d9fd6f5bfbdf49
Users can enter arabic phone number or click arabic phone number
to send MMS. Works for generic Unicode digits (full-width, etc.).
bug:5615791
Change-Id: Ieec8c5c6c3736ee2b4ac8ddf17f8c41b2001460e
Signed-off-by: Jake Hamby <jhamby@google.com>
Modify PhoneNumberUtils to automatically convert non-ASCII digits,
such as Arabic-Indic numbers, CJK full-width digits, etc., to ASCII
in normalizeNumber(), extractNetworkPortion(), and stripSeparators().
This enables the SMS application to support sending SMS's to phone
numbers written with Arabic, or other non-ASCII digits. The number will
be converted to ASCII digits and formatted for the user according to the
country formatting rules.
Bug: 5615791
Change-Id: I42039285db5795b1dda22e4251f54af302e27f13
Signed-off-by: Jake Hamby <jhamby@google.com>
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
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
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
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
Add a function that converts a string with RFC3601 defintion
of pause and wait into android representation.
Change-Id: Id8a17c3a166422d62247acb227506549990ace12
It's possible for an application to dial an emergency
number by appending extra digits to the phone number.
For example, one could dial "9111" instead of "911",
and a strict .equals wouldn't detect this as an emergency
number.
Replace .equals() with .startsWith()
Change-Id: I87f34fc2b9bbee2c4fa6be511bcc3b955559e0a9
Currently the SipPhone class manually creates a CallerInfo object, and
populates it with very basic info from the SIP address, when making an
outgoing call.
But this is no longer needed, now that we do caller-id lookup properly for
SIP addresses (based on real data from the contacts database -- see
bug 3004127 and change https://android-git.corp.google.com/g/70555).
And in fact the presence of this initial CallerInfo object actually
*disabled* contacts lookup for outgoing calls (bug 3072731).
This change removes all that CallerInfo-related stuff from SipPhone.
(Thus SipPhone is now consistent with the other phone objects, like
GSMPhone and CDMAPhone, in that it doesn't muck with CallerInfo data at
all, but instead lets the phone app do it.)
Also, update isUriNumber() to handle "%40" in case the passed-in string is
URI-escaped. (Nobody depends on that now, but it may be needed in the
future, and it's certainly safe to say that "%40" will never be found in a
legal PSTN number.)
TESTED:
- Outgoing SIP call:
- In-call UI shows correct contact info
- After the call, Call Log shows correct contact info
- Incoming SIP call:
- In-call UI shows correct contact info
- After the call, Call Log shows correct contact info
- PSTN calls:
- correct contact info everywhere
Bug: 3072731
Change-Id: I51434e4e5ad66d2e8ff51fc220001fb74485f0f5
Merge commit '4f24aed2a13d9ba89e2402894353176e19571e6e'
* commit '4f24aed2a13d9ba89e2402894353176e19571e6e':
Fix the dialing from contact for internet address.
Merge commit '669070787cc10377c2e5c3fa187babc728d96245' into gingerbread-plus-aosp
* commit '669070787cc10377c2e5c3fa187babc728d96245':
Fix the dialing from contact for internet address.
PhoneSubInfo.getVoiceMailNumber now returns only the network
portion of the voicemail number. Use the new method
PhoneSubInfo.getCompleteVoiceMailNumber to get the netowrk
portion and the post dial portion.
Bug: 2881483
Change-Id: I7637d4fa0ffa046b4eebc4d599719bb668c940b5
a. Format the number to E164.
b. Format the number based on country convention.
c. Normailize the number.
Change-Id: I39d59b99aa1a5136371dd20c74d9d9c8ec855369
Merge commit '4248d5887bf9d7d65b649a9ca0c7ba623135eed5'
* commit '4248d5887bf9d7d65b649a9ca0c7ba623135eed5':
Makes PhoneNumberUtils support international numbers after a CLIR command.
Makes PhoneNumberUtils.java support numbers in international
format (starting with ‘+’ character) after a CLIR command.
Previously a plus character would always be removed unless it
occupied the first position of the number string. In this case,
when the number is preceded by #31# (CLIR), the plus character
will be removed as well.
This is an error, prohibiting a type approval of the phone.
This change will detect the plus character after the CLIR command
and will insert it at the right position.
Change-Id: Ib220aee7b3eda30cde960db8c7470523dc5fd313
