- Fix typos in Javadoc and comments.
- Fix Javadoc @link references to other classes/methods.
- Rename MISSING_UKNOWN_APN to MISSING_UNKNOWN_APN in DataConnection.
- Remove unused (and misspelled) RETRYIES_* consts in RetryManager.
Change-Id: I3b44ac8320d6c1e4c350be600c7ef266aaf735e4
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
The terminal disallows USSD, SMS, Voice Call and Supplementary services
operations for numbers not in the Fixed Dialing Number (FDN) list when the
FDN service is enabled. FDN_CHECK_FAILURE error is sent from the RIL and the
message needs to be displayed to indicate the failure.
Change-Id: I49bd63f69a3f0201125b17cd16db2e8fcf93ddc3
For bug 2536842 to show signal strength in Emergency mode.
The STATE_EMERGENCY_ONLY of ServiceState is not in-use.
So add a hide interface to indicate Emergency mode.
Change-Id: I19398ac5e73a722dcaaf744347f961d1fa7513ac
Fixed some comment typos and cleaned up logging of unexpected calls to
CDMA-specific methods on a non-CDMA device.
Change-Id: Ia6e5fba765122cbf3186fd9fecca7a3931a76dcc
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.
When trying to view the saved sms messages on my SIM, I ran into a null ref.
With this fix, we don't try and wrap a null message, but just skip it.
This is part one of three fixes for BC-triaged bug 2205782.
Change-Id: Ie7105dae7e3134b98681deabcc14f5db555902f3
When Android Telephony receives response to GET_REGISTRATION_STATE
message from RIL it may contain few fields set to NULL. Due to a parsing
exception encountered while parsing that field, the remaining fields will
not be parsed even if they are valid data. Ignore all fields that are NULL
while letting it parse non-NULL data.
For Latitude and Longitude, the values should not be hexadecimal. They
shall be parsed as decimal values as specified in the 3GPP2 C.S0005-A
specification. Invalid value is changed from -1 to Integer.MAX_VALUE.
Bug: 2201613
Change-Id: I13dd02fcfa2ae7fcb6f21c4b94b830786bd7270c
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
Since the StatusBarPolicy is run in the System Process and shouldn't therefore call into
the Telephony process we decided to make sure all the needed info was passed along with the
original notifications.
bug: 2173053
NeighboringCellInfo works in GSM and UMTS network.
In GSM network, the locaiton value is the combination of LAC and CID.
In UMTS network, the locaiton value is PSC code.
NeighboringCellInfo should access and store those two values seperately.
It involves the change of Public API.
1. Add new API getRadioType(), getLac(), and getPsc() to get location info in GSM and UMTS.
2. Deprecate setCid() and NeighboringCellInfo(int cid) because cid is set by interpreting network type.
This routine returns integer values defined in the Phone interface,
derived from RILConstants values. Direct references to the
RILConstants are replaced by references to these new ones for
consistency.
API CHANGE:
unhide TelephonyManager.PHONE_TYPE_CDMA
Addresses issue:
http://buganizer/issue?id=1905415
Change-Id: Icfec6d457231b098c031677a66770b5e57be4a44
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
Its twin sister GsmCellLocation is public, so this really should be in the SDK too.
Change-Id: If6f5899047546a7398f1e4191c67acf15555c21b
Signed-off-by: Mike Lockwood <lockwood@android.com>
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
It is for bug 1971628 but affects almost every API function in TelephonyManager. When phone is not ready (for example, after crash and restart) the getSubscriberInfo and getITelephony returns null and causes NPE.
This is accomplished by adding hasIccCard to ITelephony and do
the implemenation in PhoneInterfaceManager.java. Then change
TelephonyManager to use getITelephony().hasIccCard().
Change-Id: I26970fdf92a058502b8156a4f52c14e213217fc6
Expose the presence/absence of IccCards in the system.
This is needed to fix bug 2033811 which needs to show
some SIM menus in the Mms app and Contact apps only if
there is a SIM and on CDMA there is no sims yet.
The current implementation assumes CDMA never has an
IccCard this is true at the moment but needs to change.
Change-Id: I4167368e364623ea68e9b2778556e6d730b1e715
Previously pdu creation was haphazardly done sometimes by the app and
sometimes centrally by the phone process -- specifically the phone
process did creation for multipart texts. This change gets rid of the
previous IPC interface for sending raw pdus to SMSDispatch in the
phone process, and instead makes everything work like multipart
messages worked before, namely the structured data is passed and pdu
encoding done centrally.
The motivation for this was the need to ensure that CDMA message id
numbers were strictly monotonic, including across reboots, which
necessitated central state in the form of a system property, which
could in turn only be modified by the phone process.
Hence, this (in part) addresses issue: http://buganizer/issue?id=2075760
Change-Id: I94ca207b6e657c465e8472534704db8646ee277c
After sending 100 messages, SMSDispatcher always displays dialog to user to
confirm the sending. If the user sends messages too fast then there will be more
than one dialogs waiting for the response, but SMSDisptcher can only handle one.
