Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit f9d97b54 authored by Egor Pasko's avatar Egor Pasko
Browse files

Introduce View#probablyHasInput

Exposes a hidden (behind @hide) method in android.view.View backed by
InputConsumer::probablyHasInput() from frameworks/native introduced by
ag/25438533.

More specifically: `boolean View#possiblyHasInput()`.

Usage constraints:

0. This is experimental. The usefulness of the hint has not been
   broadly proven, and the functionality can be removed soon if there is
   no robust data to support the usefulness.

1. The high-level API visible to apps would be effectively opt-in: does
   not create any state if not used.

2. An app could use this hint to yield from longer tasks on the UI
   thread (which it is not supposed to create in the first place). This
   is a very niche workaround for Chrome's complexity.

3. Using the Input Hint in WebView should probably be disabled: WebView
   has less control over the embedding app than Chrome, and less
   knowledge when to prioritize for input handling.

4. There is a good question whether probablyHasInput() should guarantee
   to return true only when input is queued. While it is good to return
   precise results, clients should only use this API as an optimization
   hint without sacrificing correctness. Due to the growing complexity
   of input handling on Android, it is not too hard to imagine that in
   some not-too-distant future input would get filtered by the Framework
   on the application side, potentially skipping the contents from the
   ready-to-read file descriptor or an accumulated InputConsumer batch.

Bug: b/314973388
Test: Tested with a custom build of Chrome, it returns true sometimes.
Change-Id: I874767fcea9a0f31ad510919599af50cf33c7980
parent c4f7678f
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