Solve three memory leaks related to PatchCache

A Patch can be fairly large, holding bitmap data, but
is also frequently leaked which adds to the severity.
The feature is used in many important processes such
as Home, SystemUI and Chrome.

The following leaks are solved:

1. The Patch itself was not always freed.
PatchCache::removeDeferred() can mark patches to be
cared for by PatchCache::clearGarbage(). But
mCache.remove() would only destroy the container
and the pointer, not the Patch object itself.

2. The vertices stored in the Patch at Patch::createMesh()
would always leak. The empty/default destructor in Patch
would not properly destroy "vertices" since it's just a
pointer.

3. A BufferBlock that's added to the mFreeBlocks
in PatchCache could leak. The leak happened when a
patch later needed the entire free block, because the
object was removed from the list but never deleted
in PatchCache::setupMesh().

Change-Id: I41e60824479230b67426fc546d3dbff294c8891f
Do not show Home behind full screen activity

When ensureActivitiesVisibleLocked goes through foreground activity
stack and reaches non-fullscreen activity, it sets showHomeBehindStack
variable to true.

If there is a fullscreen activity behind, showHomeBehindStack remains
unchanged, which causes Home application to be displayed anyway.
In this case user will see a fullscreen activity and Home activity
simultaneously.

To fix the issue we set showHomeBehindStack to false when we reach
fullscreen activity in the activity stack.

This was made visible by the following commit:
446ef1de8d373c1b017df8d19ebf9a47811fb402

Change-Id: I535c1283a4e26f5cf606375b837d4b7195324af0
Prevent Lockscreen album art from activating FLAG_KEEP_SCREEN_ON

This is a small fix to the showWallpaper method, in which a power
consumption problem has been introduced. This showWallpaper method
toggles the window flag FLAG_SHOW_WALLPAPER, when album art is being
shown in Lockscreen. It is important to set pixel format to
PixelFormat.OPAQUE if flag FLAG_SHOW_WALLPAPER is not being set.

If not, an application that uses window flag FLAG_KEEP_SCREEN_ON
will prevent the keyguard from going to sleep and drain battery.

Change-Id: I1808be28047977ae5ac4dd1168ea25cac8a55a78
Fix problem where PhoneWindowManager waits for keyguard to draw

This fixes a problem where PhoneWindowManager times out waiting
for keyguard to draw when it's disabled.  Instead, we pass a null
token back which allows PhoneWindowManager to continue.

Fixes bug 11190932

Change-Id: I041ea1d88dca681476d9477a3aab54559976b312
Volumes in Settings/Sound is slow to start

There is a delay after pressing volume menu item
there is a delay until the Volume popup is shown.

The reason for this is that the initialization of
the different seekbars is slow and run in the main
thread. More specifically the call to get the
ringtone from the RingtoneManager is causing this
delay.

Moving the call to the ringtone manager to the
handler thread used to play ringtones to make
the launch of the volume dialog a bit snappier.

Change-Id: I76da0226592468debd542d67164b37b2b59897c7
GC: Improve the string parsing for GC parameter setting

Improve the string parsing for GC parameter system property.
Previously we only recoganize plain number for dalvik.vm.heapminfree
and dalvik.vm.heapconcurrentstart, while users tend to use format as
2m.  Improve the string parse to cover such cases.

Change-Id: Iaf0152bc4d77e1caabc307a9a7b0e5b261f8e441
Change SQL to improve performance.

To know the number of images, use "COUNT(*)" instead of "_id" in SQL.
Using "_id" gets all result set. and when getCount() is called, CursorWindow is filled.
But using "COUNT(*)" gets just 1by1 data.
So using "COUNT(*)" is more faster than now.
And this SQL is called everytime per a file during a file transfer in MTP
The better way is by using "EXIST".
But if using "EXIST", modify MediaProvider.call() method.
So i applied just a "COUNT(*)"

Change-Id: Ic5882af0fad2304f836b7b7043a4746359391609
Signed-off-by: muzbit.kim <muzbit.kim@lge.com>