The kernel does not support aio with ffs.
Set the property so adb/mtp know to use the compatible
functions, and the same while in recovery.
Bug: 37916658
Test: Use adb / use adb in recovery
Change-Id: Id35a05fcb9952dcf7239bd15a61cc620537419bc
* 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
Jeff Johnson
Jerry Zhang
Steve Kondik
Bruno Martins
Michael Bestas
Kevin F. Haggerty
T H
Danny Baumann
Paul Keith
Nolen Johnson
Cal Archer