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
--- 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 @@
// 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;