* In O, the default setting for mobile data always active was
changed from off to on, meaning that when non-WiFi tethering
is being attempted, more than one connection can be active
* Since the first active connection type in this overlay is used,
reorder the values to get WiFi connections first, and then
any type of mobile data connection, instead of vice versa
Change-Id: I41f31ba1a2793e209ff439c9ba28a390fecdeecb
* This is needed for Trust, as we don't have a Vendor image that sets a
valid vendor security patch level.
* Taken from the G900FXXU1CRA2_G900FOXA1CRA2_BTU Factory Image.
Change-Id: I105cc7e464e581683c6784e3aef8f7297b90aea0
* We have included the appropriate android_atomic methods in libril,
so the symbols are loaded into the process space and the libsec-ril*
dependencies for all builds are handled.
Change-Id: I93289af789df7e263488e1db29bdbde0d0964e97
* Recent binder changes caused our approach of shimming libcutils to
re-add the non-inlined android_atomic* methods to start getting
slapped, at least with NDK apps. This looks oddly similar to the
heads-up we received in 7.0, so no clue why it let us do it in 8.*
prior to now.
* See: https://developer.android.com/about/versions/nougat/android-7.0-changes#ndk
* We did this because all of the libsec-ril* blobs and libuiblur
needed it and doing each and every libsec-ril seemed fragile and
fraught with the potential for error, but "fragile and fraught with
the potential for error" is better than "phone breaking". And blur
doesn't seem to ever be coming back.
* We'll leave the "standard" libsec-ril.so here and let the
individual devices handle anything specific if they have variant-
specific blobs
Change-Id: Ib11048e4924f34ade20f44b707f0106e139f2f82
* vcs_device is used to label /dev/vcs*, which are virtual consoles
* Create and use our own label for /dev/vfsspi so our fingerprint
hal can access it, and rename vcs_data_file while we're at it
Change-Id: I01f0e8c4924d3847383319ce59dbbf802f89a36b
This reverts commit aee12a34df.
* No Samsung msm8974 device is going to develop an OSS camera HAL
at this point. Move this common stuff to msm8974-common.
Change-Id: Ib0bb18fe819e2ebbb39c9b278ccf687444f65488
* Mounting /system partition is handled in kernel now,
however removing the entry from fstab caused issues building
the OTA. The workaround was to have a separate fstab, but turns out
that simply setting the recoveryonly flag does the trick because
those are then ignored during a normal Android boot.
Change-Id: I2944384d0a1c41bc9f9f51e2e29daff2bed0a0f4
Note video HDR setting in Snap is only available
in Snap advanced settings at the very bottom of the menu.
Change-Id: Ia2d907aa5b20be6134bc3594684a423cf199f925
* We're messing with ownership and permissions here, so let's go
ahead and fix the context of this near worthless thing.
* The kernel will create it, we also write it here which will create
if it doesn't exist, so this is more manageable than chasing the
type_transition path
* The file is already labeled as a wifi_data_file, so fix this to
eliminate the below denial
avc: denied { read } for name=".wifiver.info" dev="mmcblk0p26"
ino=12 scontext=u:r:hal_wifi_default:s0
tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0
Change-Id: Ie736b68f7d4d8559237b5cce072c6bf26f7ac4e7
* msm8974-common may end up going back and forth between legacy
and HIDL HALs, so let's be compatible with both for the time
being.
Change-Id: I5067fc474d7878a0f68e25c70b723de0e813d7c1
* The bulk of this policy isn't specific to klte, so let's move
it somewhere that allows the maintenace of it to help other
impacted devices.
Change-Id: I57b0d24d25e5871c5aa69d415b94ca21f89c1794
* Some idiot did a 'git push lineage HEAD;refs/for/lineage-15.1'
instead of a 'git push lineage HEAD:refs/for/lineage-15.1'.
Do you see the difference?
* Delete all of the old policy items and commented-out lines like
the previous commit promised.
Change-Id: I6cd8a8cffc76661b6de486e6b8550bafa83f5de9
* In particular, the RIL on CDMA variants seems to only work reliably
on first boot after flash, when things are all slowed down while
dexopting. After that first boot, it's hit and miss whether a
particular boot will have function RIL
* Slow things down by limiting ourselves to a single CPU on boot,
bringing the rest online when boot has completed
Change-Id: Ie194740cf0487268dc0dbd3377bbb790cdd1b04d
* 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
* Because of how structure alignment works,
adding these unused chars here is unneeded
* This makes this structure more understandable
when looking at the stock RIL java class
* Move Samsung call details as the 8 bytes before
the RIL_UUS_Info pointer, to match stock
Change-Id: I2e62be0b1774209c0165ece90588ecb7aeb042e3
* 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
* mQANElements never made tremendous sense, the response strings
are not part of an object, just a text string making up a parcel.
* ro.ril.telephony.mqanelements -> ro.ril.telephony.qan_resp_strings
for consistency with some of the other new RIL props.
Change-Id: I6f941f5177852454a4d4b9494077329814d884f1
* 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
* Samsung added call_id as the second byte of index
* Split index to avoid a workaround in RIL subclass
* Add Samsung call detail fields, reorganize to fix
incorrect structure, to avoid hacks in RIL class
Change-Id: I023228c05165c0cef9b698846a96484a6d318092
* 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
* Importing this in init.qcom.rc, especially when not all builds
have it is hacky. We'll have those devices install the script
into vendor/etc/init and let init handle it automatically, just
like the primary rild.rc script.
* Update the package name to align with the new name of the script.
Change-Id: I8eaf76c5c4f0aa590ebb1a396afa837597ebc26d
