This change allows clients of Surface to provide an IProducerListener
callback object to Surface::connect, which will be passed down to the
underlying IGraphicBufferProducer.
Cherry pick of I5ea5229bf3a329bf02c6bd20e7247039c75d136b
Change-Id: I6f8f52c72654e4cee649721383819bafe378f964
Since some variables had been switched from signed to unsigned, there
was a section of code that was guaranteed to be incorrect because it
effectively did 'if (a < b) { c = a - b; }'. This change fixes it.
Cherry pick of I9cdd6c9a0179801addebb5d6dc1fbaddf8f53c62
Bug: 19346631
Change-Id: Id13a46f74c9ae7278463ce22b586f4dc21b5e453
There shouldn't be more than 4096 fds (probably signficantly smaller) and
there shouldn't be more than 4096 ints.
Cherry pick of I3a3e50ee3078a4710e9737114e65afc923ed0573
Bug: 18076253
Change-Id: I82a883572b401f115d252dcd3d00aa7252b49b0e
Enables -Weverything and -Werror, with just a few exceptions for
warnings we can't (or shouldn't need to) work around.
Cherry pick of I034abec27bf4020d84af60d7acc1939c59986dd6 plus a
couple of minor changes to CpuConsumer.cpp to make it work with a
prior change:
Uncomment CC_LOGV on line 46
Change C-style cast to static_cast on line 71
Change-Id: Iaec610477ea0122317b0578fb74caf2383d4cf08
Adds CpuConsumer::{detachNextBuffer,attachAndReleaseBuffer}, which
can be used to more carefully manage the ownership of GraphicBuffers.
Bug: 19628705
Change-Id: Ia7a7e30da6d81eb2367241998f14988db0afc3bf
Exposes the attachBuffer and detachNextBuffer calls from
IGraphicBufferProducer to the public Surface interface. Also moves
the version of connect that takes a producer callback from protected
to public.
Bug: 19628705
Change-Id: I9ebc3013c4d9c84c4e8ef150c00e03f8af80319e
Adds CpuConsumer::{detachNextBuffer,attachAndReleaseBuffer}, which
can be used to more carefully manage the ownership of GraphicBuffers.
Bug: 19628705
Change-Id: Ia7aa1ac59c2f768f2d8a0f35ad23067936a7427c
Removes IGraphicBufferConsumer::BufferItem. Depends on the
following changes:
I187b3a7d05196b6289596afac8fb9a9d4aebff76
I0ddd38df37500cfd6b21d1e768ed14e39c5cd9fc
Change-Id: Id1fa56d092188f2cb712768d5d2fc6a9027fb73c
One of the overloads of BufferQueueConsumer::acquireBuffer was
calling itself infinitely instead of calling the other overload.
This fixes that issue.
Bug: 19733425
Change-Id: Iac8425e1241774304a131da2fb9dec6e82922f13
Switches all uses of IGraphicBufferConsumer::BufferItem (and
BufferQueue::BufferItem) to the BufferItem in libgui. Depends on
frameworks/native I699ed0a6837076867ca756b28d1ffb2238f7a0d9.
Change-Id: I187b3a7d05196b6289596afac8fb9a9d4aebff76
Switches some dependencies from IGraphicBufferConsumer::BufferItem to
android::BufferItem and adds some methods to facilitate incrementally
changing client code to do the same.
Change-Id: I699ed0a6837076867ca756b28d1ffb2238f7a0d9
Adds an overload of IGraphicBufferConsumer::acquireBuffer which takes
an android::BufferItem instead of an IGBC::BufferItem.
Change-Id: I9c3bc8037fa9438d4d9080b8afb694219ef2f71f
Currently, there are two instances of BufferItem: one inside of
IGraphicBufferConsumer, and a standalone one inside of libgui. They
only differ in the name of one of the fields, so this change modifies
the one inside of libgui to have a union of both names so that the
one inside of IGBC can eventually be refactored away.
Change-Id: I64f495105f56cbf5803cea4aa6b072ea29b70cf5
Adds a --static-screen option to dumpsys SurfaceFlinger, which
displays screen-on time broken down by the time between the prior
frame and the current frame. An example dump looks like this:
$ adb shell dumpsys SurfaceFlinger --static-screen
Static screen stats:
< 1 frames: 12.235 s (3.5%)
< 2 frames: 29.898 s (8.7%)
< 3 frames: 15.370 s (4.4%)
< 4 frames: 13.103 s (3.8%)
< 5 frames: 15.780 s (4.6%)
< 6 frames: 2.022 s (0.6%)
< 7 frames: 0.201 s (0.1%)
7+ frames: 256.887 s (74.4%)
The buckets are exclusive, so '< 3 frames' covers the interval
[2, 3) frames
Bug: 19543586
Change-Id: I3253a54c23995d25e96016997acedd0775956b60
Reorder the find permission checks. This avoids generating misleading
SELinux denials when a service doesn't exist, or when a service is
prohibited to isolated apps.
The original reason for structuring the code this way is explained
in https://android-review.googlesource.com/#/c/100530/4/cmds/servicemanager/service_manager.c@172
The concern at the time was to avoid leaking a situation where
a caller could probe for the existance of a service. This turns out
to be unnecessary. The same return value is used for both a
permission denied and a service not found. The only side effect
is the generation of an SELinux audit log, which likely won't be
accessible to the calling application.
Change-Id: I9760e1821ed16102fa5f9bec07f8c34944565be9