- Fixed the round corner radius calculation, take into account the
insets, was applied to the destination bounds side
- Adjust the leash position based on the insets
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/eUpkH2il1vYBVBPt1Vks2u
Bug: 190748719
Test: auto-enter-pip from YT landscape, see video
Change-Id: I2f3f4ae807630c5ae6bcc9968c6b46cf4501ad07
Support a custom configuration while beginning the instrumentation, also
support a custom tag for getting fine-grained CUJ in the trace.
Bug: 187495856
Test: take the trace, see the cuj section name.
Change-Id: Ife2554e0d7dbe4c01b7e4381a12a5f595e2f4364
If an application caches an ApplicationInfo and uses it to call
Context#createApplicationContext, the app will not get the most recent
version of the overlays for that application. To make things worse, the
LoadedApk stored in ActivityThread#mResourcePackages is updated using
the old ApplicationInfo causing further uses of the cached LoadedApk to
return outdated information.
Deprecate Context#createApplicationContext, convert all internal uses
to Context#createPackageContext(String packageName, ...) and log
whenever any one calls Context#createApplicationContext with an
outdated ApplicationInfo to detect debug issues in using old infos.
Bug: 188059515
Test: change wallpaper and observe widgets get reloaded with most
recent overlays
Change-Id: I2aeefa8c0e66264859109975a54c4f73f76ad710
To see this in action, enable the remote animation (adb shell setprop persist.wm.enable_remote_keyguard_animation 1) and enhanced SmartSpace (adb shell device_config put launcher ENABLE_SMARTSPACE_ENHANCED true). Also, set your lock mode to swipe or some sort of non-bypass biometrics, so you can swipe to unlock.
KIs:
- It looks pretty janky on a fast swipe - this is the same root cause as b/186847064 so will have the same fix
- Launcher animates in with window-level animations (Launcher team is looking into helping)
- Screen off animation is not yet implemented (this is for unlock only)
Bug: 187025480
Test: unlock with every possible permutation of lock settings
Change-Id: I8c186fe57132ebc9a0bc5e3d8785e753e72c3bf2
In live tile mode, the live tile app is considered the top window and therefore rotation proposals are sent even when home rotation is disabled. To detect this, launcher needs to send over home rotation state, besides the nav bar needs to listen to recents animation state.
Fixes: 185962767
Test: manual
Change-Id: Ibc873d1067a8a3b37b6c20672cdb32ea356d9f21
Android S introduces a new Quickstep animation for launching an activity
from an app widget. This is a similar but distinct CUJ to
LAUNCHER_APP_LAUNCH_FROM_ICON.
Bug: 169042867
Test: presubmit
Change-Id: I3338d31eb2ed74aef0b0697c6070ab7b422514ba
- Launcher will create a new surface which is faded in over the app,
and as it finishes the recents animation, we transfer the overlay
from the leash to the task (as with the transform), and when the
pip task organizer receives it, it can fade out and remove the
surface
- Fixes flash of status bar colors when going from light status bar
to home (dark status bar) by deferring whether a task affects the
sysui flag until it enters pip (only for autoenter)
https://recall.googleplex.com/projects/e3f080d7-2818-43f0-a087-405000b8fdf5/sessions/971a84c8-a622-4b34-a9de-4e595595da42
Bug: 184703546
Test: Swipe up from app with auto-enter but no source hint rect
Change-Id: I0a00cdb98d0a599ef065206e0cd2cfc0e6cc72b1
The window magnifier is hard to drag when it is at the bottom
of the screen. This is due to that launcher is detecting
swipe-up system gesture.
To fix it, we set the system ui state flag to true when
the window is overlapped with the gesture detection area.
We also update the gesture dection area via OnApplyWindowInsetsListener
Once the area is changed, we will update the flag again if necessary.
In the testing part, we use real WindowManager to verify the
functionality.
Bug: 179648683
Test: atest com.android.systemui.accessibility
manually test and use the following command to check the flag
adb shell dumpsys activity service TouchInteractionService
Change-Id: Ia09bd26b3eb164790614c173594d997d45f4ecdc
For auto enter PiP from landscape when no source rect hint is specified,
we should actually use the skew instead scale values to set the matrix
transform.
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/dpLVOQzIVjdJpn5kg7T4Fc
Bug: 179720719
Test: manual use ApiDemos app, see video
Change-Id: Ic7072e8354329584f9cb75876911c3d58d78e7f5
Currently, SurfaceFlinger/BLAST doesn't provide any mechanism
for syncing across processes or any way to even know that a
particular transaction has been applied (exascerbated by the
fact that the transactions are queued up on the buffer queue).
This means there is always a race between when the last
launcher transaction is applied.
Until we get a solution, we add an extra leash so that launcher
doesn't actually modify the organized surface.
Bug: 186132704
Test: using winscope, observe that launcher animates leashes
instead of the actual task surfaces
Change-Id: I53834fc434a33abd912ebd9edc06fc8c9bbf2e2f
Per discussion, will keep the two classes in Launcher and WMShell as for
now and re-address the unification in next release. In this change
- deprecate config_pipEnableRoundCorner since it's now behind a system
property and waiting to be turned on
- pass the corner radius value from WMShell to Launcher
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/dmUy8qBEMxHShFcFKB3cT3
Bug: 171721389
Test: make sure autoEnterPip has round corner support, see video
Change-Id: If978ee6c3b0307a7423fe51b996f535d7009e74c
If an incoming transition merge request contains only a task
open, this will be converted into the existing onTaskAppeared
callback that recents expects.
Bug: 186132704
Test: open app, swipe to overview, scroll to another app, launch.
Change-Id: Ifd288fbb73e2b4ea7011066bda5c3694b5f579d9
Shell Transitions operates on the leashes both before and
after the animation in order to adapt shell transit to the
legacy transit impls in launcher.
This means we can't release the surfaces before the finish
callback. Since the finish callback provides a convenient place
to release the surfaces anyways, we can effectively disable
the release here.
Bug: 186158221
Test: enable shell transit, physically rotate to landscape,
launch messages and then close it (back-gesture) repeatedly
and observe that launcher doesn't crash.
Change-Id: Ibdc958b1fd18d66a013d94b70772ce49409fb4c1
When autoEnterPip from Task with multiple activities, besides passing
the mLastRecentsAnimationBounds we should also try to pass the last
PictureInPictureSurfaceTransaction to the new Task and apply both.
Changed also
- deprecate the last recents animation bounds and use the transaction only
- reset the transform once applied to the original task
Known issue: original task appears transparent in overview once.
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/hNZ0H62PqgVDEUGh1TVMiT
Bug: 184789412
Bug: 185509920
Test: manual with ApiDemos, see Video
Change-Id: I7fb77e41e1963e14ecaf53bd135d6b4cb24493c9
This adds a couple things to support "merging" of transition
animations in shell.
1. Moves the finishing surface operations into a transaction that
gets sent to shell. This does a couple things: it complies with
the contract we have where during a transition, only the player
should touch relevant surfaces; and, it makes it so that the
player can merge the transaction with other ones.
2. Keeps a queue of "pending" transition animations in shell and
either merges them or runs them serially.
3. Any transition that becomes ready while another is playing will
first be sent to the playing handler to give it a chance to
"merge" the incoming transition.
There are 3 expected responses to overlapping transition animations:
1. Cancel the currently playing transition and immediately start
the incoming one. This can be achieved by having the currently
playing transition cancel itself (ie. immediately finishing) when
a merge request comes in. Then the rest of the shell transition
logic will immediately start the next transition.
2. Queue up the incoming transition to play once the current one
finishes animating. This is basically the default as long as
the current transition simply rejects/ignores merge requests
3. Merge the incoming transition. This is achieved when the
currently playing transition actually does some special logic
to handle the incoming transition. It then calls the finish
callback for the incoming transition (before it finishes its
own animation) to indicate that it has been merged (or "consumed").
Basically, any time the finish callback for a transition is
called before a pre-ceding transition, that transition is assumed
to have been merged.
Bug: 183994113
Test: atest ShellTransitionTests
Change-Id: I3cb54e221d57642306ddf15827c21d8881b014d0
- Move new matrix/rect construction to if the param is set on the
builder, we only apply the params if the flags are set anyways
and if the caller doesn't set those params then we are allocating
new objects unnecessarily
- Always recycle motion event
Bug: 183756396
Test: Take memory profile when dragging pip
Change-Id: Ie7457c8c508ee61bd27daeebe486c39a5cebe7d7
InputMonitorCompat is only instantiated directly now, so we can remove
old code for passing it from SysUi through Parcelable.
Test: compiles and runs locally
Bug: 185266621
Change-Id: I54e394c1eb9c702beeb5bbfbae7a140c29530c33
We are enabling a new lint check where the min sdk != compile sdk.
It has produced a lot of errors and adding the baseline file(s)
allows us to continue work without introducing more problems.
Bug: 150847901
Test: m lint-check
Change-Id: Ide8a8fe80ba31396f23853ab266afcbcc33af9a6
This makes StageCoordinator implement the TransitionHandler
interface.
In general, this currently expects 'enter' transitions to
contain 2 tasks (one in each split). The current UX is undefined
when one only one of the splits is occupied, so for now it will
throw an exception if that case is hit.
There is a split-screen API called startTasks which takes a list
of tasks (currently only supports 2) and associated options and
creates a transition to both enter split-screen and launch those
tasks into their respective stages.
These are the currently accounted-for entrypoints into
the handler interface:
- Core-initiated (handleRequest)
- in split: trigger=HOME that is opening -> full dismiss.
- in split: trigger=task with a stage parent that is last closing in
that stage -> dismiss with other stage onTop
- NOT split: trigger=task with stage parent -> exception
- Shell-initiated
- NOT split: startTasks -> enter split with 2 tasks
- in split: snap-to-dismiss -> dismiss with other stage on top
Bug: 182002789
Test: atest SplitTransitionTests
Or use the experimental pair-launch split-screen and observe
protologs to see clean transition-infos.
Change-Id: I4f4dd431ad5642cf98b4a01c32eb1d09e5b9a11e
- Allows launcher to get the associated launch cookies for
the task
Bug: 129067201
Test: Manual, check the task info for the animation targets
Change-Id: I4b9d974af1732d0ec7b19681f4772b692f614e5e
