tree c48327588557a89afb670636aa690c6dd6fe8348
parent 21b0037dac3486703303c72ba92ff4ac364c6ebb
author Bernardo Rufino <brufino@google.com> 1597844594 +0100
committer Bernardo Rufino <brufino@google.com> 1601915823 +0000

Block untrusted touches in InputDispatcher

With topic CL InputDispatcher now has the effect of each window for
cross-UID touch occlusion rules: ALLOW, USE_OPACITY or BLOCK_UNTRUSTED.
Check topic CL for exact meaning of each. USE_OPACITY is only used by
SAWs for now.

In this CL, InputDispatcher make use of that information for the stack
of windows above the touch-consuming window to block a touch or not.

The summary of the rules are:
* If there is any visible untrusted window from a different UID (than
the touch-consuming window UID) that has state BLOCK_UNTRUSTED, the
touch is blocked.
* Else, if there is any visible untrusted window from a different UID
that has state USE_OPACITY, we compute the composed obscuring opacity
by each stack of USE_OPACITY windows per UID of occluding window.
We take maximum of those and compare with secure setting
"maximum_obscuring_opacity_for_touch", if it's greater than the
setting the touch is blocked. This means the remaining visibility on the
touch-consuming window is not high enough to let the touch happen.
* Else we don't block the touch.

More details on go/cross-uid-touches. This doesn't interfere with
existing flags FLAG_WINDOW_IS_OBSCURED and
FLAG_WINDOW_IS_PARTIALLY_OBSCURED.

To compute the opacity we also propagate the alpha of each window from
SurfaceFlinger to InputDispatcher.

Test: atest WindowUntrustedTouchTest
Test: atest inputflinger_tests inputflinger_benchmarks libinput_tests
Test: go/try-cross-uid-touches for manual testing
Bug: 158002302
Change-Id: I673d7a5f16b19952311e8cb44a48af4349a4bd40