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

Make TYPE_VOICE_INTERACTION a trusted overlay

Unfortunately, VoiceInteraction APIs (aka. assistant APIs) encourage the
app to use a fullscreen overlay window and put the UI inside, providing
the appropriate touchable area (check b/173075950#comment8 for more
details). This is problematic for go/untrusted-touches as the
non-touchable parts of the window will end up blocking touches. Ideally
we'd have multiple windows instead of one window with multiple touchable
areas, but it's too late to change the API.

The approach is very similar to the one employed by the IME (both use a
SoftInputWindow, which is wrapper that controls the actual window).
However, the IME works because its window is considered a trusted
overlay. Similarly, accessibility overlays are considered trusted
overlays.

Similarly to the the IME and accessibility services, to change the
assistant, user interaction is needed along with a warning message about
the powers of the role (check bug). Because of this, I think it's fair
to make the assistant windows (ie. TYPE_VOICE_INTERACTION) trusted
overlays.

This means touches that pass through that type of window won't be
blocked for go/untrusted-touches and won't be flagged for
FLAG_WINDOW_IS_OBSCURED either.

The (Google) assistant did indeed hit this case (check bug).

Bug: 173075950
Bug: 158002302
Test: Launch Assistant via Gboard dictation, verify touches are not
      blocked/flagged via toast.
Change-Id: I2d91f01254fc4ee48554b0f5874fa81d88d5ab6f
parent d23fa9ad
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