GFX-3D: Hold the BufferReference of GraphicBuffer in BpGraphicBufferAlloc

BZ: 86716

In WIDI usage, BufferQueue is outside of SurfaceFlinger. If BufferQueue
allocates a GraphicBuffer from SurfaceFlinger, BnGraphicBufferAlloc will
create a BufferReference to hold a last ref to the GraphicBuffer, but
when the transction finishes, the parcel used in the transaction will be
destroyed and the BufferReference will be freed which caused the last
ref of the GraphicBuffer in SurfaceFlinger side goes away and then
destroy the GraphicBuffer. This leads to the buffer state between
BufferQueue and SurfaceFlinger out of sync, because in BufferQueue side,
the GraphicBuffer was just created and will be used later.

This patch add a sp<IBinder> of BufferReference for each GraphicBuffer
when created in BpGraphicBufferAlloc, this will make the BufferReference
in BnGraphicBufferAlloc stay still when the transaction finishes, which
also leads the GraphicBuffer be held. When BufferQueue free a
GraphicBuffer, the sp<IBinder> BufferReference will be set to 0 which
will free BufferReference and then GraphicBuffer in
BnGraphicBufferAlloc/SurfaceFlinger side, and will not lead to memory
leak.

In normal use case, since the BufferQueue and SurfaceFlinger are in the
same process, there will no Bp side exist. Thus, this patch will not
affect the normal use case.

https://code.google.com/p/android/issues/detail?id=54597

Change-Id: I812bbf046fd592a6dca1e4d157b459c9654835fb
Signed-off-by: Lingyun Zhu <lingyun.zhu@intel.com>
Revert "GFX-3D: Hold the BufferReference of GraphicBuffer in BpGraphicBufferAlloc"

This reverts commit 7a3802e7699164eb7760f354803ab59afbf42eab.

Change-Id: Ie29d5404c23ca8610f5fa3e5916fe1a124956ba0
native: TRDS 3.0 and new theme engine preparation (4/4)

For the one who do not know this feature see as reference
the first two versions here:

https://github.com/SlimRoms/frameworks_base/commit/b330fde28306286572ba390e451a72539c0c3576

https://github.com/SlimRoms/frameworks_base/commit/3194015737b7944b4185fca007b8d167a0675cd8

we got now over a year now a lot experience how to handle the qualifier fallback
as well how to theme it and how to handle other apps. Based on this knowledge we
redid some parts of TRDS engine with following new features/additions and fixes
to have now a final perfect working TRDS

- compared to the old versions where it was needed on some apps to restart them
  in background this is not needed any more. All is handled about the internal
  AOSP resource handling and on qualifier change the caches are cleared
  and the apps get an onconfigurationchanged to restart the activity
  like it is doing on orientation change eg
- inverted folder is now depreciated and the new folders are holodark
  and hololight which allows on the one hand a dark theme (at least
  how TRDS started) and a light based theme hololight
- This name change is mainly because of the new theme engine which
  will come which uses this as base to add 2 external themes at the same
  time and give the user the ability to switch between them. But this is
  still in early stages and this commit is just the preparation for it
- Two new automodes are now integrated. User can enable the twilight modus
  which enables/disables holodark/hololight depending on the daytime...means
  on the evening it switches to holodark on normal day it is hololight.
  The other automode is based on light conditions....means that if it is
  dark outside it switches to holodark....if we have bright light conditions
  it switches immediatelly to hololight. Due of the resource cache handling now
  this happens immediatelly for the user and feels completly system integrated
  and happens without delay. A bit comparable to some navigation tool for cars
  which can switch automatically from dark to light and back
- currently the auto modes as well the manual mode switches between holodark
  and hololight. Due that we do not have currently anything hololight themed
  in the source hololight = stock theme. We will give the user the ability
  later when done to choose between which modes the user want to switch
  (stock/holodark/hololight). But this does not make sense at the moment.
  As soon as we have done the light theme or theme engine (lets see what
  comes first) we will open the ability to choose it. This is only a small code change
- a lot small tweaks and fixes went as well into the new version

Whatever this commit as usual adds the support for it. The themeing is done in the
other commits by kroz which is as well way more extended then on the older versions

cheers
Change-Id: Ibc5aaec5661455477815043440fae86052a395ce