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.
SetupDataCall needs radio technology parameter to identify CDMA and GSM type. 0 means CDMA and 1 means GSM. The values are different from GSM_PHONE and CDMA_PHONE. Add authType parameter to identify PAP/CHAP authentication. Currently the authType is set to use both PAP and CHAP in CDMA phone.
modified: telephony/java/com/android/internal/telephony/CommandsInterface.java
modified: telephony/java/com/android/internal/telephony/RIL.java
modified: telephony/java/com/android/internal/telephony/RILConstants.java
modified: telephony/java/com/android/internal/telephony/cdma/CdmaDataConnection.java
modified: telephony/java/com/android/internal/telephony/gsm/PdpConnection.java
modified: telephony/java/com/android/internal/telephony/test/SimulatedCommands.java
When SMS is sent from a email address, Email Gateway server sends a string
containing from address, message text. Current code is treating the first
word as from_address, second word as subject and rest of the string as message_body.
Because of this second word is getting stored in separate variable and not as part
of message text, so second word is always lost.
Merge commit '0da3bdb476086db02a1076780676b21e239c79d6'
* commit '0da3bdb476086db02a1076780676b21e239c79d6':
Fix public API caused due to CDMA changes.
GET_SIM_STATUS now returns structure RIL_CardStatus. So RIL_SIM_* status are obsoleted.
modified: java/com/android/internal/telephony/RILConstants.java
- If the SID is not in NAM and PRL, the phone should use default Roaming
Indicator
- If a system is acquired that matches the NAM but does NOT match the PRL,
the device shall display a FLASHING roaming indicator
- Handle corner cases for PRL is not loaded / Home SID is not programmed
- Reorganize the ERI logic
Merge commit 'b307c8945d4bf8d843445f3cc6d727f4e43d90f0'
* commit 'b307c8945d4bf8d843445f3cc6d727f4e43d90f0':
Fix bug 1994955 where PHONE_TYPE_CDMA was 0 and it should be 2 and added RILConstants.NO_PHONE.
The issue this change fixes is that phone status bar shows full
signal strength bar even when phone is in bad signal area. The
root cause is that the signal strenth is incorrectly interpreted.
The issue this change fixes is that phone did not send MIP deregisteration
and LCP termination message when user powered down phone while data call was
in dormant state. The root cause is Framework Telephony did not wait long
enough before it sent the request to power off the radio. The fix is to
increase the waiting timer.
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.
* changes:
Refix the MT call screen stuck issue. The issue this change fixes can be reproduced by following steps: 1. Originate and connect a call to remote party #1 that is not in Contacts. 2. Receive a call from the remote party #2 that is not in Contacts, the call waiting tone is sounded and the call waiting screen is displayed. 3. Press menu key and ignore the call, and the call waiting screen is dismissed and the remote party #2 is forwarded to voice mail. When we ignore the incoming call, Phone gets stuck with incoming call screen.
Merge commit 'ecbbecf6c535e7f3e1d072d43766a95aa18ee464'
* commit 'ecbbecf6c535e7f3e1d072d43766a95aa18ee464':
Fix swapped gsm/cdma function dispatch, and 7bit text fragmentation.
The issue this change fixes can be reproduced by following steps:
1. Originate and connect a call to remote party #1 that is not in Contacts.
2. Receive a call from the remote party #2 that is not in Contacts, the
call waiting tone is sounded and the call waiting screen is displayed.
3. Press menu key and ignore the call, and the call waiting screen is
dismissed and the remote party #2 is forwarded to voice mail.
When we ignore the incoming call, Phone gets stuck with incoming call
screen.
The fix is to update the phone state before notifying the state change
in hangup() function.
The issue this change fixes can be reproduced by:
1. place an MO call;
2. place the second MO call;
3. hangup from the other end for one of the calls so there is only
one call connected;
4. try to place another call.
This issue is that the new call would fail.
In case the cdma modem indicates unspecified error as a reason for a
dropped call, then the cause was wrongly being translated to NORMAL call in
DisconnectCause. This has been fixed to report ERROR_UNSPECIFIED as
DisconnectCause in Connection.java.
The SID and NID in CDMA_SUBSCRIPTION are in hexadecimal format. So change the parseInt() in CdmaServiceStateTracker and add comments in CommandsInterface.
modified: java/com/android/internal/telephony/CommandsInterface.java
modified: java/com/android/internal/telephony/cdma/CdmaServiceStateTracker.java
modified: java/com/android/internal/telephony/RIL.java
modified: java/com/android/internal/telephony/CommandsInterface.java
modified: java/com/android/internal/telephony/cdma/CdmaServiceStateTracker.java
modified: java/com/android/internal/telephony/RIL.java
The issue this change fixes can be reproduced by following steps:
1. Originate and connect a call to remote party #1 that is not in Contacts.
2. Receive a call from the remote party #2 that is not in Contacts, the
call waiting tone is sounded and the call waiting screen is displayed.
3. Press menu key and ignore the call, and the call waiting screen is
dismissed and the remote party #2 is forwarded to voice mail.
When we ignore the incoming call, Phone gets stuck with incoming call
screen.
The fix is:
1. Update phone state promotly based on the call waiting state.
2. Remove new call handling in handlePollCalls() function because in CDMA,
the call drop should be determnited by the number of calls in the call
list.
Includes support to get the MCC and MNC from system properties, since
they are known to be unreliable from the network.
This is known to conflict with master and will be
added by hand so as not to break the build.
H_SID and H_NID are now comma separated lists, so update CdmaServiceTracker
accordingly. Note: For now, we still only store away the first of each.
Also remove H_SID and H_NID fetching from RuimRecords.java, since it is unused
(and unlikely to be used) in that class.
