Also don't show smart actions for selections in text with unsupported
characters.
Bug: 116321860
Test: runtest -x cts/tests/tests/text/src/android/text/util/cts/LinkifyTest.java
Change-Id: Ib2ee544b5783234fba8ee2f93adf0b36b039520f
Merged-In: Ib2ee544b5783234fba8ee2f93adf0b36b039520f
Fixes an issue where input intended for the keyguard could end up going
to a different display.
To prevent this, make sure that only the default display can get focused
when the keyguard is showing.
Change-Id: I6463c44aedca06930d2c9bda7c45ffd93141308c
Merged-In: I6463c44aedca06930d2c9bda7c45ffd93141308c
Fixes: 71786287
Test: atest DisplayContentTests
- KEYCODE_ASSIST: Looks for default VIS in system partition
and launches it.
- Ensure foreground activity assist context extras are collected
and sent to VIS.
- KEYCODE_ALL_APPS: Sends Intent.ACTION_ALL_APPS. For TV,
this targets default launcher package in system partition.
Test: Manual: ASSIST: adb shell input keyevent 219
Test: Manual: ALL_APPS: adb shell input keyevent 284
Test: also tested with --longpress for these keys
Test: Manual: Checked with dummy app populating overridden
onProvideAssistData()
Test: Keypresses after overriding ALL_APPS and ASSIST
on Nexus Remote
Bug: 37950079
Bug: 38496261
Change-Id: I96d9de67d4a442a8c6cb7feec28fc9aeb0dcbc18
Replacing app opps fix with the flag that is used
elsewhere.
Bug: 37442941
Test: Verified that toast and system overlay still goes
away on permission and a11y service capability screens.
Merged-In: I1a3e3c5b1696a5f5b95eac187acb5a03863b4a0b
Change-Id: If9bec515105369055415d54c7fcad7a65431f8e7
Bug: 62196835
Test: Created an accessibility service that displays a system
and a toast overlay, confirmed that it disappeared when we
reached the accessibility permission screen that uses this
flag.
Change-Id: Ic51ead670fc480e549512ba1d02f49d9c13bc3f0
Bug: 62196835
Test: Created an accessibility service that displays a system
and a toast overlay, confirmed that it disappeared when we
reached the accessibility permission screen that uses this
flag.
Change-Id: Ic51ead670fc480e549512ba1d02f49d9c13bc3f0
Bug: 62196835
Test: Created an accessibility service that displays a system
and a toast overlay, confirmed that it disappeared when we
reached the accessibility permission screen that uses this
flag.
Change-Id: Ic51ead670fc480e549512ba1d02f49d9c13bc3f0
SurfaceControl.
In a recent CL we introduced a call to Surface#createFrom, in order to
recreate the Surface object from the underlying SurfaceControl, as a
workaround to emulate when it was parcelled over binder in the past.
However this is causing BufferQueue abandoned errors when stopping and
resuming some applications. To understand them, we need to revisit the
SurfaceView destruction process when handling onStop.
First mWindowStopped will be set to true (SurfaceView#windowStopped),
and we should then enter updateSurface. Our requested visibility will
now be false and so we emit the Surface destroyed callbacks. Notice in
the finally block in mUpdateSurface, we will release mSurface, but we
will NOT null mSurfaceControl. Inline documentation explains why.
In the case that the activity is not actually being destroyed, it's
possible that we may not get a dispatchDetachedFromWindow. This means
that we will not null mSurfaceControl. Now if the activity is
un-stopped and we re-enter updateSurface we encounter a problem
state. "creating" will be set to false since mSurfaceControl != null,
however mSurfaceControl will not point to a valid surface.
Prior to the introduction of the #createFrom call, this unwanted state
didn't cause any problems. Because mSurface was released back in the
finally block as we were stopping we now fall out of the
mSurface.isValid() block in updateSurface. As we reach the finally
block again, we would now set mSurfaceControl=null since the app was
no longer stopped. Later when we reach updateSurface again (which
tends to happen quite often) it will now be null and we will correctly
set creating=true, create a valid SurfaceControl, and move along
happily. However following, the introduction of this
Surface#createFrom call we will now reinitialize the Surface from an
invalid underlying SurfaceControl. This means we will enter the
mSurface.isValid block, but will proceed to emit an invalid Surface to
the client in the callbacks.
We avoid this state by making creating=true even if
SurfaceControl=non-null when the calculated visibility changes from
invisible to visible.
Bug: 63251745
Test: Manual of app from bug and apps from previous related bugs. go/wm-smoke. Additional manual testing of many SV apps.
Change-Id: Icc32a34cac239d65267da705cc23feb23e1ceb67
The attributes for View, paddingHorizontal and paddingVertical,
were added in the O release and are documented in R.attr. But they
should also be referenced in View itself, alongside the other
padding parameters.
Similarly, the new layout_MarginHorizontal and
layout_marginVertical should be referenced in
ViewGroup.MarginLayoutParams.
Bug: 63128350 Add docs about new padding/margin params
Test: built docs, checked the result
Change-Id: I3021df5ea83c469811b4a6ec6ecd3ab2966ec384
The description for `AutofillManager.isAutofillSupported` doesn't make
clear that either the device or the user can make autofill unsupported.
Bug: 62604325
Test: Ran 'make ds-docs -j16' and staged content to
go/dac-stage/reference/android/view/autofill/AutofillManager.html#isAutofillSupported()
Change-Id: I298b9f535e23dc3cb54fabed36642523753c13a5
There is an issue (seemingly preexisting) with getPositionInWindow
after toggling view visibility. We see it when showing a view,
hiding it, and then showing it again. At this point we end up
with this call-stack:
SurfaceView#setVisibility->SurfaceView#updateSurface
->View#getPositionInWindow
and getPositionInWindow fills in the wrong values. This newly discovered
bug is tracked as 62839113.
In a second bug, introduced in the SurfaceView refactoring,
we are not appropriately clearing the last RenderThread reported
position when toggling visibility. This means that even after the
setVisibility call when getPositionInWindow begins returning
the correct values, we don't update the position. This CL fixes
that and fixes 62653411 as a result. However we still have a flicker
as we did in N as the initial position is wrong.
Test: Manual from bug, go/wm-smoke
Change-Id: I1037b8dfdb343f9ce8c8616eb9197c6d039ed133
Fixes: 62653411
Bug: 62839113
Creating the surface for every change (such as creation and
visibility) can lead to issues swapping buffers. This
changelist limits the action to only when the size changes.
Change-Id: Ic549d244613a93a43a9f4ddf284bbfb0c13300fa
Fixes: 62801621
Test: follow repro steps in bug, verified no crash.
Test: go/wm-smoke
