Wait for buffers to drain

When a BufferQueue producer disconnects and reconnects, we retain
the previously-queued buffers but empty the slots.  This allows
the number of queued buffers to grow without limit.  The low-memory
killer does not approve.

Bug 11069934

Change-Id: Ia2eaa954c7a3904b54209a3701dba01689e204d8
GC triggering performance optimizations

Copy the correct starting heap size at process init.
Interfaces to set GC/managed heap parameters.

Change-Id: Ia2b158aa28254d88f68c9534a0eef580aa811b10
Merge tag 'android-4.4.1_r1' into kitkat

Android 4.4.1 Release 1
Use implementation-defined format when HWC writes to output buffer

When GLES isn't writing to the output buffer directly, request an
implementation-defined format with minimal usage flags, leaving the
format choice up to gralloc. On some hardware this allows HWC to do
format conversions during composition that would otherwise need to be
done (with worse power and/or performance) by the consumer.

Bug: 8316155
Change-Id: Iee6ee8404282036f9fd1833067cfe11dbadbf0bf
Add a boardconfig to force HWC composition of virtual displays

When this boardconfig is defined, even when all virtual display
composition is done by GLES, the HWC will be forced to copy from the
GLES framebuffer to the output buffer. On some hardware this allows
HWC to do format conversions that would otherwise have to be done by
the consumer, with worse power and/or performance.

Bug: 8316155
Change-Id: If980ecc589f138cef063eafa757f7f748196713e
Only consume touches up until the frame time

When resampling is disabled, it's currently possible to consume
touches after the current frame time. This breaks some guarantees and
could cause unexpected behaviors.

Change-Id: I99908a2cac2df9f795dd4a07188b4451213cf3e4
Fix handling of undefined TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS

related to b/8316155 - Implement HWComposer 1.3 w/ virtual display support
Change-Id: I2dc8d65a74174aa833cc491264f97f1f2df49307
Native counterpart of new power manager method

Cherrypicked from master.

b/9464621

Change-Id: I54c0ed50a57ac870da91db8589a73a2c792dbd8d
Bug fixes for SensorService

i) Emulate Flush for AOSP Fusion Sesnsors on newer HALs that support batching.
ii) Early return if there are no events for the current SensorEventConnection.

Bug: 11325707, 11376538

Change-Id: Idb856302463649a99d3d5d0c965bb06ba06b8e1d
EGL: rename CallStack::dump into CallStack::log

Bug: 11324229
Change-Id: Ibac1be182c336e7aa5ac098f08d18b3c188964b4
DispSync: remove delay when enabling vsync events

This change fixes a bug that caused an extra frame of latency when enabling
vsync event callbacks in DispSync.  The bug was related to the logic that
prevents the two events from firing with very little time between them due to
updates to the vsync model.

Bug: 11479720
Change-Id: Ie7eaff9e92ffb7b7b6cb4d3d4402c96cbd29af7e
Don't use implementation-defined format with CPU consumers

If the virtual display surface is being consumed by the CPU, it can't
be allowed with HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED since there is
no way for the CPU consumer to find out what format gralloc chose. So
for CPU-consumer surfaces, just use the BufferQueue's default format,
which can be set by the consumer.

A better but more invasive change would be to let the consumer require
a certain format (or set of formats?), and disallow the producer from
requesting a different format.

Bug: 11479817
Change-Id: I5b20ee6ac1146550e8799b806e14661d279670c0
Provide virtual display output buffer to HWC in prepare

We were already making sure the HWComposer class had the handle before
prepare, but it wasn't passing the handle along to HWC as intended.

Partial fix for bug: 11430248
Change-Id: I25f672c4fdfaa6a81fe0acb24d9ad05153ee17dc
Don't change the framebuffer target until we render a new one

Continuing to send the last-rendered framebuffer to HWC on subsequent
frames allows the HWC to read partially-composed regions that haven't
changed, instead of re-composing from scratch.

Bug: 11573910
Change-Id: I8829877d2a06001f1e1b3f168cbba71c7b217b2d
Add BoardConfig flag TARGET_USES_OPENGLES_FOR_SCREEN_CAPTURE

This flag forces usage flags:
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)

This is a better and safer approach than https://gerrit.omnirom.org/#/c/2670/.

Change-Id: I37437827434dbc3bec80956f1e199dbe8e3d255a
Revert "Add BoardConfig flag TARGET_USES_OPENGLES_FOR_SCREEN_CAPTURE"

So apparently this isn't needed. -_-
See: http://review.cyanogenmod.org/#/c/55376/

This reverts commit 05aff6836224f6a6cf648f2385535d1bf2a23fe7.

Change-Id: I119c476f403469a8102ac3207a6528e7efd697e3
Revert "remove support for glReadPixels screenshot path"

This reverts commit 3ca76f416bc8665a97636ca8a2d0128b9da9d92c.
Support forcing all screenshots into a CPU consumer

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
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
sf: work around for no EGL_RENDERABLE_TYPE support

Conflicts:
	services/surfaceflinger/SurfaceFlinger.cpp

Change-Id: I04de379c73fc349526527ded9ddd3dd07f1998a0