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
Fixing a typo in the previous commit: s/remove/put/
Bug: 153013604
Test: ran CTS tests on sdk_gphone_x86
Change-Id: Iabe8ce51f38ac921aa5cc0e78b559e4a512b9273
In quick switch flows, launcher will first swipe task snapshot
through recents animation, and then start new task with custom animation
options through startActivityFromRecents after gesture finish detected,
and then finish recents animation finally.
But that way user may experience flickering before the new task launch
and recents animation finish.
To improve quick switch flickering, we ignore the new task's custom
animation from recents and generate task remote animation target,
and then trigger a callback for launcher to control/animate this
task surface, more like a part of RecentsAnimation,
Also, adding removeTask method for launcher can flexibility remove the
new task animation target once no need to animate, so that launcher
can decide when to finish recents animation.
Bug: 152480470
Test: manual as below steps:
1) Doing quick switch task.
2) Make sure launcher can receive onTaskAppeared callback.
3) Make sure launcher calls removeTask successfully.
4) Make sure launcher can finish recents animation after 3).
Change-Id: I0692a280a49719229fa8871509bad37a1343a00f
This will be used by FlickerTests to capture composition state
in SurfaceFlinger trace.
Test: atest FlickerLibTest:LayersTraceMonitorTest
Fixes: 153563549
Change-Id: I3d09196ced43a1b0bac811e8f458c28be4e44992
As the final enabler for the BLASTSyncEngine, we add a new relayout
result BLAST_SYNC. If the WindowState is participating in a BLAST sync
during relayout we return it to the client. If we return it to the
client the client will direct it's next draw in to a BLAST transaction
and report that transaction via finishDrawing. You can now observe
the BLASTSyncEngine working end to end in TaskOrganizerMultiWindowTests.
We do a few small clean-ups in TaskOrganizerMultiWindowTest while we
are there.
Bug: 153561718
Test: TaskOrganizerMultiWindowTests
Change-Id: I719b731350b942aafa444a33972aaef8973422ea
The root causes of this issue are:
1. WindowTokenClient#attachContext makes WindowTokenClient has strong
reference to WindowContext, which leads to WindowContext cannot be
GC'd.
2. WMS#removeWindowToken needs MANAGE_APP_TOKEN permission which
normal apps don't hold.
This CL does following things:
1. Use weak reference instead on WindowTokenClient#mContext.
2. Relax WMS#removeWindowToken to check callingUid if
MANAGE_WINDOW_TOKEN permission is not held
3. Deliver config changes to the client side in
WMS#addWindowTokenWithOption
4. Some minor fixes
fixes: 150812449
Bug: 150715095
Test: atest WindowContextTest
Test: atest WindowManagerServiceTests
Test: atest WindowTokenTests
Test: atest WindowManagerPermissionTests#testMANAGE_APP_TOKENS
Test: atest
WindowManagerPermissionTests#testADD_WINDOW_TOKEN_WITH_OPTIONS
Change-Id: I9f1d73af2abb78fc9844e6d9eb25e9f0293514e7
Support addWindow with the other userId which can be different from Uid.
This can be used when client want to addView for secondary user.
Example:
1. Create context with createContextAsUser or similar method.
2. Get WindowManager with this context.
3. WindowManager#addView
Bug: 151414297
Test: atest WmTests WindowAddRemovePerfTest AddWindowAsUserTest
Change-Id: I13e58d76b1f056f3829bc984c2b61496c8f8d535
Add a comment explaining the permissions necessary for a successful call
to acquireFrameRateFlexibilityToken(). This is feedback from a
previously submitted CL.
Change-Id: Id316e6943153c20a06d90af844605851591e225c
Bug: 148033900
Test: n/a
