Fix a race bug in clearGarbage of PatchCache

In clearGarbage of PatchCache, the garbage patch was returned back
to mFreeBlocks, and then removed from the cache. Since this function
is called from another thread other than the rendering thread. There
is a possibility that the cache was hit and reused by rendering
thread after it was returned to mFreeBlocks but before removing from
cache. As a result, the rendering thread gets wrong VB, UI corruption
is observed. To fix it, remove it from cache before return it back
to mFreeBlocks.

Change-Id: Idef4af737648f5d7128ac52088707357025089eb

Conflicts:
	libs/hwui/PatchCache.cpp
Fix a resource race bug in PathCache

When enabled defer rendering, it will do precache for DrawPathOp.
The paint used for creating PathTask in precache just get the address
of mFilteredPaint of OpenGLRenderer. So for the following defer
operation like DrawTextOp has possibility change the mFilteredPaint
by getPaint while another WorkerThread in PathCache is using the paint
which pointed to the same address of mFilteredPaint to generate bitmap.
As a result, it will generate a wrong bitmap for generateTexture in
PathCache. To fix it, do a copy of paint when creating PathTask.

CRs-Fixed: 664244

Change-Id: I5516f5b143458b88d3573d15b7ebb34f688800c7
MtpDatabase JNI: Fixed a memory-leak in getObjectPropertyValue().

The jstring "stringValue" was not never freed.
In the case where "str" was NULL the whole cleanup part (see "goto out")
was even skipped.
This patch makes getObjectPropertyValue() behave like
getObjectPropertyList().

Change-Id: I5a7ec3611036f5253a054b00064999bcd1d1c29e
Remove some pointless code.

Unnecessary disk reads for values that are never
used (and cached elsewhere, so that optimization is
rendered pointless).

Change-Id: Ic14a8b53a96908bb03eae28759d7be2c217e8125
hwui: fix possible null pointer de-refrence

add layer check for  null before de-refrencing it.

issue link: http://code.google.com/p/android/issues/detail?id=61622

Change-Id: I54fc21ec594effcfb1eededd80dd5b0b52645c4c
Fix the texture ID reuse issue in HWUI.

Issue: When the layer of previous frame is destroyed, it doesn't clear the
texture id in mBoundTextures[mTextureUnit], so in the next frame, if
glGenTexture returns same texture ID of the previous frame,
the new texture is not bound.

CRs-fixed: 671736

Change-Id: Ifc5fd2115fb1863b3c006ab14b0faabeaeb4eab4
[Asset Manager] Fix memory leakage bug

Symptom: memory leakage
Root Cause: new SortedVector but not free it in native cpp
Solution: free the SortedVector
Project: AOSP
Note:

Change-Id: Iab5a7f2e8d8509631301e7231427927d4797c856
Fixing parcel leaks to avoid virtual memory leak

Client has to call recycle() on parcel object after its usage
otherwise native layer of binder won't clear the resources of
parcel which were allocated for IPC

Change-Id: Ib31ddcc92aa4ebd80bb66729922b9133692e9c9e
Fixed VM memory leak in AudioSystem JNI interface

The function android_media_AudioSystem_error_callback from AudioSystem
JNI interface is using FindClass function but does not delete the
reference created by VM in this function.
By doing this call, VM will add a local reference in IndirectRefTable
and it's the caller's job to delete this reference.
By not doing this, everytime this callback is called, a new reference is
added and never deleted.
The effect is crashing the VM running system_server:

