Implement a smarter system on whether to connect
to the provided 2Ghz or 5Ghz network.
Change-Id: Idd41e3d9a5e2bde3ea9b4873dffc4274d1530324
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
Setting the beacon missed count threshold
with a difference of 10 to improve stability
of the WIFI connection.
Change-Id: Iea459ead3505bcea1a41f9b0e713957092bf4745
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
* Since someone was funny enough to label display.qservice
as 'service' instead of 'vndservice' in legacy qcom sepolicy
I'm forced to move these back to passthrough ;-;
This reverts commit a8fd5e61e0.
Change-Id: I4fb729fce584450499b55cc7b8815e9768dac846
The core SEPolicy for vendor_init is being restricted to the proper
Treble restrictions. Since this is a legacy device, it is tagged as a
data_between_core_and_vendor_violators and the needed permissions are
added to its device specific vendor_init.te
Bug: 62875318
Test: boot 8976 targets without audits
Change-Id: I13aaa2278e71092d740216d3978dc720afafe8ea
The new camera interface calls set_callbacks with a pointer
to it's internal CameraDevice and expects following calls to
the callbacks to use that pointer.
Store the pointer in the camera wraper and intercept the
callbacks calls to pass it along.
Change-Id: I99f02484e12a3f72cf1be13f1c724f474a452d7f
* This has now turned into a separate repository (maintained only
for legacy devices, those that never got official Orea updates).
Change-Id: I981b452b697bc3610d7aa97b74ed182c6b70ca30
Our camera blobs trigger some checks for broken behavior (destroyed
mutex usage, invalid pthread usage) present in newer API levels.
Change-Id: I8705437e0a5c6d80b86748bff559ce1e8a7bf716
* Our camera requires 0x02000000U. Per headers from exynos5420,
this appears to be USAGE_PRIVATE_NONSECURE.
Change-Id: Ie5a8a46fef1c0f28ebd2cd3b3d29cc19763bc2a3
enable narrow search range for video encoding
Change-Id: Ica0de8c893fdabf1b4393abe72291814bb708f74
(cherry picked from commit 819706119048a5818560ff7dbd1cc5feb0229da0)
* Google has been tightening up mutexes by disallowing calling
pthread_mutex_destroy on an already destroyed mutex in P
* This normally isn't an issue, but Qualcomm, in their infinite
wisdom, decided to destroy a mutex in a loop in isp_module_stop_session
when they were freeing some related memory allocations
* This results in a SIGABRT in mm-qcamera-daemon from a
__fortify_fatal call in HandleUsingDestroyedMutex in libc
* To work around this, the CBNZ instruction (aka, the break condition)
in the loop was moved before the call to phtread_mutex_destroy so
that the during the 2nd (and final) iteration of the loop, it exits
*before* rather than *after* the calls to pthread_mutex_destroy
* ASM instructions:
- Before: https://gist.github.com/javelinanddart/9afdc8577134bf8ecd48b15213d66491
- After: https://gist.github.com/javelinanddart/789ba3bde8494ff4ba0b7967c93daa14
Change-Id: I36dfab9f3afb8c9e010da8c6b02c2d9eff856c07
Srinivas Girigowda
Alex Naidis
syphyr
LuK1337
Kevin F. Haggerty
Tom Cherry
Demon000
Bruno Martins
codeworkx
RAJATH R
Danny Baumann
Michael Bestas
dianlujitao
Ethan Chen
Paul Keith