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
IncrementalService can create the library files beforehand, but
delay filling in their data. As it takes quite a while in
general (over a second in cases when the phone is busy), it's
better to run the unzipping and filling in a separate thread
and only make sure it finishes before the whole installation
process is complete.
This speeds up the megacity.apk installation by ~250-300ms,
1000-1100ms -> 750-800ms
Bug: 153513507
Test: adb install megacity.apk
Change-Id: Ia44f7e45b9e0abaebdfb6fe5352f9dcf29ab4ece
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
- If the task is previously not visible or has no visible children at
the point when we start controlling it in the task org, hide the task
until we send taskAppeared to ensure that the task org can reparent
and show it otherwise we could see a flash of the task.
This happens mainly from two cases:
- when starting a new task with a given win mode, we show it and wait
for first draw before notifying the task org
- when transitioning into pip from swipe up, the activity is hidden
and when it requests to enter pip is made visible again
Since we are hiding the task w/ the pending transaction, we also need
to defer all task org callbacks until that's applied to ensure proper
lifecycle of the calls.
- Also skip app transitions for task org tasks for now
This reverts commit d2fb07e4f6.
Bug: 152809695
Bug: 152134460
Test: Open a bubble, ensure that we don't see the task in fullscreen
first. Enter pip, ensure that we don't see flash of the task
before SysUI can fade it in.
Test: atest PipAnimationControllerTest
Test: atest TaskOrganizerTests
Test: atest SplitScreenTests
Change-Id: I9f1fc5931df1d69a7086c02b633347162cda94bf
This exposes errors directly, which mirrors what PackageParser
used to do. Just a leftover TODO from the refactor.
Bug: 153472626
Test: manual install broken APK and check the error is logged
Change-Id: I06804ad7396196e28ce2177a671d4eef3958e1d6
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
