* changes:
Rollback chooser menu to version Q behavior for accessibility button (2/n).
Rollback chooser menu to version Q behavior for accessibility button (1/n).
@SystemApi requires @hide, so @TestApi is needed for these to
be visible to CTS testing
Test: methods visible to CTS test
Bug: 152052560
Change-Id: Icd7f82f3859a1deccd41d2279d8f9722a42df957
Allow separate Activities to handle the multiple-target case for the hardware and software shortcuts. Migrate from an extra to an explicit class so the Intent dispatch will launch the correct Activity for the particular shortcut.
Bug: 151294664
Test: manual test
Change-Id: I54bb1d3ab91e2757c465e8763786d0234f6d4ea8
The previous solution used a different transaction from the one used in
SeamlessRotator#finish. So the transaction might be applied in an
unexpected order between here and there when the target frame number is
reached.
This CL reverted the previous solution. Instead, we don't dispatch the
leash if it is not ready. For the client, it won't play the animation
until obtaining the leash.
Fix: 154195854
Test: Rotate device to change the orientation in Camera, and see if
navigation bar stays visible.
Test: Check if transient bar can be shown/hidden/aborted as expected.
Test: Make sure b/153104643 stay fixed.
Test: atest InsetsPolicyTest
Change-Id: I29f80f1c77615b0a3cde38df265220f48d66f117
This change is to prevent misuse of window context from app
and leads to performance drop on system by limit the numer of window
context an app can use. Code snippet below is a sample to cause
this issue:
```
Rect getBounds() {
Context windowContext = context.createWindowContext(...);
return windowContext.getSystemService(WindowManager.class)
.getCuttentWindowMetrics().getBounds()
}
```
This method could be invoked dozens of times and produce dozens of window
tokens. It would slow down the speed of window traversalling. These
token won't be removed until system server has been GC'd.
Test: atest WindowContextTests WindowContextPolicyTests
fixes: 152934797
Bug: 153369119
Change-Id: I927e85a45c05c4d90b51a624ea408ff3a3ffce93
For testing the accessibilityNodeInfo constructor methods, making this
method, AccessibilityNodeInfo#getSourceNodeId, to become a testing API.
Bug: 154163930
Bug: 154163953
Test: a11y CTS & unit tests
Change-Id: I9a2ff665996e28d6d5770723d98b49f96eab1f50
Adds filter to prevent passing binder objects in the extras and styling
APIs for inline suggestions. Avoids these to be used to send over remote
objects for Autofill provider and IME to communicate through private APIs
bypassing the OS.
Bug: 152316540
Test: atest CtsAutoFillServiceTestCases
Test: atest InlineSuggestionsRequestTest
Change-Id: I00940a845ed0e2546cbe09fa36e2439869c2f783
If there is a sync transaction, but blast is not enabled,
mNextDrawUseBLASTSyncTransaction will be true, but mBlastBufferQueue
will be null. This will cause a NPE when trying to call
mBlastBufferQueue.setNextTransaction
Test: Use sync transaction without blast
Fixes: 154527936
Change-Id: Ibff2de7fc7460f882acaceb0182c68ea4b05afb7
This is an implementation of long screenshots supporting
interactive, incremental capture of scrolling content using
a cooperative API between the app process and the system.
Design goals:
- Provide for tile based incremental screenshots of scrolling content
- Support existing apps without developer action
- Provide support for non View-based Apps & UI toolkits
Bug: 148131831
Test: atest \
FrameworksCoreTests:android.view.ScrollCaptureClientTest \
FrameworksCoreTests:android.view.ScrollCaptureTargetResolverTest \
FrameworksCoreTests:com.android.internal.view.ViewGroupScrollCaptureTest \
FrameworksCoreTests:android.view.ScrollViewCaptureHelperTest \
WmTests:com.android.server.wm.DisplayContentTest
Merged-In: I6c66a623faba274c35b8fa857d3a72030a763aea
Change-Id: I6c66a623faba274c35b8fa857d3a72030a763aea
While debugging SurfaceView transaction usage I noticed this
code was unconditionally dead. Notice the else statement
only contains the single if statement within, so it could
be written as else-if. But then notice the condition of this
rewritten else-if is contained within the original if and
so it can never be entered.
Bug: 153120755
Test: Existing tests pass
Change-Id: I032b17911a9c71a1e3d09e3933e6f6a3d86dffb6
There's no need to keep it synchronous
Bug: 154304487
Test: atest NotificationShadeWindowViewTest
Test: atest WallpaperControllerTests
Test: manual
Change-Id: I547e05fb4e2a5f2d30cfc5de354c36cd9070e65b
In Q, app developer would've to wait for InputConnection on Editor before
showSoftInput() could be called. This made API very un-intuitive. While
WIC.show(ime) took care of some of the scenarios, it didn't handle
showing IME from onCreate() i.e. when control is not yet available.
This CL introduces a pending IME show request that waits until IME
control is available.
Test: atest WindowInsetsControllerTests#testShowImeOnCreate
Bug: 153014086
Change-Id: I93dd5790e1fb3d7841ad1323a45cd3bae2d6e9b8
Instead, the click listener is set on the app opp container since
clicking on the app opp container results in the same action as clickng on the
individual app icons. As per a11y guidance, only set the click listener
on the container.
Test: manual
Fixes: 153281363
Change-Id: Ic1c2bdb2f77fc459a3a3e997ed494b4bab36a273
In ImeFocusController#onPostWindowFocus -> onViewFocusChanged,
it implies that the view has focus after onPostWindowFocus, this logics
we keep leveraged from IMM#onPostWindowFocus -> focusInLocked() long
ago, which may not always be true as SearchView layout may call
View#clearFocus when size changed after IME switcher shown.
When IME switched and back to app activity, in the above call path,
even activity window focused, and set the fallback focus view as
activity's root view, but the root view is not actually focused,
if we set this view as the next served view, then calling
View#onCreateInputConnection will return null, because it's not an editor.
Use correct view focus state when calling onViewFocusChanged.
Fix: 153612876
Test: manual as below:
1) Launch Files app, taps SearchView EditText
2) switch IMEs with IME switcher dialog
3) see if Password keyboard shown.
4) keeps 2) and 3) several time.
Expected: There is no password keyboard and
the keyboard input is still workable.
Change-Id: I68bb95fc3cbfe1f5992ccf87694b34c3e52bb31f
This helps us to debug.
Bug: 154056280
Test: Locally make leashes invalid and check the log format.
Change-Id: Idcde497ffee1f10a4289520e154aa8b39eed1f78
* For now filtering is not implemented for inline augmented autofill
suggestions. So before this change,augmented autofill inline
suggestions are displayed in the IME, and user starts typing, it's
up to the IME to remove the suggestions.
* After this change, any text view value change event will be sent to
framework autofill manager service, which will be used to hide the
existing augmented inline suggestion.
* Caveat is that this may be less optimal for text heavy fields, such
as the email compose field.
Test: atest CtsAutoFillServiceTestCases
Bug: 153765306
Change-Id: Id7387c3ef0aa0379cfe846ea0ca0b9033b67ce01
Capturing the answers to some questions I received today in-to
source-code comments.
Bug: 153756455
Test: Comments only
Change-Id: I208ca0370267803bf546d654f5a8d4e0c25b6f11
PipTouchHandler, similar to other components in SysUI, should be in-sync
with the destination bounds calculated within SysUI rather than WM.
Fixed also the empty movement bounds upon the first call to
PipTouchHandler#onMovementBoundsChanged. Together, this change should
fix the PIP not being lifted on IME show up. PipTouchHandlerTest is
updated correspondingly.
Bug: 153352899
Test: manually enter/exit PiP
Test: atest PipTouchHandlerTest
Change-Id: I2912af2a181b7fb57c6d90751744d46c6b3366d2
It seems that there are several applications that call
InputMethodManager#windowDismissed(IBinder), which was recently
removed [1], then crash due to unhandled NoSuchMethodException
exception.
The most probable hypothesis that explains why these apps ended up
calling this method via reflection is trying to address object leaks
from InputMethodManager, which we have received reports then fixed all
the known issues [2][3][4][5][6]. There are several Internet articles
that claim calling InputMethodManager#windowDismissed(IBinder) can
*fix* such object leaks, which is in fact no longer necessary in
recent versions of Android. However, it seems that some of such apps
didn't gracefully take care of cases where IMM#windowDismissed()
doesn't exist then ended up crashing due to unhandled
NoSuchMethodException.
Note also that AndroidX Activity (androidx.activity.ComponentActivity)
already implements a similar workaround [7] hence app developers no
longer need to work around by themselves.
Anyways, in order to avoid unnecessary crashes from apps that call
IMM#windowDismissed() via reflection, this CL re-introduce it as an
empty method. As their goal is supposed to be clearing internal
fields within InputMethodManager to avoid object leaks, an empty
method is believed to be sufficient.
[1]: Ib455704fe1e9d243f93190a84f230210dbceac2a
970d9d2e0c
[2]: Iad09cf5dbb7f6f156fd39ed243431432e00f8945
4478de3c02
[3]: Iaf3fe2c065b5bf91e49a729ba46262114bb6da88
b13f015ab5
[4]: I219394178e4172bc47864297f1418e677dba25e5
5f05965f54
[5]: Id6afc8fc64512225578c62557b96c7dc2e969adf
0f3a99d837
[6]: I8fabb30f14bcb2cd7019e29b6642b4562d49d248
dff365ef4d
[7]: I615e92f0c64b6d668b31f2c83527b7409a7bef6f
b1bf8502e0574a4bfcf450235595372b7cb3778a
Fix: 152261618
Test: manually verified with apps in question
Change-Id: I599896a96267fc60a738eac31be02b770e10dff3
