* This fixes auto time zone
* This is related to how it was handled in the
old SamsungQualcommRIL class (deprecated) but
the Parcel is fixed rather than handling it
directly in the RIL subclass
* This is done because after we handle it,
it's still handled by processUnsolicited
in the super class, which undoes our changes
* The extra "garbage" that is sent in the
RIL_UNSOL_NITZ_TIME_RECEIVED parcel seems
to be country MCC code for whatever reason
Change-Id: I70982873e6304d81794bdd03eb8d9a1c1d3f3a55
* Commit 722ab7ae6d inadvertently
removed the entry in ueventd.qcom.rc that sets ownership and
permissions for the NFC device node used in kltedv and kltespr
devices
Change-Id: Iae2758603b9cb91aa011e105b0d964561d9e362d
* Disable MSB. Quicker and stronger lock. Winning.
* All regions/carriers are now (GEOFENCE|ON_DEMAND_TIME|SCHEDULING)
* CDMA carriers were already set to this value
Change-Id: I2b060a11795a97889e96b3d7de26b0ed28392841
* Allow splitting of blob list into multiple to better manage
situations like klte which has multiple variant blob sets.
Change-Id: I74f2d0c3a414ba6c250ef9dbee3218db07fc51c2
* General idea shamelessly kanged from m8
* Copy instead of symlink because we need the libril shim and doing
that for each variant is non-scaleable
* Will only be used if explicitly called-for by dependent devices
Change-Id: I15b4b25d3e1b8856a9f8df2f2c6b72c0e55a6d66
* Let everyone know which revision of blobs we expect to build against
* Now to remember to maintain it...
Change-Id: I9820a828d07b978349731b2bc28e890e996ad170
* This is one main step toward future consolidating of some klte*
builds
* Approach taken from Nexus/Pixel devices, values based on
previously functional variant gps.conf files combined with
LPP_PROFILE tuning by carrier from marlin
Change-Id: I9a66eb156df69340d35c139d20f835fa8693a716
This reverts commit 92828016a3.
* Do not ever ever ever use this partition for anything, not even if
someone has a gun to your head. It will cause misery and make
EVERYONE want to murder someone. And only you will know it is you.
* This was the cause for the "gapps upgrade makes klte unuseable"
problem.
Change-Id: Ibd69a528a1f3df4d8146472d1dc977676c72bbed
* These branded firmware files don't actually exist in stock images,
but it is important for libbt performance that they live in the
builds. Prevent oopses.
Change-Id: I8e8cb62f978e898f4b3ef95938cb6ece6c5b51fa
Squash of the below two commits
* msm8226-common: Generate graphics vendor Makefile if missing
This allows to build CM without cloning vendor repos.
Change-Id: I87777485edc5f29c5899091176e55d28e36bb263
* msm8226-common: Fix blobs extraction with no vendor repos
Commit bff1cb1def84 ("msm8226-common: Generate graphics vendor
Makefile if missing") fixed only the generation of the makefiles,
but it didn't take care of the actual extraction of the blobs.
Change-Id: Idd38fbff554c0dac4b7cb8a867abb017bf37afc3
Change-Id: I3d6b70c8fdedfb624791fe3281c02df1c190d598
* Symlinking the files seems to be horrendously brittle. Sometimes
after a nandroid restore, the OS would helpfully "upgrade" the
symlink to the new location, causing self-directed symlink for these
criticial files.
* This actually handles the nandroid restore path.
Change-Id: If53d7ddfb7493df1526b7578be3ccf9a63997234
This is a follow-up to Ifb15e64b4c351d7195e5ad3f5d5315419790d0f8.
The change fixed a crash upon deactivation of torch mode by removing
code that forecully set or unset Zero Shutter Lag. This change results
in HDR not working anymore, but SEGFAULTing the camera instead. The
commit addressed this by disabling HDR entirely.
The present change reinstates the removed code, but executes it
conditionally only if the camera is not in torch mode. This prevents the
crash upon disabling torch mode and simultaneously leaves HDR in a
working condition.
Torch mode can only be reliably detected when it is activated by checking
whether the requested settings have a "flash-mode" of "torch" set.
Deactivation simply asks to deactivate the flash, which cannot be told
apart from the camera app requesting the same before taking a photo. The
CameraWrapper however stores the current settings, so by checking if
they contain a "flash-mode" of "torch", it is still possible to detect
the mode's deactivation. The only possible problem with this approach
could arise if the camera went directly from torch mode to camera mode
with HDR, but this apparently does not happen.
Change-Id: I71611257868b3bf86041adf7aed931cf92880ddc
* Autodetection code is not working properly, leading apps (e.g., TI
Backup) to not present the appropriate menu button/icon
* Credit to XDA user Zoomed for noting the problem and appropriate
overlay
Change-Id: I62b035f88ad212fdfe0d00ab0473f8b7119c50cb
* Our sensor firmware is weird, and breaks
when there's a batch size set
* Let's opt-out of setting a batch size in
order to fix rotation on our devices
Change-Id: I3e930087f989a2b52078872219366ea59f53a6f3
Signed-off-by: Paul Keith <javelinanddart@gmail.com>
* These aren't any more proprietary than the audio configuration and
should be able to be edited as such
Change-Id: I08e3a2c751e680acfda591452a925553c94e57f9
Gabriele M
jrior001
Kevin F. Haggerty
OzzysCmAcc
Kevin F. Haggerty
Andreas Schneider
Phillip Berndt
Paul Keith