Target the two biggest offenders:
- Coalesce keyguard setHidden(false) calls during unlock.
- Make sysui->WM call async.
Found during investigation into b/11221659.
Bug: 11221659
Change-Id: Icab48376bc356a933e0f9940bc2f924e2e77ab22
With the new tuned vsync offset, vsyncs are likely to occur shortly
after the input is received, meaning we will empty the input queue,
and thus won't schedule input consumption until more input is
received. If an application then speculatively posts draw commands to
the main looper faster than 60 hz, it will eventually end up blocking
in eglSwapBuffers. Since we're blocking in eglSwapBuffers, we won't
even schedule consumption until after the current frame (8-16ms), and
it's entirely likely we won't actually get around to consuming input
until after the next frame (another 16 ms of latency). This means we
can often go 16-32ms without processing any input events, causing
very noticeable amounts of jank.
Rather than waiting for the next input event to schedule input
consumption, speculatively schedule it every frame as long as we've
consumed some motion batch during this frame.
Bug: 11398045
Change-Id: I25e46308e00e9f9de00a1d8906f6b0e0f2e845b4
IMEs recently gained the ability to layout out under the nav bar,
but our core measuring logic does not give height=WRAP_CONTENT windows
the entire screen height when computing desired window height.
Since IMEs can be identified by type, let them use the entire screen
height for measuring purposes, to properly handle the cases where
space is constrained, making that unaccounted-for nav bar height
important.
Bug:11215678
Change-Id: I1d0b73454c0c629e7d669b9de70641c7e8c4d333
A measurement optimization has exposed some apps that are relying
on incidental layout requests to have themselves update. With the
optimization enabled, these apps break.
Apps targetted at older versions of Android should not
break due to this optimization.
bug:11192311
Change-Id: Id5fc7f83ec2cb1541d3d0d16f951cd57c0afaccd
We have become too aggressive about not allowing windows to draw while windw
animations are running, basically not allowing any drawing in any window when
there is any window animation. So if you did a relayout while the status bars
were being animated, your window would stop drawing until that status bar
animation was complete.
This change relaxes those rules in two ways:
- A particular window will only be told to stop updating when *it* is
currently involved in a window animation. So animations in status bars
will not stop app windows from update, and vice versa.
- If a window receives input events while it is in the "do not update"
state, we will immediately terminate that state and start allowing it to
draw. If the user is actually interacting with a window, we don't want
to wait to show feedback.
Change-Id: I72574eec048aee53115b46a78686cf27f42c42f7
The existing View.SYSTEM_UI_FLAG_IMMERSIVE flag will be somewhat
redefined. Swiping will clear the flags, revealing the normal bars.
The new View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY flag will enable
hideybars - the auto-hiding, semi-transparent bar mode.
Bug:11062108
Change-Id: Ibf8be9072f0075953baa4580cd976e7562d44455
Ensures accessibility framework is notified when subtree visibility
changes as a result of hiding descendants. Fixes collision between
HAS_TRANSIENT_STATE flag and IMPORTANT_FOR_ACCESSIBILITY mask.
BUG: 11087525
Change-Id: I92dba27350970a09e76b5a878c7604ea06cae197
Specifically, ignore any flags that alter the visibility of the navigation
bar and transparency.
BUG: 11082573
Change-Id: I17264dc55a1c6c3cb9b9cf92d5121799cecee5b8
