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.
1. The authType should be specified in the APN database.
This was hardcoded to 3 in the qmi driver. We currently set it to
3 in the RIL till the apn database side changes are done.
2. RIL_SEND_SMS response has errorCode as a new field,
Indicate SMS memory available/not available based on DEVICE_STORAGE_OK/FULL
intents, and immediately NAK with MEMORY_FULL if we've received a
DEVICE_STORAGE_FULL notification.
This may end up being a short term solution, as the messaging app is
getting re-worked in Eclair, which may change the way we want to handle
memory full reporting (ie, more app involvement).
The changes from 090602 update frameworks/base to support 3way calling
and call waiting.
The changes from 090603 completed the CdmaInformationRecords class
but the original changes submitted has been simplified, toString added
and a bug fixed where the notifications where not being handled properly.
The changes from 090605 added Prl Version, apn fixes.
