- 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.
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.
