tree 7de99cdd3b45e3da7da4d9ebe5cda061055a3539
parent abd78597dfaecf6d2d0815c494fe85ae4005f2de
author Bernardo Rufino <brufino@google.com> 1597844730 +0100
committer Bernardo Rufino <brufino@google.com> 1601898277 +0000

Block untrusted touches opt-in

The feature is disabled by default and can be in one of 3 modes:
disabled, permissive and block. In permissive we only log but
don't block the touch. This knob is implemented in a global setting
block_untrusted_touches. It can also be disabled per occluding app using
app-compat infrastructure, so if you disable for a certain app, overlays
of that app won't have the chance of blocking touches. More details
on these on go/try-cross-uid-touches.

Each window has 3 modes related to touch occlusion: ALLOW, USE_OPACITY
or BLOCK_UNTRUSTRED. Check code comments for the meaning of each. If the
feature is turned off for the app, then the mode is ALLOW. Else if it's
a SAW, then it's USE_OPACITY. Else it's BLOCK_UNTRUSTED. These states
are passed to InputDispatcher, who then perform the proper checks and
blocks or not the touch.

If input dispatcher deems the touch unsafe, depending on the feature
mode, we filter out such touches and log a message to logcat.

I also introduce a global (secure) setting
MAXIMUM_OBSCURING_OPACITY_FOR_TOUCH which represents the maximum
opacity allowed per UID that's obscuring the touch-consuming window
according to some rules, which are discussed in topic CL for
InputDispatcher code. This maximum is initially set to 0.8, but we'll
be conducting local experiments to determine the final value.

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