Commit Graph

7 Commits

Author SHA1 Message Date
Jeff Sharkey
0ab7007631 resolve merge conflicts of 358f0d4fc8 to master
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
2020-12-08 11:01:05 -07:00
Jeff Sharkey
52b9862f87 Improve OWNERS coverage across frameworks/base/.
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.

Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas.  Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:

-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage

Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance.  With this extensive
effort, we've now improved our coverage as follows:

-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage

This specific change is automatically generated by a script that
identifies relevant "include" directives.

Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
Change-Id: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
2020-12-08 08:36:28 -07:00
Siarhei Vishniakou
efed16630a Track per-window information in ViewFrameInfo
FrameInfo will now be per-window; that is, per-ViewRootImpl.
Some of the information should remain “global” (it remain in Choreographer),
while some information is going to become ViewRootImpl-specific.
Before the information gets passed to the native layer,
 the ViewRootImpl-specific info will be stitched together
with the general Choreographer info.

This change is useful in order to correctly correlate frames with a specific
input event. In the unlikely scenario of a user touching two windows of the
same app simultaneously, this change will allow us to correctly measure the
latency of both frames produced by the windows.

Design doc: https://docs.google.com/document/d/1KMpMBlOxnl7zkWBCbXZZE6ZlaHEA4efYnN6WYK8n3FE/edit?resourcekey=0-eqooVNP0SskupljlTFvtOQ

Test: atest ViewFrameInfoTest
Bug: 169866723
Change-Id: Ib0bf9cd51cbcc0b9b70460c929c480eb490ec322
2020-12-01 15:07:50 -10:00
Brett Chabot
7818ee4f57 Remove android-support-test from InputTests.
android-support-test is long deprecated, and the runner flakes if both
androidx.test and android-support-test are included.

Bug: 171910851
Bug: 172570181
Test: m -j InputTests
Change-Id: Icd257481583e9555875d5fd0e93caba49d44caab
2020-11-05 09:03:24 -08:00
Siarhei Vishniakou
3d34eeb8d0 Remove batched consumption from onStop
This patch reverts the earlier patch, ag/11959351, because the correct
solution is aosp/1459888.

When batched input is available, the Choreographer::CALLBACK_INPUT is
scheduled by ViewRootImpl. The callback always runs, even if onStop has
been called. So the earlier patch was invalid.

In practice, what happened was that the batched input was not getting
consumed after FOCUS event was received in the receiver. This was fixed
in aosp/1459888.

The consumption mechanism is complex, so I added a doc explaining how it
works, for future readers.

The newly added test, IncompleteMotionTest, ensures that this regression
does not happen again.

Test: atest IncompleteMotionTest
Bug: 160561987
Change-Id: Ic0a453ebbce1f847de8e9cb87bdffdaf72c12637
2020-10-27 17:12:17 +00:00
Siarhei Vishniakou
34fad5cc21 Put InputTests into presubmit
To prevent regressions, such as the ones introduced by the recent
InputChannel refactor, put InputTests into presubmit.

Test: none
Bug: 169154685
Change-Id: I8b8aa04e836455ed7bd21cf5f63c9fa8ffabacc2
2020-10-21 13:50:19 -05:00
Siarhei Vishniakou
57dff76579 Show ANR dialog for unresponsive gesture monitors
If a gesture monitor is unresponsive, today there will not be an ANR
dialog. Since the input channel token for the gesture monitor is not
provided to WindowManager, there is no way for the proper ANR to occur.

That means, the user will not know that the gesture monitor isn't
working.

To fix the issue, we record the pid of the caller when first registering
a gesture monitor. This will be stored in InputManagerService.
Next, when an ANR for this gesture monitor occurs, we will provide this
pid to the WM.

WM will use this pid to properly blame that process.

Bug: 161904619
Bug: 160903019
Test: atest AnrTest
Test: adb shell input dump
Change-Id: Ie1a16352a116914ba6550958ad41de07cff063be
2020-08-04 09:55:40 -05:00