Be more conservative about initial keyguard state

Prevents a race condition that could lead to leaking the home screen
if Keyguard is too slow at pushing its state to the window manager while
booting.

Bug: 21128921
Change-Id: I992066c2c4e1bc4f797776c7804408a53b658b03

diff --git a/services/core/java/com/android/server/policy/keyguard/KeyguardStateMonitor.java b/services/core/java/com/android/server/policy/keyguard/KeyguardStateMonitor.java
index 01c110f..f1f9c50 100644 (file)
--- a/services/core/java/com/android/server/policy/keyguard/KeyguardStateMonitor.java
+++ b/services/core/java/com/android/server/policy/keyguard/KeyguardStateMonitor.java
@@ -36,10 +36,11 @@ public class KeyguardStateMonitor extends IKeyguardStateCallback.Stub {
     // Keyguard changes its state, it always triggers a layout in window manager. Because
     // IKeyguardStateCallback is synchronous and because these states are declared volatile, it's
     // guaranteed that window manager picks up the new state all the time in the layout caused by
-    // the state change of Keyguard.
-    private volatile boolean mIsShowing;
-    private volatile boolean mSimSecure;
-    private volatile boolean mInputRestricted;
+    // the state change of Keyguard. To be extra safe, assume most restrictive values until Keyguard
+    // tells us the actual value.
+    private volatile boolean mIsShowing = true;
+    private volatile boolean mSimSecure = true;
+    private volatile boolean mInputRestricted = true;
 
     private int mCurrentUserId;