Clean up ExceptionOccurred.

Use ExceptionCheck before ExceptionOccurred since ExceptionCheck
doesn't acquire any locks and is faster.

Change-Id: Ibd87fd1e33b339bd2a6effa1d20d3253c8a61bdc

Conflicts:
	core/jni/android_util_Binder.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 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] 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
[ActivityManager]: Update home process when home activity resumed

Symptom:
  When switch between two home activities, the home process might not be updated to the correct one. In that case, the home activity might be killed easily.

Root Cause:
  The home process is updated only when a home activity is newly created or being restarted. ActivityManager did not update the home process when simply resume a home activity.

Solution:
  Update home process when home activity resumed

Reproduce Steps:
  1. Install a launcher application, such as Apex Launcher
  2. Press home key to change to Apex Launcher by "Just once" option
  3. Press home key to switch back to original home activity by "Just once" option.
     (The home process is still the Apex Launcher's process because ActivityManager does not update the home process when resuming the original home activity.)

Change-Id: I046279ca7ba851a283ee67ea19202890f7b3f343
[ActivityManager] Prevent coredump file may not complete for testing.

Sympton:
During testing, skip kill native crash process manually because it will continue to die by default.

Root Cause:
Large process may take some time to do coredump.In auto test, crash process will be killed immediately that results incomplete coredump file.

Solution:
If the tester (IActivityController) will handle app crash event,
Do not kill native crashed process if the rom is debuggable.

Change-Id: Ia360af147d694125d440e5ba2f958c4759a50494
[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
ActivityManagerService: Penalise large apps going to background

Large applications (PSS more than a given threshold) when closed are
penalised with higher ADJ. Now, they will be more prone to be killed by
lowmemorykiller during memory pressure levels. This ensures better app
concurrency and improved subsequent latencies as it leaves some more room
for other smaller bg apps to be alive

Change-Id: I448fa12f55370949b22075595cd75b9c29e5d4b5
Optimize drawBitmapMesh using TRIANGLE_STRIP

Draw BitmapMesh using STRIP instead of TRIANGLES.
Depending on where the bottleneck is located in the pipeline,
there is a potential for saving two-thirds of the time spent rendering.
The speedup is due to avoiding redundant operations,
i.e., mapping each vertex four times to texture and color attribute,
sending each vertex twice to the GPU, vertex processing of GPU ...

In this patch:
1. Refactoring mesh using Strip.
2. Batch triangles by adding extra vertexs at the start and end of rows.
3. Optimize computing positions of texture and color attribute.

Benchmark: Drawing Bitmap(1152x768 px) with 200x200 meshes
Performance: ~46% improvements (from 26.4 fps to 38.7 fps)
Memory: Reduce 80800 vertices with xy, uv, rgba data.

Change-Id: I08c5c20d981d88528ce7b02012feefae468d6ec4
Signed-off-by: kui.zheng <kui.zheng@arm.com>
advanced reboot: add soft reboot option

Adds a "Soft reboot" option which restarts zygote, as requested in JIRA
CYAN-3998

Change-Id: Ia6e5ed9b053e1c5ebd1fc55e5692858b97f7e0fc
Signed-off-by: Roman Birg <roman@cyngn.com>

Conflicts:
	core/res/res/values/cm_arrays.xml
	core/res/res/values/cm_strings.xml
ShutdownThread: set soft reboot trigger accordingly

Change-Id: I72bd52aa1492d356e368e8c60897002c1f110172