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
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
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
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
As per several discussions, we stick to the default behavior now.
In stead, we provide compareStrictly() as a hidden method, so that some
internal components are able to use the method if needed.
Since these are static methods, they cannot refer to the configuration files,
whose values can be obtained only via Resources object.
Please make callers' side if you want to use strict version of compare().
Internal issue number: 1892808
Refactored common code between CallerInfo and CallerInfoAsyncQuery that deal
with voicemail number comparison.
In CallerInfo.java added a new field mIsVoiceMail to indicate this is a
voicemail call.
Added a new method to convert the CallerInfo into a VM instance.
Added a new method to generate a debug string from an instance.
PhoneNumberUtils has a new method "isVoiceMailNumber" to check if a number
is a VM one. I left the method as hidden. Previously any security exception
failure was cached in a static variable. I removed that and
privilege the optmistic scenario. I am not sure if the security exception
is only for the 'regular' telephony layer and if it applies if a 3rd party
VM app is installed (e.g googlevoice), hence i removed the cashing to make
sure we can pick up new voicemail providers when installed/enabled/disabled.
Bug:2112640
This patch includes the plus code conversion clean up.
1. change the plus code conversion based on the current and default
number systems retrieved from MCC.
2. for format such as +NANP, replace the '+' with the current IDP (011).
3. comments changes.
The issue is that the plus sign in a dial string is always converted
to the IDP (International Dial Prefix).
This fix implements a plus sign conversion mechanism based on the default
telephone numbering system that the phone is activated and the current telephone
number system that the phone is camped on. Currently, we only support the cases
where the default and current telephone numbering system are NANP.
This method is used by the Phone app to decode ACTION_CALL
Intents, resolving to a real phone number. Because the
columns are changing with the new provider, I added logic
to query using the correct columns for the authority of the
requested Uri.
