Skip to content
Commit 64bbd4b1 authored by Bernardo Rufino's avatar Bernardo Rufino
Browse files

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
parent abd78597
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment