Some devices have extra pointers in this structure that if non-zero
causes libsec-ril.so to segfault
Change-Id: I9fd07a4747ef0fb1388ebbec472f2dda8dea4003
* From P onward samsung changed the socket name in libsec-ril.so from
Multiclient to VND_Multiclient.
* In order to not break compatibility with older RIL stack guard this
behind TARGET_USES_VND_SECRIL.
* This is mostly relevant when using P (or newer) prebuilt ril stack
coupled with OSS audio hal from hw/samsung, which depends on OSS
libsecril-client to provide connection to the RIL daemon.
Change-Id: Iab5d07f2301d33216bbdf3e18f844522e32fadce
(cherry picked from commit 6d6c0500f3139f84163eefefc8e19dcc934ef26a)
Tuned the Binder buffer to 500KB as it is not
going to use the default allocated 1MB which
saves RAM for 32 bit processors.
Change-Id: Ifea2720f8e853643a37912c3459e923168677b1e
CRs-Fixed: 2283052
Use strlcpy instead of strncpy when copying strings to make sure
the copy is always null-terminated.
Change-Id: I12d4883c22a180e2136dc8c85bc0394ddcdcb706
guarantee non-null function pointer before rild register its hidl service
Test: Build and local test
Bug: 78886552
Change-Id: I1137cc0f4f09f0304662a2227b84c2b5b228d45d
OEM hook is deprecated, so adding a way to disable it to
this radio implementation.
Bug: 75322118
Test: boot device w/ DISABLE_RILD_OEM_HOOK works, lshal
Change-Id: Ie7ade48476d2c330df608e9cc8dab805f84dd81d
received.
If cached value for NITZ is used, the time at which it was
received needs to be cached too.
Test: Basic telephony sanity
Bug: 72283604
Change-Id: I8f443171c4583e3eab9be7973d7714ae6c7ab6af
service and add null-checks.
The payload of a SAP request could be freed twice in certain scenarios.
Also, add null-checks to prevent dereferencing of null pointers.
Bug: 64729356
Test: Manually run the fuzz tests and ensure that there is no crash in
rild
Change-Id: Ib7ae269fa5297d6acea267337b220b8858c82bae
RIL_RadioFunctions
Re-add constant for function pointer table to
RIL_RadioFunctions. Const was accidentally removed
during a warnings cleanup.
Bug: 64231560
Test: compilation
Change-Id: I93675980c51d9162f624495d12fe3c97f1da8031
clang is the default compiler since Android nougat
Change-Id: I0555fa8067352fd43b47aabe80be1224597da17e
Signed-off-by: Lennart Wieboldt <lennart.1997@gmx.de>
* 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
Before:
if (response == NULL || numStrings != 3) {
After:
if (response == NULL || numStrings != mqanelements - 2) {
This patch fixes the logic so we don't change the value check.
"mqanelements" is not related to getOperatorResponse, so get get rid of
the affected code.
Change-Id: I86c6ae7b7492a5d04fbc8dc415c4f615e7d05bab
if a kernel device returns an I/O error, it is better not to chew
the CPU resources retrying I/O operation on a not ready device.
Fixes periodical 100%-core load in audioserver after a voice call
completion.
Change-Id: I2b66ffd18c85823a11e50598a6b4e3c0245a0083
On some devices, like SM-T805 (Galaxy Tab S 10.5 LTE), the RIL client
code produces errors "SendOemRequestHookRaw: No token" due to large
amount of tokens allocated by OEM messages requiring no response from
RIL daemon (like set call audio path, set call volume, set mite etc).
The indicator of an OEM message with no response expected is:
RegisterRequestCompleteHandler(client, REQ_XXX, NULL);
inside the RIL client message method. To prevent the token pool from
overflows, the proposed patch de-registers the token and frees its call
history if the handler for this message req_id is set to NULL.
Change-Id: Id414263bf471115797cae1a9ed628249734b9347
Exynos4 devices send two ints as a response to this request,
causing responseFailCause to think the result is a LastCallFailCause struct,
which it then tries to treat as a Java UTF-8 encoded string, causing a
crash.
Work around this by forcing responseInts (the original behaviour)
on Exynos4 devices.
Change-Id: Ied14948db3049066ffc760b6d3df09b4cefa2df0
* Instead of messing around with indices, look up
the requestNumber in the array.
* This has a cost of O(N) instead of O(1) with the
previous implementation, but we don't receive unsol
response codes frequently enough to be worried about
this.
* This was needed because a few vendor reponses, aka
RIL_UNSOL_SNDMGR_WB_AMR_REPORT at index 33 and
RIL_UNSOL_SNDMGR_CLOCK_CTRL at index 34
could not be addressed by their array indices anymore
because we cannot calculate their index by the unsol
response code we receive from the modem.
Change-Id: I27319e621c777fe19ae8908d7e0c4a46d6dd6d3b
* Adjusted whitespace to minimize diffs
* Plugged memory leaks
* Fix use-after-free
* Use calloc instead of alloca
* Reworked the Samsung request/response code to be
more readable
Change-Id: Ifd07b525fc84e8a3fca584d4d412785974ca3482
Tim Zimmermann