JNI calls aren't free and we don't need to burn one
to call update with the values we just passed in.
Bug: 152501005
Test: Existing tests pass
Change-Id: Iaf272edb03d4ec195b75e9ef7e6c122604025dcb
This error showed because DecorContext uses application context
to get WindowManager. This CL changes to use PhoneWindow to obtain
WindowManager instance. Also refactor ctr to obtain context from
PhoneWindow.
Bug: 152806048
Test: manual - enable strict mode and check the error log not shown.
Test: atest DecorContextTest
Test: atest MemoryTests#testActivityRecreation
Change-Id: I1d416b9cdb015c9bc3553571041f3b14bb9da5da
CL[1] intends to reset served view and restart input state when focus to
the next window, which the main idea is try to make the lifecycle of the
input connection can more aligned with the window focus change.
However, this behavior change unexpectedly breaks Gboard
TranslatesUIExtention that will closeExtensionView when
onFinishInputView -> onDeactivate called, while launching language
selection dialog.
Remove the reset logic as the lifecycle of input connection still
needs to break down.
[1]: I8d4fff94ba9313b773bc27fcbd019cc88580d3e9
Fix: 152373385
Test: To make sure not break Bug 148489857 and Bug 148788569, following
auto / manual test to verify:
- Auto: atest FocusHandlingTest#testKeyboardStateAfterImeFocusableFlagChanged
- Manual:
1) Build / install EditTextVariations
2) Select menu -> Direct-Reply, make sure Notification comes up.
3) Tap EditText on Notification, verify soft-keyboard is visible.
Change-Id: If20cdb43ecd013c330c5e16c73e9af972bd89f33
1. Avoid a seperate IPC querying in to system-server
to initialize the mUseBLAST flag.
2. Avoid calling property_get_bool with each BufferQueue
creation.
Instead we piggy-back both values inside addWindow return values.
Bug: 152501005
Test: Existing tests pass
Change-Id: If130560a8230f8d399cf7631264d551522939faa
Add test to verify that requestedVisibleAwaitingControl starts
animation. This is followup test for comment in commit
I958fc5747382109aa2f21bc1067a28746e7242d8
Bug: 154440912
Fix: 153577930
Test: atest ImeInsetsSourceConsumerTest
Change-Id: I08db27151605ac53b0575b08343b5a75dc2e5fc2
* 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).
This sets the most-recently created view on a shellroot
to be used as the "accessibility" window. This allows
each shellroot to have 1 window that accessibility sees.
Bug: 152368950
Test: atest AccessibilityWindowQueryTest#testWindowDockAndUndock_dividerWindowAppearsAndDisappears
Change-Id: Ice2820e11544ccdf7a3e600f918eac0ffb506548
@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
