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
By design, if the user presses the power key twice within 5 seconds
(panic), it will show immersive confirmation again at the next time
entering immersive mode.
But there is a bug on calculating the time between pressing the power
key. The time get from event.getDownTime() will stop when the device
is sleeping without being charged.
So here uses SystemClock.elapsedRealtime() instead.
https://code.google.com/p/android/issues/detail?id=80772
Change-Id: I4dca9dc260904f1c5b60464834781e2a82a9bcf4
If we return vis without clearing clearable flags, it will be set to
IStatusBarService in updateSystemUiVisibilityLw(), and then be
callbacked to WMS via statusBarVisibilityChanged(), and then be
dispatched to the client; which is wrong because WMS should dispatch
the new value to the client, not the old one.
https://code.google.com/p/android/issues/detail?id=79991
Change-Id: I2a06d1fbe66e854e639d86a39784f8c6a3303674
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: 70532bf
* commit '70532bf46433519a27ecada265b6de9364f51f39':
Wake up device in the case a touch is encountered in theater mode when the screen is off and no dream is running.
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
