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>
It helps to catch the right exception.

Bug: 7238149
Change-Id: I7b60ec44d1d1d5ece8a871cb089f811b611f4a4a
LockPatternUtils: isSecure: respect profile settings

When the lock screen is set to secure and overridden to insecure
by profile settings, isSecure() would return true causing confusion
to some code.

For example, attempting to use a lockscreen shortcut
to launch an activity will cause the device to soft-reboot due to
recursive calling and a stack overflow.

Change-Id: I02984671c2a047765f4da1f6a44bb19dea5bf2d3
Profile: respect DPM when overriding screen lock (1/2)

Profile currently allows the user to override the keyguard set by
device policy, which is undesired.

Change-Id: Id8d80cfdad51ca0a64dc231a77e53b104ecb9825
Fix race condition in backlight adjustment.

When configuring the automatic backlight levels, there's a race
condition in setting the lux and brightness settings as the settings
provider doesn't allow storing multiple settings atomically. When
deleting rows, there's quite a high chance of DisplayPowerController
picking up a state where the lux values already have the lower number of
rows, but the brightness values do not, effectively leading to an
ArrayIndexOutOfBoundsException.

Fix that by
- waiting a second of cool-down time until applying the settings and
- adding a sanity check for the very unlikely case that the delay
  between writing both values is > 1 second

Change-Id: I44e41530fc5334aaefc4ab7d3a90542f78fabe0c
JIRA:CYAN-755