Fix Watchdog HeartbeatHandler to run on correct thread

The HeartbeatHandler for the System Server Watchdog has been running
on the wrong thread due to a race condition in initialization.  It's
designed to run on ServerThread, so that it can catch lockups in the
main looper of the System Server.  It has been running on
ActivityManagerThread instead, so it does not detect lockups on the
ServerThread as it should.

ActivityManagerService is calling Watchdog.getInstance() before
ServerThread calls Watchdog.getInstance().init(), so the handler is
being bound to the ActivityManagerThread instead of the ServerThread.

Explicitly bind HeartbeatHandler to ServerThread, so that the Watchdog
catches lockups on this critical thread.

Change-Id: Iccb184ac3adb817feb86ed4ee0e50e443bf74636
"[+>" more icon was never shown in PhoneStatusBar

"[+>" more icon was never show in status bar because
the member variable for this icon was not initialized
from resources. This fix enables "[+>" icon to appear
in status bar when the number of indications in status
bar becomes large.

Bug: 8368569
Change-Id: Ieb3412eed831052d69c0cf63c9b4230c38171e4a
Audio continue to played even if paused manually

Currently, audio will resume playing after a phone call
or notification even if the user had manually paused playback.

This patch addresses that by introducing a new player state
to distinguish the user pausing playback and the browser
losing audio focus for some other reason. Audio will only
 resume if the browser temporarily lost audio focus and
not when the user has manually paused playback.

Change-Id: I9e8beaedb0fcc5afe920068297ed9c387eab2ac8
Signed-off-by: Roger Chen <cxr514033970@gmail.com>
VpnDialogs: filter obscured touches

Change-Id: Ifcc919c36006c88e36363f5160f9334df0cf7e5b
Fix starting window memory leak

If starting window is added to arrays like mViews in
WindowManagerImpl.java, but not accepted by WindowManagerService,
we leak starting windows. To avoid leaking, remove the view
from WindowManager.

Change-Id: I4d98b883e9dfaf5e71bdece385643ba1b59b2633
Fix potential deadlock between LockScreen and WindowManagerService

If LockScreen is enhanced using SurfaceView/GLSurfaceView,
deadlock problem between LockScreen and WindowManagerService
can occur because of IWindow.resized() callback.
And it must lead to watchdog and reset.

IWindow.resized() callback is one-way function so calling resized()
callback of a remote IWindow object is never blocked.
However, calling resized() callback of a local IWindow object
(LockScreen is running on the same system_server process)
is always blocked until resized() callback returns.
Because resized() callback of SurfaceView/GLSurfaceView can lead to
WindowManagerService.relayoutWindow() call, deadlock can occur
between relayoutWindow() and performLayoutAndPlaceSurfacesLockedInner().
(Both functions need locking mWindowMap)

So this patch simulate one-way call when calling resized() callback
of a local IWindow object.

Change-Id: I2a6a5c74ed22d8e6b7a3bea3424ff2879d227105
Signed-off-by: Sangkyu Lee <sk82.lee@lge.com>