DcTracker: Expedite data stall recovery

The current stall recovery process has a pending packet queue which
needs to fill up before a stall is determined. But that process is
also multi-step, and it is currently expecting that queue to fill
between steps.
Waiting for the unacknowledged packets to grow after running the
connection cleanup step looks like something that would never happen,
or would take a very long time to, so expedite the stall recovery after
it begins: if any single packet stalls and there's already a recovery
in progress, run the follow up step immediately.

Change-Id: Ib16b2c47b5c832a812c8bd2a3d940862741ed9db
Support for SEEK on Android.

Support for following apis have been added:
1. exchangeApdu()
2. openLogicalChannel()
3. closeLogicalChannel()
4. getAtr()

Conflicts:
	src/java/com/android/internal/telephony/sip/SipCommandInterface.java
	src/java/com/android/internal/telephony/test/SimulatedCommands.java

Change-Id: I267d0d6fd229f20671411b130f7654ee705f14ca
SIMRecords: If there's no EF_SPN record, fallback to EF_PNN

Turns out some SIM (TMobile US, at least) don't fill in the SPN, but
do insert a PNN record for home network (which in the case of a non-MVNO
are the same. a MVNO should always have the SPN filled anyway).

Change-Id: I18388bb071a49698015c76abefb58798f800946c
Telephony: Scrub debug messages for identifiable information.

Change-Id: I70fd8d9b4900dc9e070be24e7efa8d3458caef99

Conflicts:
	src/java/com/android/internal/telephony/util/BlacklistUtils.java
Telephony: Decode Virgin Mobile US MMS

Fixes receiving MMS as one or more sms from a 9999999999 number full of
gibberish.

Back in the CM7 days, a developer named Blarf (Blarfiejandro) started a
repo called Inferior Human Organs for the optimus S/V (LG LS670 and
VM670) when no-one could figure out how to get Virgin Mobile MMS working
in CM.

His MMS patch to decode Virgin's weird system for MMS was eventually
absorbed by CM10.2 by  rukin5197. Without it, MMS comes in as one or
more sms from a 9999999999 number full of gibberish.

bigsupersquid took the CM10.2 patch for this fix and updated it enough
to work in CM11. However because he doesn't have Gerrit, he asked others
to integrate the fix for him.

More information here:

http://forum.xda-developers.com/showthread.php?t=2663277

http://androidforums.com/virgin-mobile-galaxy-s3-all-things-root/840298-mod-universal-lte-virgin-mobile-apn-fix-wip-cm-aosp-4-4-x-2.html

Change-Id: I6518538e941fdbfb7d7441b6db49d1309e87aa9e
Correct order of parameter in iccExchangeApdu()

The class must be in 1st place for RIL_REQUEST_SIM_TRANSMIT_BASIC
or RIL_REQUEST_SIM_TRANSMIT_CHANNEL requests to map hardware/RIL
component.

Change-Id: Idcf6faee0f6259704ea07b62ce713ebdd4c5da1b
Fix MMS sending issue in LTE on CDMA networks.

For CDMA-LTE mode, operator numeric based on USIM is used for configuring
MMSC settings in APN db. Currently CSIM based operator numeric is set
as current carrier in CDMALTEPhone and hence MMS app cannot find MMSC
setting when camped to LTE in CDMA-LTE mode.
However for CDMA only networks, MMSC settings are added based on CSIM/RUIM
operator numeric.
To make both configurations work, update the current carrier operator
numeric based on current data RAT from DcTracker.
Also make sure that only DcTracker updates the current carrier in case of
CDMA/CDMA-LTE modes to avoid overwriting with wrong value in case of multi
app UICC cards.

Change-Id: I465369811520cf345605ad70d7dadf9532b74017
CRs-Fixed: 642640
MSIM(DSDA): Update setMode properly.

When user accepts MT call mSpeedUpAudioForMtCall should be set
to true, but this is not happening when there is already a call active
and user accepts an MT call. As a result when setAudioMode()is called
after user accepting call, audio mode is again set to RINGING.
As part of the change, mSpeedUpAudioForMtCall is set to true,
when user accepts MT call, regardless of whether there is already
an active call or not.

Change-Id: I08cc4955c5d8dbb100bd33b5ef2db2532d43fb56
CRs-Fixed: 690366
Telephony: Close the FileReader when finished

Change-Id: I12865e8d974515d4f349d476bcf775e015008e16