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.
HSDPA: High-Speed Downlink Packet Access
HSUPA: High-Speend Uplink Packet Access
HSPA: High-Speed Packet Access
Add support for HSDPA/HSUPA/HSPA:
1) extend TelephonyManager.NETWORK_TYPE for HSDPA/HSUPA/HSPA
2) extend ServiceState.RADIO_TECHNOLOGY for HSDPA/HSUPA/HSPA
3) set radioTechnology into ServiceState in GsmServiceStateTracker
4) change the implementation of TelephonyManager.getNetworkType to
solve the competition timing issue between the time of setting
system property and the time of receiving notification through
PhoneStateListener
4.1) add a getNetworkType interface in ITelephony.aidl
5) add icons resources for HSDPA/HSUPA/HSPA
6) make use of HSDPA/HSUPA/HSPA icons in StatusBarPolicy
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.
Merge commit '0da3bdb476086db02a1076780676b21e239c79d6'
* commit '0da3bdb476086db02a1076780676b21e239c79d6':
Fix public API caused due to CDMA changes.
Merge commit 'b307c8945d4bf8d843445f3cc6d727f4e43d90f0'
* commit 'b307c8945d4bf8d843445f3cc6d727f4e43d90f0':
Fix bug 1994955 where PHONE_TYPE_CDMA was 0 and it should be 2 and added RILConstants.NO_PHONE.
This bug originally reported that PHONE_TYPE_CDMA needed to be 2 because
it was public. But as far as I can tell it has never been public and it
is still marked @hide so is not public now. There is a bug in that
PHONE_TYPE_NONE and PHONE_TYPE_CDMA were both 0. But this doesn't
appear to have been a problem because PHONE_TYPE_NONE doesn't looked to be
used anywhere except in TelephonyManagerTest.
Merge commit 'ecbbecf6c535e7f3e1d072d43766a95aa18ee464'
* commit 'ecbbecf6c535e7f3e1d072d43766a95aa18ee464':
Fix swapped gsm/cdma function dispatch, and 7bit text fragmentation.
