1. Create a OWNRES file in the textclassifier test folder
2. Add me and licha@ to the OWNERS files.
Test: N/A
Change-Id: I5bedfc28d2ea18cdaa2dac7e0e799cf225ba99d1
Per request from a partner, these APIs will not be restricted as they
are in use. This is conceptually a partial revert of change 5d123b6775.
NoNonSdkCheck: b/170729553
Bug: 171933273
Test: Treehugger
Change-Id: Ibb525e9a9e2fc90248b74f45f3cdcb0be7487c3a
This makes view root dispatch the up-to-date WindowInsets to the app.
Fix: 166619182
Test: Steps in the bug (comment#12)
Change-Id: I8c47e3be84357f65084a7d9994f7d7b68f15611e
(cherry picked from commit fd94351305)
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
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 from
detailed ownership information confirmed by team leads.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Change-Id: I9789c97c1de8e5d962b48c29c57d82fe83729eba
This makes sure the write operation (NativeInputApplicationHandle
::updateInfo) is always called from window manager side once when
calling SurfaceControl.Transaction#setInputWindowInfo or
InputManagerService#setFocusedApplication. If the info of input
application handle is changed, a new instance will be created.
That avoids the race condition of reading the fields of the same
InputApplicationInfo instance from input dispatcher.
Bug: 171857140
Bug: 161334769
Test: WindowInputTests
Change-Id: I70de9835c7699fe6f56fc3655b0fee5c317ecc3a
Some apps like Netflix crashed while handleWindowFocusChanged but mView
somehow has became null.
It's fair to check null for mView.findFocus() since other places
in ViewRootImpl that calling this method also add null check.
Fix: 153862451
Test: atest CtsInputMethodTestCases
Change-Id: I86bd5f3193deabe28bb425a8564017f7b32b90f3
(cherry picked from commit bdaa14bf18)
Having a hidden abstract method for a class that can be extended
means that public implementors cannot implement these hidden methods
posing a risk that custom implementations will not have required
abstract methods resulting in an exception.
Bug: 151134792
Test: make update-api
Change-Id: I758d12465fabc671be19bedeeceb16885de23c87
Merged-In: I758d12465fabc671be19bedeeceb16885de23c87
Exempt-From-Owner-Approval: large scale suppression of existing issues,
no-op in terms of behavior
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I8285daa8530260251ecad6f3f38f98e263629ca7
Change-Id: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
