Fix OOBE crash/DoS after receiving 0-byte WAP push.

Add a try/catch block around the code in WapPushOverSms.dispatchWapPdu(),
so we don't get into a reboot trap on receiving weirdly formed messages.
Only catch ArrayIndexOutOfBoundsException, which is difficult to
prevent inside dispatchWapPdu() for 0-byte PDUs or other unusual
contents. The caller should probably catch any unhandled exceptions of other types and log them with stack traces.

Bug: 11967705
Change-Id: Iabfec68d2564dd438d45c80cdba877bf19fa0397
GsmSS: Use data tech in isConcurrentVoiceAndDataAllowed

Voice technology is not properly supported in older RILs

When using RIL blobs, the value would be set to UNKNOWN,
resulting in data being disconnecting during call despite
being on 3G.

When using source-built RIL, the value would be set to
UMTS regardless of 2G/3G status. (At least from reading
the source.)

Change-Id: I12738abc1736165e92aa7f4530ca043cc1acc44d
IccSmsInterfaceManager: Don't intercept short-code premium messages

For both charging and potential timing factors on emergency and carrier
services, short codes should be delivered directly to the network.

Change-Id: If9d288048f9925573f8c5f2e51f0c2df789277bd
Fix NPE on sending multipart texts.

Watch for deliveryIntents, parts, and sentIntents being null.
Also do some code style cleanups.

This is based on http://review.cyanogenmod.org/#/c/46009/

Change-Id: I4abe2a2bd3e45bafde32de3a0c81576d742e4cee
Properly handle a null URI.

Change-Id: Ic144986f6935e9a2df0073869a6a8b4e863a6128
JIRA:CYAN-2491
CdmaLte: call setDataRegState when using RilVoiceRadioTechnology for data

When using the VoiceRadioTechnology to set the DataRadioTechnology
(by using usevoicetechfordata in ro.telephony.ril.v3), the actual
data registration state needs also to be updated with the service
state depending on the VoiceRadioTechnology. Without this, no data
connection would be established.

Change-Id: I72cd3ef2d40e62cf408cf79ee8d884da8675c1ca
Merge tag 'android-4.4.2_r1' into HEAD

Android 4.4.2 Release 1
Fix cdma data calls based on NV

For NV data calls we need to create dummy profiles
When DcTracker switches from lte to cdma we need to bring
down existing data call and establish new one (same goes
for switching cdma->lte)

Bug: 10804691
Change-Id: I7ad8d0632854ea9875afb76709c1ba894bf048fd
(cherry picked from commit 4ead798ed4964952c3086b3224d775479d66d240)
(cherry picked from commit f333f0ca7b1c992ab36af83ca74a1131d3ae17b8)
(cherry picked from commit 14e5657432de2eb9ba52ebf28a8967ed62ee4a0b)
Merge "Properly handle a null URI." into cm-11.0
Merge "Fix cdma data calls based on NV" into cm-11.0
Merge "GsmSS: Use data tech in isConcurrentVoiceAndDataAllowed" into cm-11.0
Revert "Fix cdma data calls based on NV"

Causing a wild issue on d2vzw and jfltevzw.
If you connect to wifi, data will be broken when you disconnect
unless you reboot the phone.  Reverting this and the dependant
base change fixes the issue with data coming off wifi.

This reverts commit 7cd6a99e125fe292eb6a78f8d8a307762eea320d.

PS2: Retain some NV pieces
PS3: Fix compile
PS4: derp

Change-Id: Iaad556f46bf5d35483f1c44c054945511d8c4234
SamsungCDMAv6RIL: update to latest RIL

Also add two mic state and WB AMR

Change-Id: I0a9fdbbfa7880f964c530b7aa3e46baf2fe9e6c1
Merge "CdmaLte: call setDataRegState when using RilVoiceRadioTechnology for data" into cm-11.0
Could not enable data connection

Could not enable the default type APN in below case:
1. Default apn exists, connect wifi
2. Delete default apn
3. Disconnect wifi

enableApnType won't reactivate default apn type when no
default apn exists. Add default apn criterium to avoid this.

Change-Id: Ic8699669e576e5d2140852f359e34ed6c3275633
Merge pull request #3 from CyanogenMod/cm-11.0

merge CM 11.0