BatteryService: fix FC on boot until battery stat is present

updateLightsLocked() can be called from CM's added SettingsObserver
when battery stat is not present, causing an FC and a loop until
battery stat is present.

I/SystemServer(  502): Battery Service
E/System  (  502): ******************************************
E/System  (  502): ************ Failure starting core service
E/System  (  502): java.lang.NullPointerException
E/System  (  502): 	at com.android.server.BatteryService$Led.updateLightsLocked(BatteryService.java:735)
E/System  (  502): 	at com.android.server.BatteryService.updateLedPulse(BatteryService.java:709)
E/System  (  502): 	at com.android.server.BatteryService.access$1600(BatteryService.java:86)
E/System  (  502): 	at com.android.server.BatteryService$SettingsObserver.update(BatteryService.java:860)
E/System  (  502): 	at com.android.server.BatteryService$SettingsObserver.observe(BatteryService.java:822)
E/System  (  502): 	at com.android.server.BatteryService.<init>(BatteryService.java:187)
E/System  (  502): 	at com.android.server.ServerThread.initAndLoop(SystemServer.java:328)
E/System  (  502): 	at com.android.server.SystemServer.main(SystemServer.java:1309)
E/System  (  502): 	at java.lang.reflect.Method.invokeNative(Native Method)
E/System  (  502): 	at java.lang.reflect.Method.invoke(Method.java:515)
E/System  (  502): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:781)
E/System  (  502): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
E/System  (  502): 	at dalvik.system.NativeStart.main(Native Method)

Change-Id: Ic4438fe50e98f1aa05ae1d0d26240bf9410fd92f
[1/2] Frameworks: Wakelock Blocker

Change-Id: Id4fd1d8da6ed40517094a5a156f7c6fea622e985

Conflicts:
	services/java/com/android/server/power/PowerManagerService.java

Conflicts:
	core/java/android/os/IPowerManager.aidl
	core/java/android/provider/Settings.java
	services/java/com/android/server/power/PowerManagerService.java

Conflicts:
	services/java/com/android/server/power/PowerManagerService.java
[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