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
GET_SIM_STATUS now returns structure RIL_CardStatus. So RIL_SIM_* status are obsoleted.
modified: java/com/android/internal/telephony/RILConstants.java
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.
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.
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.
* changes:
Ensure that we never trigger ArrayIndexOutOfBoundsException by checking that the index is always < the array's length. Also ensures that the object's state is consistent. Should resolve a denial-of-service bug when handling malformed WAP pushes.
The NullPointerException in getCallState is caused by the restarting of phone process. getITelephony() was not ready to be used at that moment.
modified: java/android/telephony/TelephonyManager.java
the index is always < the array's length. Also ensures that the object's
state is consistent. Should resolve a denial-of-service bug when handling
malformed WAP pushes.
The user is on wifi, then enables SUPL APN. When wifi is switched off,
we try to establish DATA connection on the Default APN. If this fails,
we were not retrying as the mRequestedApnType variable was not being reset.
This was happening because the SUPL APN and the data connection APN
were the same.
Need to correctly interpret WAP Datagram data. Specifically the
source and destination ports are only included in the 1st segment,
not subsequent segments but the original implementation was looking
for the ports for all segments.
There were a few places where we were not sending SMS ack. This change fixes that, and helps ensure that we don't miss any others.
Also fix a bug I introduced in RIL.java for CDMA SMS ACK (it uses RIL_CDMA_SMS_Ack and not int[]).
Previously, when call waiting is ignored by user or timed out
by PhoneApp, the connection object for call waiting does not
release the wake lock. It causes the phone process to crash
randomly.
The fix is to release the wake lock when call waiting is
ignored by user or timed out by PhoneApp.
