The inputs to native_handle_create can cause an overflowed allocation,
so check the return value of native_handle_create before accessing
the memory it returns.
Bug:19334482
Change-Id: I1f489382776c2a1390793a79dc27ea17baa9b2a2
(cherry picked from commit eaac99a717)
There shouldn't be more than 4096 fds (probably signficantly smaller) and
there shouldn't be more than 4096 ints.
Bug: 18076253
Change-Id: I3a3e50ee3078a4710e9737114e65afc923ed0573
...in Parcel destructor
Don't use a Mutux object, just use simple posix mutex primitives,
to avoid static init/destroy order problems.
Change-Id: Ic012d94297564c0a55d58869f8276d7d10545fbc
Passes the BufferItem for the queued buffer to the onFrameAvailable
callback so the consumer can track the BufferQueue's contents. Also
adds an onFrameReplaced callback, which is necessary if the consumer
wants to do anything more than simple queue length tracking.
Bug: 18111837
Change-Id: If9d07229c9b586c668e5f99074e9b63b0468feb0
On one device there is a bug, not yet root-caused, that causes fence
fds to not make it across binder from producer to consumer in the
IGraphicBufferProducer::queueBuffer call. Rather than returning an
error, which the producer typically treats as a fatal error, this
change allows the buffer to be queued with no fence. This avoids an
application crash at the risk of (likely single-frame) visible
corruption.
Bug: 17946343
Change-Id: I9ca89f94098c455e1e90f5f58d5336c936b04a9c
Previously it was possible to have the driver's eglTerminate called beofre
eglDestroyImageKHR in GLConsumer. This was because we didn't increment the
refcount for the lifetime of the image. This could lead to a crash or a deadlock
when multiple threads called terminate and destroy simultaneously.
Bug: 17700483
Change-Id: I7010d0f1b3db875332e95630b5e098a5564ba755
mmap returns MAP_FAILED (which is -1) and not NULL on
failure.
Diagnosed by cferris.
bug: 17909809
Change-Id: I609788ebf94742ef88af002d2d3f3bc9b9e520ac
Temporary extra debug validation for b/17477219: a Parcel recipient is
getting a positive but invalid fd unexpectedly. Trying to track down
where it's coming from.
Debug code for bug: 17477219
Change-Id: Idb1e71621025a3928c7adc88fd44790e1abd2a01
Throttling was previously controlled by a combination of the
driver and the number of buffers in the queue. This patch makes
a more consistent trade-off, which allows two GPU frames pending
but not three. More buffering could improve throughput in the
case of varying frame times, but this also increases latency.
Bug: 17502897
Change-Id: I4ee68019ca94c635294c5959931a555a6c4ef2df
i) Call removeFd() only if the fd in the BitTube has been
previously added to the Looper. Use a flag to determine whether the fd
has been previously added or not.
ii) Increment mPendingFlushEventsToSend after holding a connectionLock.
iii) Store the number of acks that are pending in SensorEventQueue
and send them all at once.
Bug: 17472228
Change-Id: I1ec834fea1112a9cfbd9cddd2198438793698502
Try to clean up the code paths coming in and out of binder IPCs to
plug any places where we could disrupt the gather flag of a thread,
causing it to keep gathering stack crawls (which is the thing that
is causing our strict mode data to become so large).
We now take care of saving and restoring this state in the core
IPC code path, not at the Java layer.
Change-Id: I73d564778da127bdce00f304225930e7f2318293
This is used by media service to schedule video frames at the
proper time, based on precise vsync timings.
Bug: 14659809
Change-Id: I1a90603f3dc09dca9aa4f90a3aa845fab56e0a5e
