* Checking numInts and numStrings for strict equality when
we're not looping is dumb, because Samsung is notorious
for sending extra information in their RIL (mostly VZW)
* Check if there's *enough* data rather than the *exact amount*
to fix a bunch of invalid response errors for Verizon
Change-Id: I14bc37240e5760b4629fcb74b64f25ad95d4fdfc
* Sometimes, the modem is sending 1-2 extra fields with
the country mcc, which confuses ServiceStateTracker
* Drop the extra data here, instead of in our RIL class
[haggertk]: Forward port to ril-caf on lineage-15.
Change-Id: Ifbec67bb0dac271226bd8b5471deaf6a2ef33f2b
* For search, the number of strings returned for
RIL_REQUEST_QUERY_AVAILABLE_NETWORKS should be defined in the system
prop ro.ril.telephony.qan_resp_strings
Change-Id: Ie5bb8ba80c5ac93b7502da3b1bb3d2b4404ecd5e
* Samsung added an int to the end of the RIL_SMS_Response
struct in some of the variants (like vzw) but not all
* The presence of this field was discovered by examining
the stock RIL.java, which conditionally read an extra
int from the parcel, based on the device specific
CscFeature_RIL_SmsErrorClassRetry feature
* This causes SMS messages to show as "failed to send"
in the app, when they actually suceeded in sending
* Allow Samsung's custom struct and AOSP's to fix it
* Forward port to ril-caf on lineage-15.1
Change-Id: I6b3e545c2c42ab2de2ac11e93dfdf9546248080a
* Changes in ril.cpp based off of hardware/samsung/libril
[haggertk]: Forward port to ril-caf on lineage-15.1 by
remapping all the samsung unsol responses
to NULL with the old response in a comment,
and all the samsung requests to NULL with
the old request mapping in a comment.
This is safe because nothing in AOSP knows
about any of Samsung's requests/responses
***** SIGNAL STRENGTH HACKS NOT PORTED YET *****
Change-Id: I59bad9925d141e6cefbc24d4eefdc0c79017852a
Paul Keith
Martin Bouchet
Kevin F. Haggerty