E/dalvikvm( 3071): JNI ERROR (app bug): local reference table overflow (max=512)
W/dalvikvm( 3071): JNI local reference table (0x732da288) dump:
W/dalvikvm( 3071):   Last 10 entries (of 512):
W/dalvikvm( 3071):       511: 0x42a90008 java.lang.Class<android.os.Parcel>
W/dalvikvm( 3071):       510: 0x4381fd90 android.view.KeyEvent
W/dalvikvm( 3071):       509: 0x439b9808 android.view.KeyEvent
W/dalvikvm( 3071):       508: 0x42d2fe18 java.lang.Class<com.android.server.input.InputManagerService>
W/dalvikvm( 3071):       507: 0x42ad4298 java.lang.Class<android.media.AudioSystem>
W/dalvikvm( 3071):       506: 0x42ad4298 java.lang.Class<android.media.AudioSystem>
W/dalvikvm( 3071):       505: 0x42ad4298 java.lang.Class<android.media.AudioSystem>
W/dalvikvm( 3071):       504: 0x42ad4298 java.lang.Class<android.media.AudioSystem>
W/dalvikvm( 3071):       503: 0x42ad4298 java.lang.Class<android.media.AudioSystem>
W/dalvikvm( 3071):       502: 0x42ad4298 java.lang.Class<android.media.AudioSystem>
W/dalvikvm( 3071):   Summary:
W/dalvikvm( 3071):       510 of java.lang.Class (3 unique instances)
W/dalvikvm( 3071):         2 of android.view.KeyEvent (2 unique instances)
E/dalvikvm( 3071): Failed adding to JNI local ref table (has 512 entries)
...
E/dalvikvm( 3071): VM aborting

In this case, PID 3071 is system server.

Change-Id: I0c113eb72256984854d59a3ccef11a8d23f96e79
Signed-off-by: Robert Chiras <robert.chiras@intel.com>
frameworks/base: Fix SystemUI crash on Recent Apps list

Issue: SystemUI crash is observed when Context MenuItem "App info"
       is selected on the recent apps activity
       1. Open the rencet apps list
       2. Long press on any one/more recent app(s)
       3. Lock the screen using power key
       4. Unlock the screen using power key
       5. select menu item "App info"
       6. SystemUI process will get crashed.

Fix: Changed the code to make sure that only one context
     menu is active at a time and also dismissed the
     context menu on pause of the RecentsActivity

Change-Id: Ia50bed7bfad6fde7beeaec37fa6402177eee1d40

Conflicts:
	packages/SystemUI/src/com/android/systemui/recent/RecentsPanelView.java

Conflicts:
	packages/SystemUI/src/com/android/systemui/recent/RecentsPanelView.java
Fixing NullPointerException in TextView

Adding null pointer protection for layout that fixes some force closures.
Signed-off-by: Dmitry Tsyganyuk <fdt017@motorola.com>

Change-Id: Ia9039912aafa76090da9016a0fb3ee4d6774caef
Memory leak in parsePackage

The method parsePackage failes to delete some resources
in case of failures.

Added delete of "package" in the cases that was previously
missed.

Change-Id: I183e9ec5864c5ed18bb48410ab41317cb3d96bda

Conflicts:
	libs/androidfw/ResourceTypes.cpp
[ActivityManager] Ensure alive process is not killedByAm.

Symptom: Unable to kill by Am again and will be skipped updating its oom adj.

Root Cause:
A restarted process will reuse original process record.
The flag killedByAm will keep previous state.

Solution:
Reset the flag killedByAm to false when the process is started.

Note: Found another similiar patch If95137d91939cc44882ad2813131bcde0edd0c1b

Change-Id: I59a86648ca8d0aed4c489d92751af120aae5ef90
[ActivityManager] Prevent kill a restarted process again.

Root Cause:
Use removeTask with flag ActivityManager.REMOVE_TASK_KILL_PROCESS will set waitingToKill = "remove task"
to the target process when its setSchedGroup is not BG_NONINTERACTIVE.
Later the target process may be killed when applying oom-adj due to setSchedGroup has changed to BG_NONINTERACTIVE.
If the process is needed to restart, the process record will be resued.
Then the restarted process may be killed again because its waitingToKill is not null.

Solution:
Clean waitingToKill when process is dead.

Change-Id: I5ffb5388127f4221da4c700d3f1c224f7ca6e7b2
[ActivityManager] Avoid keeping restarting home when only home activity exists.

Root Cause:
When there is only home activity existed,
updating home apk will call forceStopPackageLocked to finish the activity.
Then activity history becomes empty, then home will be launched,
but its package is still target to close that results a loop.

