Fixes a problem where mms apn was on when we lost the network (airplane mode) but mms was
off when airplane mode was turned off so it kept thinking we didn't have access and
future mms always failed.
bug: 2075145
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.
Issue to be addressed:
In radioRestart() method in CdmaDataConnectionTracker, if the radio is
restarted right after cleaning up connection, it is possible that the
connection setup request triggered by radio-on may happen before the
connection cleanup has been completed so that the connection may not
be set up correctly after the radio is restarted. The end result could
be that the phone lost the data capability.
The patch includes the following changes:
1) Add EVENT_RESTART_RADIO in DataConnectionTracker.
2) In CdmaDataConnectionTracker, method restartRadio(), send a message
delayed by 20s, the purpose of which is to wait for connection cleanup
to be completed, then to restart radio.
3) In CdmaDataConnectionTracker, method trySetupData(), don't try to setup
data if there is pending message to restart radio.
Addtional notes:
A system property is not used to config the delayed timer because we
think this fix is to address the unusual error case and waiting for
long time should not impact user experience much. 12s is the longest
time to complete the data cleanup as we have seen so far, so we are
using a 20s timer.
Send a flash command to CDMA network for putting the other party on hold.
For CDMA networks which do not support this the user would just hear a beep
from the network.
For CDMA networks which do support this, it will put the other party on hold.
Fix some race conditions (check isTeardownRequested).
Fix the passing of mInterfaceName to subtypes (mms, etc).
Fix the generation of CONNECTED message to already active subtypes.
Fix the enabling of Data in DataConnectionTracker.
bug: 2065037
Based on the VZW requirement, phone should be still in ECM mode in 2nd emergency call.
but in the current phone call, if a 2nd emergency call is originated, ECM mode will exit.
For fixing this problem, the coding design is as below:
1. In framework, canceling the first ECM timer immediately upon the origination of the
2nd E911 call, and restarting a new timer when the 2nd E911 ends.
2. Framework needs to syncronize the timer with phone app by sending notification to phone app to
inform timer is canceled or re-started, since phone app needs to show how much ECM time left
on the status bar.
3. In phone app's emergency callback mode service, the timer in this service will be canceled
when it receives the timer cancel notification from framework; the timer will be restarted
once it receives timer restart notification from framework.
Issues to be addressed:
The method setPowerStateToDesired() in CdmaServiceStateTracker class sends
a msg to CdmaDataConnectionTracker class to deactive data call, and then starts
a loop which calls SystemClock.sleep() to wait for several seconds.The purpose
of this is to wait for data-disconnection before sending RADIO_POWER off request.
However, the CdmaServiceStateTracker and CdmaDataConnectionTracker are running in
the same process so that the CdmaDataConnectionTracker is not able to process the
message to deactive data before the loop ends.
The patch includes the following changes:
1) In setPowerStateToDesired() in CdmaServiceStateTracker, replace implementation
of loop-delay by sending a delayed msg to set RADIO_POWER off.
2) In CdmaDataConnectionTracker, when getting EVENT_DISCONNECT_DONE, call a new
method in CdmaServiceStateTracker to process pending request to turn RADIO_POWER
off.
to retry a connection and possibly reconnect after a temporary data loss.
The root cause appears to be because DEACTIVATE and POWER_RADIO_OFF are
sent back to back and POWER_RADIO_OFF completes before DEACTIVATE.
When this happens CdmaDataConnectionTracker won't attempt to reestablish
a data connection until a voice call terminates.
At this time it appears the better solution is have CdmaDataConnectionTracker
wait for DEACTIVATE to complete before issuing POWER_RADIO_OFF, this fix
will be implemented in the near future.
and when data roaming is enabled reset the retry manager.
This change also refactors mRetryMgr to DataConnectionTracker
removing it from Cdma and Gsm data connection trackers child classes.
Setting max_retires to infinite sets mRetryForever to true and therefore
isRetryNeeded will always be true. This is better than an alternative
which is to set max_retires to a large value such as 2147483647.
Seperate dataRoaming from gsmRoaming. dataRoaming is based on +CGREG returns in GSM while gsmRoaming is based on +CREG returns. Previously, the status of dataRoaming is always treated the same as gsmRoaming. However there is a situation where +CREG returns 0 and +CGREG returns 5, i.e., gsmRoaming is off and dataRoaming is on. In such situation, the phone should setup data connection if the phone enables data service when roaming (for example, data only card). The phone shouldn't setup data connection if the phone disable data service when roaming (to prevent roaming data charge). So gsmDataConnectionTracker should use dataRoaming instead of gsmRoaming to decide if data service allowed.
modified: GsmDataConnectionTracker.java
modified: GsmServiceStateTracker.java
This also refactors ConnectivityService a bit towards supporting multiple simultaneous connections by making each a seem like a seperate Network with it's own stateTracker, etc.
Also adds tracking of process death to clean orphaned startUsingNetworkFeature features.
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.
Save the operator name during network selection. The name will be used by UI to provide network selection notification. See bug 1414247.
modified: java/com/android/internal/telephony/PhoneBase.java
modified: java/com/android/internal/telephony/gsm/GSMPhone.java
When ro.telephony.disable-call is set to true the phone disable actual calls. It provides a way to test in user-debug builds for stability runs. See bug 2031157.
modified: java/com/android/internal/telephony/TelephonyProperties.java
modified: java/com/android/internal/telephony/cdma/CdmaCallTracker.java
modified: java/com/android/internal/telephony/gsm/GsmCallTracker.java
modified: java/com/android/internal/telephony/TelephonyProperties.java
modified: java/com/android/internal/telephony/cdma/CdmaCallTracker.java
modified: java/com/android/internal/telephony/gsm/GsmCallTracker.java
1. Convert the voicemail count of a VM notification from
BCD to decimal. That way the user will not be notified
of 16 new VM when there are only 10.
Ref: 3GPP2 C.S0015-B / 4.5.12 Number of Messages.
2. Allow VMN-95 notifications without "User Data" to be
processed. Only mandatory items for VMN-95 are
"Message Identifier" and "Number of Messages".
Ref: 3GPP2 C.S0015-B / 4.3.5 Voice Mail Notification.
Temporary rollback of this change, for now the radio can prevent data traffic,
but that's not the desired long-term solution.
This reverts commit 79ef673d56e2599932b8b7f13695d23b4df54d09.
During the time of OTA activation screen startup, the app needs
to get MIN by calling getCdmaMin(). The issue in current code is that
OTA app calls getCdmaMin() before framework gets MIN data from lower
layer.
To fix this issue, framework will be providing the following new APIs
to applications for checking if MIN data is ready:
1. isMinInfoReady():
Check if mMin variable in getCdmaMin() has been assigned a non-null value.
2. registerForSubscriptionInfoReady():
Apps uses this API to register for notification.
3. unregisterForSubscriptionInfoReady():
This API is used by apps to unregister notification.
Framework will be sending out the notification in the following situations:
1. when mMin is assigned a non-null MIN value;
2. When app calls register API and MIN is ready.
This indicates to the UI that the hangup command has been received by the
Telephony layer and passed down to the RIL, but we have not yet been notified
of a successful DISCONNECT.
Addresses http://b/issue?id=1659876.
