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
When leash changes, we need to re-apply our local state, to ensure
new leash has same state as before and new leash is visible on
screen.
Test: Switch IME while open
Test: SurfaceControlTest
Fixes: 152876819
Change-Id: Ieae1aecdc3ddc427ccb89c4aa7ef7ae9283f39eb
A window might request to control insets before it is added to WM and
expect the first dispatched WindowInsets as requested.
The first insets state returned from addToDisplay or relayout might be
not expected if the window just become thecontrol target in the
function.
With this CL, WM can return controls from addToDisplay and relayout, so
that the client can apply controls immediately, and update controlled
insets sources before dispatching the insets to the view hierarchy. This
enaures the insets dispatched are up-to-date.
Fix: 150756571
Test: atest WindowInsetsControllerTests RelayoutPerfTest
WindowAddRemovePerfTest
Change-Id: Ib78c24beb7af5a54ad78935c3ddb260ef9645212
This reverts commit 8c56ac6b94.
Underlying issue has been fixed:
Test: InsetsControllerTest
Bug: 152071027
Change-Id: I2b80de7067bf688a6b36233b9a1e92e2cf31c148
Add support for temporarily relaxing frame rate restrictions in surface
flinger. This is used by CTS tests to get a consistent device state
while running frame rate tests.
Bug: 148033900
Test: - On a Pixel 4, I turned the brightness down and covered the
ambient light sensor, causing the display manager to set a frame rate
restriction. I ran the frame rate CTS test without these CLs applied,
and confirmed the test failed because surface flinger couldn't switch
frame rates, as expected. Then I ran the tests with the CLs applied, and
confirmed the tests pass.
- I confirmed that, without adopting shell permission identity, the CTS
test is denied the request to acquire a frame rate flexibility token. So
normal apps won't be able to access this.
Change-Id: Ie2b611cf5726c14a7a22e315a85bf6200d190682
If BLAST is enabled and we somehow end up in positionLost or
setParentSpaceRectangle without having called setUseBLASTSyncTransaction
we will end up putting operations in to a Transaction which will never be
applied. This condition should be considered a bug, but it's best to
defend against it. To compensate, rather than checking the global
use BLAST flag, we check if the current draw is actually using
BLAST.
Bug: 152663327
Bug: 152780239
Test: Existing tests pass
Change-Id: I3c05b83400b59be82a339933fc8ef1382d4f0e21
If visibility changes we will try and hide the Surfaces from
the RT. We want to sync this with ViewRoot drawing so
we enable BLAST sync for the next frame in this case.
Bug: 152663327
Bug: 152780239
Test: Existing tests pass
Change-Id: I9cd157954a3ce87a8f95a7be97d6d5c7f324327b
When we call mSurface.transferFrom(getOrCreateBLASTSurface()) we
always end up incrementing mSurface.generationId, because
BLASTBufferQueue.java::getSurface will always return a new native
wrapper object. We had a similar situation with
mSurface.copyFrom(mSurfaceControl), and had to build IGBP
comparison in to the native method. Here though, it's easier
to just rely on the stability of the Surface (never changes
for the lifetime of the BLASTBufferQueueAdapter) to avoid
duplicate calls to transferFrom.
Bug: 152501005
Test: Existing tests pass.
Change-Id: I64b9a6ae3cabfa75974e040460638417bfac6845
Currently every call to getOrCreateBLASTSurface produces a transaction.
This transaction has two parts, both of which can be eliminated:
1. The first is the reparent. This was written when the
client allocated the BLAST SurfaceControl, but now the WM
allocates it and it has the correct parent to start, so
we can just eliminate this.
2. Showing the surface. We can eliminate this by just showing
the surface by default.
Bug: 152501055
Test: Flip BLAST flag. Play.
Change-Id: If6e28e9153a09909fb3bb061980deb82c132dd5a
