* Some legacy Samsung HALs supporting BODY_SENSOR types are
incompatible with the new permission checks added in M.
Extend the NO_SENSOR_PERMISSION_CHECK flags to cover more
of the actual checks.
Change-Id: Id2b9b57d8151b0998d9233e0a6541e8c88e06af7
This is needed by Samsung devices with pre-M sensor
blobs which have support for SENSOR_TYPE_HEART_RATE
or body sensors in general.
These HALs somehow segfault on the flagged code.
Change-Id: I698f4129e71b683f6f063f00da79f32a5f521149
In a4650a5 the concept of a maximum frame number allowance for the consumer was
introduced. A call to acquireBuffers will only return buffers when their frame
number is less-than-or-equal-to this maximum frame number. When SurfaceFlinger
is the consumer, this maximum frame number is calculated in the
onFrameAvailable/onFrameReplaced callbacks. These callbacks are called when a
new buffer is dequeued by the application. The problem is that these callbacks
are called _after_ the fence wait which is used to throttle the frame
production of client apps. When the previous frame needs a long time to draw,
those waits can potentially be a long time. As a result SurfaceFlinger won't do
any composition with the new frame until the wait is over.
Normally this isn't a big problem because there is a queue of buffers for
SurfaceFlinger to work with. However, this changes massively when a client app
is using a swap interval of zero. In this case, a new frame will instantly
replace the previous queued frame. However, SurfaceFlinger doesn't know this
until the onFrameReplaced callback gets called - which is delayed by the fence
wait. If the timing is bad, SurfaceFlinger never gets a chance to pick up a new
frame to do the composition with.
We see this behaviour on our TC development system (slow GPU) with legacy
on-screen benchmarks. Such apps are using a swap interval of zero and sometimes
frames don't get updated for several seconds. This behaviour can be also seen
on a Nexus5, although it isn't as obvious as on our TC.
The fix in this cl is to move the EGL throttling to the end of the queueBuffers
function. This ensures that if a frame gets replaced in the queue, all
consumers who installed the callbacks, get called in a timely fashion.
Change-Id: I36e9ecda162150f41e97d4fb7437963a3d86b371
Signed-off-by: Christian Poetzsch <christian.potzsch@imgtec.com>
Looks like a full GPU path is less efficient on some GPU
drivers that we're still using, and CPU is reliably faster...
(there's probably a locking condition going on somewhere, this
needs to be looked into)
Change-Id: I8878796a117d65bf2324507cf8755cadce49f6dc
Squashed commit of the following:
commit 012d3fe41d1d6cd38a0858b59145e9a4447641fa
Author: Hashcode <hashcode0f@gmail.com>
Date: Sun Dec 8 19:36:50 2013 +0000
sf: Always use opengles for screen capture
Go back to the usage of GRALLOC_USAGE_HW_TEXTURE and GRALLOC_USAGE_HW_RENDERER
in captureScreenImplLocked regardless of useReadPixels value
This fixes the EGL_NO_IMAGE_KHR error returned from
eglCreateImageKHR (blank images returned from screenshot path)
Change-Id: I62fe90a081607b9e89c67f3dcfd34c84efc89d35
commit 4866ddf98ac98d8e22a1cd6a21894bb17f274588
Author: Ricardo Cerqueira <cyanogenmod@cerqueira.org>
Date: Thu Oct 31 03:53:39 2013 +0000
Revert "remove support for glReadPixels screenshot path"
This reverts commit 3ca76f416b.
Conflicts:
include/gui/ISurfaceComposer.h
libs/gui/ISurfaceComposer.cpp
libs/gui/SurfaceComposerClient.cpp
services/surfaceflinger/SurfaceFlinger.cpp
services/surfaceflinger/SurfaceFlinger.h
Change-Id: I8c239e533757af770e418dbb198f5a86c736961f
Change-Id: I8c239e533757af770e418dbb198f5a86c736961f
Inside Surface::lock if new buffer is allocated
and DirtyRegion does not cover complete buffer
bounds then copyback may not cover all remaining area
as it copyback only area covered by dirty regions
from other buffers. This will lead to left out
black area which may cause flicker.
Change-Id: I4a3f7a56fc5fbaf4af926584919577d8d34bed57
Copyback dirty region logic does copyback,
even when its not necessary causing 2ms delay.
Fix the logic to copy back only what is necessary
CRs-fixed: 562334
Change-Id: I52de68258ac9f87d704ee5401f93417805fa6773
The uninitialized local variables pick up
whatever the memory content was there on stack.
This data gets sent to the remote process in
case of a failed transaction, which is a security
issue. Fixed.
(Partial manual merge of master change
12ba0f57d028a9c8f4eb3afddc326b70677d1e0c. Rest
to automerge from klp-dev)
For b/23696300
Change-Id: I704c9fab327b3545c58e8a9a96ac542eb7469c2a
The uninitialized local variables pick up
whatever the memory content was there on stack.
This data gets sent to the remote process in
case of a failed transaction, which is a security
issue. Fixed.
(Partial manual merge of master change
12ba0f57d028a9c8f4eb3afddc326b70677d1e0c. Rest
to automerge from klp-dev)
For b/23696300
Change-Id: I704c9fab327b3545c58e8a9a96ac542eb7469c2a
The uninitialized local variables pick up
whatever the memory content was there on stack.
This data gets sent to the remote process in
case of a failed transaction, which is a security
issue. Fixed.
(Manual merge of master change
12ba0f57d028a9c8f4eb3afddc326b70677d1e0c )
For b/23696300
Change-Id: I665212d10da56f0803b5bb772d14c77e632ba2ab
If the custom sensor requires the BODY SENSOR permission, we should add
the body sensors app op for the custom sensor
Bug: 23396558
Change-Id: I132917d1bca12c76c8a9fb146e00951cba3e6d7a
