Fix memory leak in PatchCache

Patch object should be deleted when removing its corresponding
cache entry from PatchCache.

Change-Id: I8dfd7f557f6e5c6e9a9c04ba915372790e6f34f5
Signed-off-by: Sangkyu Lee <sk82.lee@lge.com>
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
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
MtpDatabase JNI: Fixed incorrect method name in ALOGE.

Change-Id: I46688cf79f1e7554b28162df2347c4dcb571b8a9
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
Service: Keep services needing restart.

Services needing restart after crash include:
1) service with 'persistent == true'
2) service explicitly reuqired restart by returning START_STICKY
   or START_REDELIVER_INTENT from onStartCommand

Change-Id: Icda43d349faf344a8d022fc4ec5e928ec3399036

Conflicts:
	services/java/com/android/server/am/ActiveServices.java
A background started service is removed from mStartingBackground when timeout.
Fix is to make sure mStartingBackground is updated to remove one.

Change-Id: I0e42beb550d33e6e400349b85bbb89848e18d520
Move service from starting list once onStartCommand get called

Currently bg service will be marked as starting when it get started.
But it will be only get removed from the starting list when it get
binded. This caused the BOOT_COMPLETE intent delay more than 1min when
there are lot of service filter this intent.
Move service from the starting list if onStartCommand is completed.

Bug 1444146

Change-Id: I4b402cea9bf0fca51f76acc9aaf2163ad5125941
Tunning max allowed background services

The serialize running of background services feature
delay some services startup when system bootup, and
lead some abnormal behaivor at the early of system startup.
Tunning will be disabled after system complete bootup.

Change-Id: I834607d9156253bee13848586a8136e24760fdf4
Increase start timeout for wrapped process

 * apparently 300*1000 for valgrind is not enough
   (hammerhead aosp tot).

Change-Id: Ia3f26cb67d3aa0ebdec68f3c1a764bad5e7f4f95
[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
Optimize Blend composites.

Removed redundant array allocations to improve performance for various
blending modes.

Change-Id: Iaba1d6ff3ad03eebdc859c599b610cc593370438