[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
DO NOT MERGE - [ActivityManager] Ensure consistency behavior when a background activity brings another existed activity to front.

Symptom: ANR occurs on previous activity.
Root Cause:
In KK, when a background activity starts another existed background activity (bring to front),
if current focused stack is not the same as the stack of target starting activity,
it will still resume the top of target stack, even the top activity on the target stack may not the same as target activity.
And it will result incorrect focus, press back key will send to previous stack's top then popup ANR on previous activity:
"Reason: Waiting because no window has focus but there is a focused application".

By original code comment, it looks 'bring to front' should not happen in this issue case.
// If the target task is not in the front, then we need
// to bring it to the front...  except...  well, with
// SINGLE_TASK_LAUNCH it's not entirely clear.  We'd like
// to have the same behavior as if a new instance was
// being started, which means not bringing it to the front
// if the caller is not itself in the front.

If the caller and target are in the same stask, it will just deliver new intent without changing task order (the same behavior as JellyBean).
So the patch concept is just to avoid to use target stack to resume top when caller and target are in different stack.

Solution: Do not allow to resume another stack top if non-top activity try to bring existed activity to front.
It may not be a good solution, just a reminder for the issue case.

Reproduce steps:
Assume A, B, C are different app tasks.
When the application stack is like:
  Top C
      B
      A

 #Case 1: Home is foreground
  A starts B with NEW_TASK, C will resume, focus still stays at Home, and window order does not update.
  Then press back key or volumn key will result ANR on Home.

 #Case 2: App is foreground (Resumed activity is C)
  A starts Home, Home will resume, focus still stays at C, and window order does did not update.
  Then press back key or volumn key will result ANR on C.

Change-Id: If05070123b248e2335791e43a4d4ddee6db11d84
[ActivityManager] Move top task to top in window manager

Symptom:
In certain situations, application starts activity while
it is in background. When an existing background activity
starts a new activity which results to be kept in the same
background task, the new activity won't be resumed.
In that case, the background task (sourceTask) should not be
moved to top in window manager.

Solution:
Move top task of the target stack to top in window manager

Change-Id: Id7a37ea67ce1f80e0c2b5399865c51fd7113deb8
[ActivityManager] Do not finish root activity when reset task

Symptom:
The root activity not always located at index 0 of the task.
For example, the index 1 activity will become the new root
when the original root activity (at index 0) finished.
The new root activity might be finished unexpectedly before
the original root activity actually destroyed.

Solution:
Check frontOfTask to avoid finishing the root activity unexpectedly

Change-Id: I623ab97e9c95c83b3cfe7c9dfc151a291a391ea4