This reverts commit 1991590ddd0ca6d3a0cac290b65120c147034dbc
and fixes a bug where we were showing the scrim on devices without keyguard.
Bug: 18468369
Change-Id: Idce1370dadacd09c4a8f1a7fd9728c23b218d19c
This attempts to fix a bug where the device sometimes shows the home screen
before keyguard starts. The fix ensures we show the scrim when KeyguardServiceDelegate
is created and stays there until KeyguardService connects.
Fixes bug 18468369
Change-Id: Ib560889663c0c4dd84135d949fefc2b9819ce9a1
When FLAG_SHOW_WHEN_LOCKED was set over an unsecure lockscreen the
behavior was incorrect. In such cases the lockscreen was not being
dismissed with or without FLAG_DISMISS_KEYGUARD. This change causes
the lockscreen to be dismissed when FLAG_SHOW_WHEN_LOCKED is set
over an insecure logckscreen.
Fixes bug 18563298.
Change-Id: Iba0d096a59789bf41332e109f1bd3e70834bbb83
Windows that had FLAG_SHOW_WHEN_LOCKED and FLAG_DISMISS_KEYGUARD set
would ignore the FLAG_DISMISS_KEYGUARD if the lockscreen was
insecure. This change adds a test for insecure keyguards when the
two flags are set together.
Fixes bug 18563298.
Change-Id: I3027c7ec476d3ac15978f7e6a78b3c2050cbab02
Add a state callback so lockscreen reports back whenever its state
relevant for PhoneWindowManager changed, instead of synchronously
calling into SysUI which can lead to deadlocks. Directly use
LockPatternUtils for isSecure, and optimize the number of calls to
this method to optimize layout performance.
Bug: 17677097
Change-Id: I5d491fc8884d4f84d9562626b9ea0d5eaa5166fc
adding the following two system properties to control remote
display rotation and device orientation lock:
"persist.demo.rotationlock"=true|false
"persist.demo.remoterotation"=landscape|portrait
Bug: 18317603
Change-Id: Id5fe115f895c6a0e72563036b9a98ff3b5037763
Wake-up when entering brightness boost mode, don't boost in ambient
mode since some display device drivers do strange things in that mode and
boost doesn't work. Waking up feels more natural as well.
Don't flutter the power HAL's interactive mode bit simply due to changes
in display ready state since that may result in visible artifacts
such as display flashes.
Don't stop the auto-brightness sensor while temporarily boosted.
Don't prevent the display from entering the ready state while in brightness
boost since that would unnecessarily delay the transition from DOZING to AWAKE
until boost is finished.
Restart the user activity timeout when brightness boost ends and prevent
the display from dimming while boosted.
The pixel fairies basked in the sunlight.
Bug: 18262044
Bug: 18261782
Change-Id: I8c42a1e6091b0fe1253e90265ac248087ebc24e1
We allow TYPE_INPUT_METHOD windows to show on the lock screen.
These windows can attached other types of windows (For this
case the Swype KB was attaching a PopupWinow which will be
of TYPE_APPLICATION). This causes the popup window app token
to be added to the list of apps to be hidden on the lock
screen, thereby preventing the lock screen from been hidden,
which then causes a layout cycle(s). Now, we remove app
tokens for non-app windows from the hidden list in case it
was added by any attached widow they migth have.
Also, when we are updating window animations, set the
hideWhenLocked flag for windows that are IME tragets so
they don't go through unneeded cycles of having their
visibility policy set to hide/show/hide/show/...
Bug: 18021493
Change-Id: I3680256d41793f62def42fda00e26db1dcc990cc
automerge: 68f9773
* commit '68f97736e65f1be4664fd3c3765fc621f3b76c3a':
Wake up device in the case a touch is encountered in theater mode when the screen is off and no dream is running.
Windows with FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS were
getting an incorrect content inset hint, because the
hinting didn't see the adjusted systemUiVisibility.
Also adds hinting for the stable insets.
Bug: 17508238
Change-Id: If9647277feb6811b15665b801accd896c51dbd12
The entering animations were only applied to the incoming windows
one time. If those windows weren't drawn yet then they never had
an animation assigned.
Furthermore if a starting window was drawn in time it would get the
animation but its main window would not get it if it weren't drawn.
Even if an animation were assigned later they wouldn't be synced
with each other.
This change creates a single animation which is shared by all
incoming windows. As windows are drawn they can then animate with
the starting window.
(Also refactorings to eliminate redundant code and unnecessary
variables.)
Fixes bug 15991916.
Change-Id: I844d102439b6eda8c912108431916e04b12f7298
The entering animations were only applied to the incoming windows
one time. If those windows weren't drawn yet then they never had
an animation assigned.
Furthermore if a starting window was drawn in time it would get the
animation but its main window would not get it if it weren't drawn.
Even if an animation were assigned later they wouldn't be synced
with each other.
This change creates a single animation which is shared by all
incoming windows. As windows are drawn they can then animate with
the starting window.
(Also refactorings to eliminate redundant code and unnecessary
variables.)
Fixes bug 15991916.
Change-Id: I9949ef0a1639c831754316da34de97cb86403f5a
automerge: abf33e4
* commit 'abf33e48baff1ffc14562a499ec3eabc09a5dbb5':
[Theater Mode] Add framework support for screen double tapping out of theater mode.
Added support for brightness boost or setting theater
mode from the power key. This behavior is disabled by default and
must be enabled for specific products in a config.xml overlay.
Because the power key is already so overloaded, refactored the
code to split out handling of the similar ENDCALL button and
renamed all of the state that has to do with screenshot chord
detection to avoid confusion.
Bug: 17949215
Change-Id: Id282133188e3781472aabb64fabcee7b98d0c77d
Starting windows are displayed prior to their app windows visibility
being set. Consequently the WindowToken.hidden boolean for starting
windows is still true even when it is shown. The keyguard logic uses
the method WindowState.isVisibleNow to determine whether to animate
each window. This method incorrectly determined that starting windows
were not visible based on WindowToken.hidden and consequently didn't
animate in the starting window.
This change fixes isVisibleNow() to correctly determine when
starting windows are visible and animates them in as part of the
keyguard transition.
This change also adds keyguard debug.
Partially fixes bug 15991916.
Change-Id: Iac3e5f3f33876be5801ec619bbe7a1579e648322
These are available as XML attributes but were lacking setters. None
of the Window properties have getters, so just adding setters here.
BUG: 16847753
Change-Id: I9c032903e94b7f12125210bd73c911243612df69
Tracks which window caused the disable flags
instead of just blaming PhoneWindowManager.
Bug: 17830264
Change-Id: If6c957120bb2ee8e0083f80e35c71eb21b8672b6
