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.
Block incoming SMS in CDMA Emergency Callback Mode
CDMA carriers expect that incoming SMS is not processed by phone while
it is in Emergency Callback Mode, so don't acknowlegde it to the network.
These were combined to save testing time.
cpr107:
Enhance the MDN change during OTA
1. Remove the OTA MDN change code in RuimRecords.java and move
to CdmaServiceStateTracker.java
2. Reduce the frequent function GET-CDMASubscription. Move the
Get_CDMASubscription from pollstate() to EVENT_NV_READY handler.
The CDMA Subscriber MDN/MIN is only changed by OTA programming.
Only need fecth the subscriber information when power on and OTA
completed.
3. Add new variable for PRL version in cdma subscription
cpr146:
SMS-to-Email fix for extracting e-mail address
These are combined to save testing time.
Change 225:
make NV_READY return State.READY.
Change 203:
CDMA SMS decoding support for Latin and fix for WAP concatenation
1. Enabled support for 8bit Latin decoding.
2. Change octet decoding to remove an extra pad byte from the payload.
This caused problems with the concatenation of WAP PUSH messages.
3. Decode octet encoded data as if it was Latin. There are devices out
there that will use 0 instead of 8.
This is the problem where various things are listening for broadcasts
(such as battery status, PIN/PUK/Network) that an application can send
to cause harm to the system.
Solving this is tricky because many of these broadcasts are sticky,
and I have never figured out how to do permissions with sticky
broadcasts in a sane way. So instead, I am going to punt on the
general problem and just brute force it:
There is new a way for system components to declare specific
broadcast actions to be protected, which means that only the system
and the phone can send them. This is good enough for now. None
of it is exposed in the public API so we can make something a little
less stupid in the future if we ever need to.
With this fix, phone will not show that it is roaming
when it is not, and there is no need to enable the
"Data Roaming" in order to get the data to work.
Merge commit '37ea71122579e9e2ad1f91b3eca5e4d436b54ea9'
* commit '37ea71122579e9e2ad1f91b3eca5e4d436b54ea9':
septet-align UD after any UDH for GSM-7bit coding
