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
Removes all dashes if locale isn't NANP or Japan and the number
don't have there country code.
Use case: If adding a number starting with 1nnnnnn and then
trying to add a country code before (ex +46) we will first
trigger NANP formatting with +1-nnn-nnn so when we get
+41-nnn-nnn we will still have the old NANP formatting.
This number should be shown as +461nnnnnn.
Change-Id: I5cab830350d785a58367eba79e268d9e8ee16aac
Contacts with phonenumbers beginning with '+' lose the '+' in the
phonebook when imported from SIM.
This was only noticable on ADN-records with unknown NPI-values which
isn't very usual.
Change-Id: I181249759ae3d4181dd3cf627c7a588394b80419
- Fixed a bunch of typos in comments (plus a few variable names)
- Removed unused import lines from telephony classes
- Added @Override attribute to overriding methods
- Made SmsMessage.PduParser inner class private & deleted unused constructor
- Added type specifiers to declarations of ArrayList and HashMap
- SimulatedCommands.getRegistrationState() had an ArrayIndexOutOfBoundsException
trying to write to index 14 of a 14-element array. I removed the
out-of-bounds assignment.
Change-Id: I054b5156aa64ab6639028d5b45a7e688b2deee08
Currently, the emergency calls are put into an readonly property ro.ril.ecclist.
It is possible that ecclist has to be changed before and after SIM pin lock.
And ecclist can also be changed after network broadcasts the local emgergency numbers.
So add r-w property ril.ecclist to make emergency number list changable, while still
check r-o property to make old RIL work.
- when comparing two numbers whose dialable char length is less than the MIN_MATCH (7), treat them as equal if the dialable portion of the numbers match.
- update unit test.
Create a new extractNetworkPortion() function, since the old one is
public, that does effectively the same thing but is more flexible as
just mentioned.
Addresses issue:
http://buganizer/issue?id=2013998
Change-Id: Ie5df08ef9c871881e8728a44abf0385908000823
