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
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
