Upstream change I732234a22328a1bfcb603bb020547f543b6fd766 makes
RIL_UNSOL_DC_RT_INFO_CHANGED's responseFunction() NULL, without
protecting against it in RIL_onUnsolicitedResponse(), thus crash-
ing at least hammerhead's RIL stack upon mobile data connection.
https://android-review.googlesource.com/#/c/platform/hardware/ril/+/345950/
Change-Id: I6567019cb6daf6492a29e04cc9872e69b2ba456d
Signed-off-by: D. Andrei Măceș <Andrei.Maces@alumni.nd.edu>
(cherry picked from commit e73eafff8695ab28201acbc03a362d5b177047aa)
* All of the libsec-ril*.so libraries reference these symbols, but
Google finally dropped the non-inlined versions from libcutils with
Android 8.0. This could be handled with shims in numerous device
trees, but shim semantics and implementation aren't exactly stable
and we can handle it more cleanly here in one place.
* See LineageOS/android_system_core@103e8f560
Change-Id: I787372b739f3ace0d9cbbc33e4bffafa6876665e
* While msm8974 is not 64 bit, certain users of this libril will be
* A previous revision of this libril had 16 bytes of padding in this
struct for 64-bit platforms (due to word size and struct alignment),
but a change by me to use a long instead of a pointer and an int
broke this padding for 64-bit platforms because a long is still
just 8 bytes on 64-bit platforms, where 16 bytes is necessary
* Use two pointers as padding instead to make 64-bit great again
Change-Id: If599bdb625f7a45e083f5b30df512d12810be79b
* This is based on how it was done in cm-14.1, but redone
because the old code completely ignored signedness
* Samsung, in their stock RIL.java, reads index as an int,
sets the first 8 bits to index, the next 8 bits to call_id,
and ignores the upper 16 bytes of the int parcelled up
* This emulates that behavior here, except it only sends the
first 8 bits so that AOSP's RIL.java doesn't get confused
Change-Id: I5c78447fdef7d5fd7fc39addb970300ee1188cd1
* 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
* 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
* Check if there's *enough* data rather than the *exact amount*
to fix a bunch of invalid response errors
Change-Id: I14bc37240e5760b4629fcb74b64f25ad95d4fdfc
* 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
***** SIGNAL STRENGTH HACKS NOT PORTED YET *****
[javelinanddart]: Redo this code from 14.1 to include
the proper RIL_Call fixes, no Samsung unsol/request
handling as it was unnecessary, and a extensible way
to remap RIL unsols if necessary for the device
Change-Id: I59bad9925d141e6cefbc24d4eefdc0c79017852a