Solution:
If home activity has been force-stopped, do not stop the same home activity again.

Change-Id: Icff12028d407873c2e6f50a06bcad231b908ccbd
[ActivityManager] Prevent provider creating twice.

Root Cause:
If a process which contains provider is starting by not from accessing provider, e.g. service/activity/receiver,
its providers' will be created during handleBindApplication,
and before the process complete publish provider to ActivityManagerService,
if there is an access to its provider, these providers will be created again (there will have 2nd onCreate).

Solution:
Check if provider record is existed, do not schedule install provider,
becuase it is already creating and will be published later.

Change-Id: Ic200ceae042c014c86e7edee0acd013b513af334
[ActivityManager] Prevent potential deadlock from system error dialog and InputMethodManager.

Sympton:
When application crash in a special timing and system server's InputMethodManager is binding, deadlock may occur.

Root Cause:
Thread(1): When using InputMethodManager in system server, it will lock mH(handler) of InputMethodManager,
and sometimes it will call to InputMethodManagerService::showCurrentInputLocked and will call bindService at some condition,
then it will also lock ActivityManagerService.
Thread(2): When an application crashed, it will lock ActivityManager when showing crash dialog, inside the dialog,
it will call setEnabled of Button and lock mH of InputMethodManager.setEnable of TextView will lock IMM's handler.
So the deadlock happened as the flow: (2) lock AMS -> (1)lock mH -> (2)wait mH -> (1) wait AMS

Solution:
Reduce nested lock of error dialog: post message to let (2) lock mH after release AMS lock.

Change-Id: Id85c29406236db3b5fca9655fde1fcaf0afd1337
[ActivityManager] Avoid mistaking visibility by finishing task.

Sympton:
Next activity only adds to history but does not launch/resume then results ANR.

Root Cause:
In a rare timing, some windows are switched at the same time,
it will cause some finishing records on the top temporarily,
then set startIt to false that skip to resume the real top activty.

Solution:
If all activities in a task are finishing, do not use it to check.
The behavior/checking is the same concept as in JellyBean:
            // If starting in an existing task, find where that is...
            boolean startIt = true;
            for (int i = NH-1; i >= 0; i--) {
                ActivityRecord p = mHistory.get(i);
                if (p.finishing) { // <--
                    continue;
                }

Change-Id: I9d81a7b5182400c52e173da23eee61c74692beee
Fix a potential deadlock in ProcessStatsService.

The potential deadlock:
ThreadA (backtrace),
  at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java)
  at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java)
  at com.android.server.am.ProcessStatsService.performWriteState(ProcessStatsService.java)
     --- try to lock mWriteLock.
  at com.android.server.am.ProcessStatsService.writeStateLocked(ProcessStatsService.java)
  at com.android.server.am.ProcessStatsService.writeStateLocked(ProcessStatsService.java)
  at com.android.server.am.ProcessStatsService.writeStateSyncLocked(ProcessStatsService.java)
  at com.android.server.am.ProcessStatsService.shutdownLocked(ProcessStatsService.java)
  at com.android.server.am.ActivityManagerService.shutdown(ActivityManagerService.java)
     --- lock AMS

ThreadB (backtrace),
  at com.android.server.am.ProcessStatsService.getStatsOverTime(ProcessStatsService.java),
     --- lock mWriteLock and then try to lock AMS.
  at com.android.server.am.ProcessStatsService.dumpAggregatedStats(ProcessStatsService.java)
  at com.android.server.am.ProcessStatsService.dumpInner(ProcessStatsService.java)
  at com.android.server.am.ProcessStatsService.dump(ProcessStatsService.java)

Change-Id: I437a5cedceb34292a6bd1d9e7610f52b1478e424
Signed-off-by: hanpengx <pengfeix.han@intel.com>
Add BlendComposite.java

The class is adapted from a demo tool for Blending Modes written by
Romain Guy (romainguy@android.com). The tool is available at
http://www.curious-creature.org/2006/09/20/new-blendings-modes-for-java2d/

Change-Id: I8f7c7ca08d3078106056764a4e2f1ce95d990137