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
An accessibility service may register to observe the interactive windows
on the primary display. These windows are the one that has input focus and
ones a sighted user can touch. It is sometimes beneficial for an
accessibility service to overlay a window to intercept user interaction
and based on that introspect and perform an action on the windows that
are on the screen. This is problematic as overlaying a full screen window
that is touchable prevents the accessibility service to introspect the
content under this window.
This change adds a special type of window that only an accessibility service
can place which does not affect what an accessibility service can "see" on
the screen. Hence, even putting such a window full screen the service will
be able to interact with the other interactive windows it covers.
Change-Id: I053ccc3a5c6360a98dc40bdb172b54dab35d8b31
The Lollipop release introduced a feature that allowed
apps to extend under the navigation bar. This also means
any popup window that is anchored to the bottom of its
parent window will overlap with the navigation bar if the
parent window is extending underneath the navigation bar.
This change introduces a new window flag
(FLAG_LAYOUT_ATTACHED_IN_DECOR) that allows the app to
specify if the popup window should be attached to the decor
frame of the parent window thereby avoiding an overlap
with the screen decorations.
By default the flag is set on SDK version LOLLIPOP_MR1 or
greater and cleared on lesser SDK versions.
Also, replaced flags FLAG_NEEDS_MENU_KEY and
PRIVATE_FLAG_NEEDS_MENU_KEY_SET with needsMenuKey state
variable to make room for the new
FLAG_LAYOUT_ATTACHED_IN_DECOR flag.
Bug: 17789629
Change-Id: I2150e0c6ac688c966c0e8f7e54d42fd20285bea6
Sometimes it can take a long time to turn the screen on. That's not
good but what's worse is that the user will often get impatient
and press the power button again which effectively cancels the
process and makes the screen not come on at all. The user may
then conclude that the device ignored the power key press.
This change suppresses power key presses while we're already in the
process of turning the screen on so that at least the screen comes
on eventually, even if it's slower than we would like.
Bug: 17753363
Change-Id: I23083873e35a3dcfa5c20b6f870f53c18e465582
The motivation is an API change: FloatMath is going to be
deprecated and/or removed. Performance is not the goal of
this change.
That said...
Math is faster than FloatMath with AOT compilation.
While making the change, occurances of:
{Float}Math.sqrt(x * x + y * y) and
{Float}Math.sqrt({Float}Math.pow(x, 2) + {Float}Math.pow(y, 2))
have been replaced with:
{(float)} Math.hypot(x, y)
Right now there is no runtime intrinsic for hypot so is not faster
in all cases for AOT compilation:
Math.sqrt(x * x + y * y) is faster than Math.hypot(x, y) with
AOT, but all other combinations of FloatMath, use of pow() etc.
are slower than hypot().
hypot() has the advantage of being self documenting and
could be optimized in future. None of the behavior differences
around NaN and rounding appear to be important for the cases
looked at: they all assume results and arguments are in range
and usually the results are cast to float.
Different implementations measured on hammerhead / L:
AOT compiled:
[FloatMath.hypot(x, y)]
benchmark=Hypot_FloatMathHypot} 633.85 ns; σ=0.32 ns @ 3 trials
[FloatMath.sqrt(x*x + y*y)]
benchmark=Hypot_FloatMathSqrtMult} 684.17 ns; σ=4.83 ns @ 3 trials
[FloatMath.sqrt(FloatMath.pow(x, 2) + FloatMath.pow(y, 2))]
benchmark=Hypot_FloatMathSqrtPow} 1270.65 ns; σ=12.20 ns @ 6 trials
[(float) Math.hypot(x, y)]
benchmark=Hypot_MathHypot} 96.80 ns; σ=0.05 ns @ 3 trials
[(float) Math.sqrt(x*x + y*y)]
benchmark=Hypot_MathSqrtMult} 23.97 ns; σ=0.01 ns @ 3 trials
[(float) Math.sqrt(Math.pow(x, 2) + Math.pow(y, 2))]
benchmark=Hypot_MathSqrtPow} 156.19 ns; σ=0.12 ns @ 3 trials
Interpreter:
benchmark=Hypot_FloatMathHypot} 1180.54 ns; σ=5.13 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtMult} 1121.05 ns; σ=3.80 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtPow} 3327.14 ns; σ=7.33 ns @ 3 trials
benchmark=Hypot_MathHypot} 856.57 ns; σ=1.41 ns @ 3 trials
benchmark=Hypot_MathSqrtMult} 1028.92 ns; σ=9.11 ns @ 3 trials
benchmark=Hypot_MathSqrtPow} 2539.47 ns; σ=24.44 ns @ 3 trials
Bug: https://code.google.com/p/android/issues/detail?id=36199
Change-Id: I06c91f682095e627cb547d60d936ef87941be692
When the status guard is not available, (e.g. when the window is not
drawing system bars) do not consume the insets when an action mode is
active.
Bug 17691453
Change-Id: I459622eaf161a96152fb9ac5f60bb9508aa4de89
This checks if the phone app is currently getting or in a call when a
media key event is sent and sends it to the phone session instead of the
foreground app if it is.
bug:17527302
Change-Id: Ie5d6cf0c897da81d106f2b1a0561b79f4fc35e82
