- move all the code related to EGL extensions in one place
- add missing extension strings:
EGL_KHR_lock_surface
EGL_KHR_reusable_sync
- add public extensions strings and entry-points
EGL_ANDROID_wait_sync
EGL_ANDROID_presentation_time
- add missing entry-points for EGL_KHR_reusable_sync
Change-Id: Ifd98966b549e8efd8ef5385eba0efde8c4cbc77b
This change adds support for the -a command line argument to atrace. This
argument sets the comma separated list of application names (i.e.
/proc/self/cmdline values) for which to enable application-level tracing.
Change-Id: I812d57c4cdc581943247229413f09b7e1adc10d0
In gcc 4.8, the warning for unused parameters (such as JNIEnv* pointers
in JNI functions that don't need it) is enabled by default - causing
-Werror to break the build.
Change-Id: Ib91721f2cb9912b79c2ac19b4210b1309b08304f
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
This patch set allows the PMS to parse the
mac_permissions.xml file which contains the
seinfo values. Each package that is installed
on the device will be assigned an seinfo value
based on policy. This seinfo value will help label
the app process and data directory. Modifications
include adjustments to ApplicationInfo.java
to store the seinfo tag per package as well as
adjustments to installd to communicate the seinfo
tag to libselinux.
Change-Id: I61ad1ea12fb6a9a6d0b108ec163bc4bf4c954b58
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
8323587: Add feature for supporting app widgets
8323342: Add feature for replacing the home screen
8323590: Add feature for supporting input methods
The app widget service looks for the app widget feature
and refuses to work if it doesn't exist. I didn't do
this for the input method service because some devices
will probably want to still make use of that mechanism
without supporting third party input methods.
Change-Id: Ia358ccc6059d43f163d74810c7cbe9568a67ede9
If we're using a HWC that doesn't support virtual displays, or we have
more virtual displays than HWC supports concurrently, the
VirtualDisplaySurface should simply be a passthrough from source
(GLES) to sink.
This change also tries to distinguish between display types and HWC
display IDs a little better, though there's more to do here. Probably
needs a higher-level rethink; it's too error-prone now.
Bug: 8446838
Change-Id: I708d2cf262ec30177042304f174ca5b8da701df1
HWComposer didn't allow the virtual display output buffer to be set
directly, instead it always used the framebuffer target buffer.
DisplayDevice was only providing the framebuffer release fence to
DisplaySurfaces after a commit.
This change fixes both of these, so both HWComposer and DisplayDevice
should continue to work if VirtualDisplaySurface changes to use
separate framebuffer and output buffers. It's also more correct since
VirtualDisplaySurface uses the correct release fence when queueing the
buffer to the sink.
Bug: 8384764
Change-Id: I95c71e8d4f67705e23f122259ec8dd5dbce70dcf
- added a ctor that updates and dumps the stack immediately
- added a "logtag" parameter to dump()
Change-Id: Ie51c256071d282591752243bdb4f68cf9ff8829d
some drivers don't support this yet, so we use a system
property to enable the glReadPixels "workaround" for them:
ro.bq.gpu_to_cpu_unsupported=1
Change-Id: I74d6a3a8f0cee8d5a507b72c760cf247e39195e0
Previously we only queued a virtual display buffer to the sink when
the next frame was about to be displayed. This may delay the "last"
frame of an animation indefinitely. Now we queue the buffer as soon as
HWC set() returns and gives us the release fence.
Bug: 8384764
Change-Id: I3844a188e0f6ef6ff28f3e11477cfa063a924b1a
We're not using IMemoryHeap as a transport anymore,
instead we're providing a CpuConsumer and use the
IGraphicBufferProducer version of the screenshot API.
However, some GPU drivers don't support properly
a GPU to CPU path, to work around this, we use a
temporary BufferQueue on the server side for the
GL rendering, and we use glReadPixels into the
CpuConsumer (we're now using a CPU to CPU path
which is always supported).
Currently this "wrapping" is always performed,
but it can be bypassed on devices that support
the GPU to CPU path.
This also addresses a DoS attack vector on
SurfaceFlinger, where an application could
consume all of SF's filedescriptors by creating
a lot of screenshots in a row.
Bug: 8390553
Change-Id: I9e81514c2a7711b9bb393f74305be7d2abe08f1c
