tree 1d0f80299d9d73bdee05c0cce1054e4f97bdf05d
parent ab008846a8eea36f02a7762d65ca233004929b47
author Bernardo Rufino <brufino@google.com> 1605283845 +0000
committer Bernardo Rufino <brufino@google.com> 1605809392 +0000

Use opacity rule for animating windows

Windows that are being animated will use the opacity rule previously
only applied to SAW. This means that if their opacity is below the
maximum obscuring opacity allowed (now this is 0.8), then the touch is
allowed.

During some animations (ie. exit animations) the window is made
pass-through on purpose so the user can interact with the new content
as soon as possible. This is specially problematic with animations that
take long to finish and the alpha takes time to settle on 0. The result
is the user has to wait until the animation finishes to be able to
interact w/ the device.

Applying this rule allows the user to interact w/ the device as soon as
the alpha in the animation is below the threshold (0.8).

We chose to use the same mechanism for SAW (including the same
threshold) for code simplicity and because these animations are either
controlled by the system or when they are supplied by the app they are
limited to 3s (ag/10438533), so they are safe.

We had previously connected the touch occlusion mode of the
InputWindowHandle to the WindowState in populateInputWindowHandle(), but
that method is only called if the window has an input channel. If the
window doesn't have an input channel it falls into the early return of
UpdateInputForAllWindowsConsumer.accept() that calls
populateOverlayInputInfo() instead (overlay here comes from the fact
that it doesn't handle input, I *suspect*). Since now, the default
occlusion mode (BLOCK_UNTRUSTED) was the appropriate for such windows.
However, now we need animation windows to be USE_OPACITY, and some of
those animation windows (eg. exit animations) don't have an input
channel, so now we also connect the occlusion mode of InputWindowHandle
to the WindowState in populateOverlayInputInfo().

Test: Verify on exit animation, touch is not blocked.
Test: atest WindowUntrustedTouchTest
Bug: 158002302
Bug: 172787052
Change-Id: Idbf847b758299d40764240cf3e84629efb3038b0