Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Merged-In: I719b5c94e5b1f4fa562dd5d655953422958ad37e
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
(cherry picked from commit 8c854f86a4)
InputMethodManager#sInstance is a long live static object so we have to
set its field with right value, otherwise any object referenced by it
cannot be gc including potential activity context.
Now InputMethodManager#mCurRootView is set to null in
InputMethodManager#onPreWindowFocus which is invoked when app's
ViewRootImpl received ViewRootImpl#W#windowfocusChanged from WMS.
However, in the ViewRootImpl#W#windowfocusChanged, mViewAncestor is a
weak reference which get() may returns null sometimes.
One scenario is the ViewRootImpl#W#windowfocusChanged is called after
ActivityThread#handleDestroyActivity. The activity is destroyed and its
ViewRootImpl get GC'd. Then InputMethodManager#onPreWindowFocus won't
get called and InputMethodManager#mCurRootView won't be set to null.
And it is a proper time to set InputMethodManager#mCurRootView to null
when the window it served dismissed.
Fix: 116078227
Test: Break at ActivityThread#handleDestroyActivity and ViewRootImpl#W#windowfocusChanged
Change-Id: I8fabb30f14bcb2cd7019e29b6642b4562d49d248
Signed-off-by: daqi <daqi@xiaomi.com>
With my change [1] in Android N, applications no longer need to
manually call this hidden API even when directly implementing
InputConnection interface without extending BaseInputConnection [2].
So far applications that we have confirmed to be using this hidden API
is Chromium and browsers that are supposed to be built on top of
Chromium source code [3]. Actually my change [1] was per request from
Chromium team and Chromium does not use this hidden API on Android N
and later devices [4].
Moving forward, with this CL applications that target API 29 and later
are no longer allowed to use this hidden API since we see no actual
use case of this hidden API on Android N and later devices so far.
If you have any reason to continue relying on this hidden API, please
leave a comment in Bug 114740982.
[1]: I571d6cc9c6e461d8994aa7496e7e18be13766411
159dd47db3
[2]: This scenario had not been suppored until Android N.
See also other CLs that are tagged with Bug 24688781.
[3]: https://cs.chromium.org/chromium/src/content/public/android/java/src/org/chromium/content/browser/input/InputMethodManagerWrapperImpl.java?rcl=525c72b0f4694d6b3f93bcc7797d0411c2fa683c&l=113-128
[4]: crbug.com/551193
Bug: 114159783
Bug: 114740982
Test: compile
Merged-In: I41d6419438cef92cce81cc33d9db00dd2ee89d33
Change-Id: Iac81f49413605271fccc0b8aec3e6ed95925f061
Bug: None
Test: I solemnly swear I tested this conflict resolution.
Change-Id: I0807ae67e0ed3e84f17af962dc8b7a3152f8103f
Merged-In: I4147b038ed7adf0311ee9918b44766f82a057eaf
For packages:
android.view.textservice
android.view.textclassifier.logging
android.view.textclassifier
android.view.inputmethod
android.view.autofill
android.view.accessibility
android.view
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: Ie4663ebd4640b2893e575e599582d2c9530da313
Merged-In: I4147b038ed7adf0311ee9918b44766f82a057eaf
Bug: None
Test: I solemnly swear I tested this conflict resolution.
Merged-In: I773bda19dc7b32c01bf064bf78b517896e8df991
Change-Id: I2c9bd92522932175856fb72ca5cce2c1999f4a1e
For packages:
android.view.animation
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I52f3e770dd1e8240e67c897e7788bd928145f583
Merged-In: I773bda19dc7b32c01bf064bf78b517896e8df991
Such that it gets executed after setSurface, in order that
mReqUsage has the correct flags set.
Test: Take trace, ensure that allocateBuffers actually allocates
in the right format/usage by ensuring that dequeueBuffer doesn't
trash them immediately again.
Bug: 111517695
Change-Id: I94b402d7b29d565155a77a2d09106246261712d2
Root cause has been identified, but fix is too risky. Instead, we
remove the WTF for now and readd the fix as well as the WTF
in master.
Note that due to defensive programming, in case we land in the WTF
case, it doesn't cause any real bug.
Test: boots
Bug: 110834518
Change-Id: I0da1e48e420c3fcde0e818b7fe0527da9155a159
When SurfaceControl is created with creating variable
in updateSurface(), sizeChanged is also set.
So, setSize() is called, and it blocks UI thread
until the transaction is handled in SF.
There is no need to resize in the creation time,
because size is already set when creating SurfaceControl.
Test: systrace any app including SurfaceView
Change-Id: I65028b4d0d0ba2b75fbe089c98a11a56b6c08104
Otherwise there is a big performance hit in all kinds of
situations where we do operations with the region, specifically
when:
- updating input windows
- insetting the cutout during layout
- touch dispatch
Test: DisplayCutoutTest, WmDisplayCutoutTest
Bug: 110464019
Bug: 110452325
Change-Id: I94a25c3794ecd33b8b7204ca308ac91623498f13
If draw() invokes postDraw that sets the next callback, the
callback will never be invoked.
Test: Long-swipe-up from navigation bar
Change-Id: If2e4dfff8a845b73fa77426305d5ece1921857e5
Fixes: 109701914
If an app crashes during Keyguard transition, make sure to keep
Keyguard transition
Test: AppTransitionTests
Test: go/wm-smoke
Change-Id: I80b80952f93d2b5611754f05a3dc333905cd1c86
Fixes: 80132133
In a situation where a focused view consumed only the UP of a key
and the unhandled key manager would focus a listener, it wouldn't
drop focus unless the original key was pressed/released again.
This updates the record of captured keys before it can be consumed
in the view hierarchy.
Bug: 79993136
Test: Added a test for this to cts ViewTest#testUnhandledKeys
Change-Id: I5dfdcf16c5c41e9ad51cb62b385580c5493e8520
This field contains the autofill session id (Thank You, Captain Obvious!), which
is useful to correlate autofill metrics that are not logged on
AUTOFILL_REQUEST.
Test: atest CtsAutoFillServiceTestCases # to make sure it didn't break anything
Test: manually run some test and watched
'adb shell logcat -b events | grep sysui'. Example:
[757,913,758,4,806,android.autofillservice.cts,871,android.autofillservice.cts.LoginActivity,914,2,915,2,1456,-2045861404
Fixes: 80093094
Merged-In: If4b1c9ab616b2ba580745096894997eb7edb3e34
Change-Id: If4b1c9ab616b2ba580745096894997eb7edb3e34
Test: atest CtsAutoFillServiceTestCases # to make sure it didn't break anything
Test: manually run some test and watched
'adb shell logcat -b events | grep sysui'
Fixes: 80151641
Change-Id: I5b83e6ceb549a641d10c39bbfd4f24d0a43d1a23
In TextClassificationManager, we use the application context to reduce
the likelihood of leaking the underlying Activity. Unfortunately, some
places (e.g. auto, system_server) don't actually provide us an
application context, so we need to fall back to whatever context was
passed in to TCM in the first place.
Bug: 80188317
Test: none
Change-Id: Ib4b2e6ed543d3ed56cefd8f56717855158cdc0fe
ActionBarOverlayLayout used to drop WindowInsets, extract the content insets
as a rect, and then dispatch a modified rect to the content view; this because
there was no way to retarget the WindowInsets to the content view, and the
WindowInsets were not truly immutable. That means however, that other kinds of
insets than the content insets do not get dispatched, such as the display cutout.
To fix this, we add APIs to inset WindowInsets, make them immutable. Note that
a similar change is needed for the support lib.
Bug: 79733300
Test: atest ActionBarOverlayLayoutTest
Change-Id: I6a69d8462163ca5e66fdb53f83def6bc4063f8aa
Fixes jank issues where trimMemory gets scheduled during an
animation. trimMemory likely hits code that is not in the
page cache anymore, leading to high execution time because of page
misses. Scheduling it after the next frame has been drawn
minimizes the risk that this page miss actually causes jank.
Test: Boot, switch between a couple of apps.
Bug: 78611607
Change-Id: Ia1fc411fbe6ca07861183ae484124406681118e5
Approach here is to register a content observer that invalidates the
TC settings whenever updates to the settings happen.
This CL also ensures that the TC is invalidated when a settings
update happens. This is because the settings may change what
TC the system returns.
TextView's SelectionActionModeHelper has been updated to not cache
the settings and get them directly from TCM (which caches the settings).
NOTE that we expect TC settings to rarely change.
Bug: 77539576
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: manual - Made changes to TC settings and observed logs / app behaviour
Change-Id: I88bbb6f951708b17323fac1a72385fe808d270a5
Otherwise it could lead to parameters applied in the wrong frame,
leading to jank.
Test: Open notification
Bug: 78611607
Change-Id: Ia7900e753b29187a7a7b81f393666687e8b8e04b
Merged-In: Ia7900e753b29187a7a7b81f393666687e8b8e04b
This way the newest PendingIntent will override any matching ones.
Bug: 78286917
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationTest
Change-Id: Ib130fa5979c3dab628e7be668331cb94d23e0829
We use ids to break ties when sorting views just to
guarantee that we won't break sorting. But we don't
want to have our swipe order determined by arbitrary
ids.
Before resorting to such a crude tie-breaker, look at
a view's children to try to break a tie using their
bounds. That sort is more based on what's on the
screen, and will also produce the same result from
the same ui.
Bug: 78348191
Test: Switch access order is much more sensible on
Recents. Also ran a11y cts.
Change-Id: I918eae3b0d27e889a53d05a6ebe925e38ce5d7b4
