WindowContext relies on WindowTokenClient#onConfigurationChanged after
calling WMS#attachWindowContextToDisplayArea.
However, it took some time to wait for onConfigurationChanged callback
from the server side so that we may get a stale value right after
creating WindowContext.
This confuses developers especially when the foreground activity is in
size compat mode or freeform because the process config is overridden
by activity's config.
This CL makes #attachWindowContextToDisplayArea return DA's configuration
and applies to WindowContext direcly.
It also benefits WindowProviderService because it can obtain DA's
configuration before onCreate() based on [1] and this CL.
Bug: 190019118
Bug: 190745506
Bug: 198298520
Test: manual - 1. launch an Activity in size compat mode
2. create a WindowContext and verify if WindowMetrics
matches DA bounds.
Test: atest WindowContextTest WindowContextTests
Test: atest WindowContextControllerTest ContextGetDisplayTest
[1]: dd4a748af0
Change-Id: I8dd3987b731662502bc01e9d2ed67e718ada5f46
This CL aims to optimize the previous CL[1] to schedule removing
tasksnapshot after a fixed timeout according the tasksnapshot:
- With IME snapshot: 350ms
- Without IME snapshot: 100ms
As the previous approach has some cons espically when the tasksnapshot
has IME shown:
1) It lacks a signal or callback to notify WmShell to dismiss
tasksnapshot when IME is actually drawn on the task and always
dismissed after the timeout.
2) The timing to schedule tasksnapsit removal is when
ActivityRecord#onWindowFirstDrawn, which is much eariler than the
window focused (about 100-150ms), and it may easier to see flickering
when the task is showing IME.
The reason is that IME is drawn after window focused and started input
connection. Also, starts from R, IME insets visiblity
is handled by the app's UI thread, so if the schedule removal timing
been triggered too early and if IME / App takes more time to handle IME
surface layout, then user might aware the app task flickering when
tasksnapshot dismissed, since IME is not yet be drawn and then it
show up again when the next layout finished.
In this CL, we made the following changes to improve the above cons
- Postpone the schedule removing tasksnapshot (with IME) timing to
after the app task has focused.
- Modify the tasksnapshot removal timeout (with IME) from 350ms to
450ms (with renaming to MAX_DELAY_REMOVAL_TIME_IME_VISIBLE),
in case some edge cases may take longer time to process IME layout.
- add ITaskOrganizer#onImeDrawnOnTask(taskId) to notify the shell
task organizer to properly remove the tasksnapshot without waiting
until the max timeout.
[1]: I7865e17b57961e12a0cdcf068e412195123a6ec7
Fix: 192065018
Test: ateset StartingSurfaceDrawerTests#\
testRemoveTaskSnapshotWithImeSurfaceWhenOnImeDrawn
Test: manual tests by
1) launching Android Message with focusing an editor
2) swiping out to home and launch another apps (e.g. chrome)
3) swiping up to overview, tapping Android Message task
4) verify if IME is flickering after switched back.
Change-Id: I81031f64966b1aeb55cc09f381d4d83ec3460dc9
The top activity in TaskActivitiesReport can be filter out if the state
of top activity is INITIALIZING, this doesn't make sense for splash
screen, because the state of the top activity do can be INITIALIZING.
Create a filed targetActivityInfo in StartingWindowInfo to specify the
starting activity info.
Bug: 193459277
Test: atest SplashscreenTests StartingSurfaceDrawerTests
Change-Id: Ifec7aff644013a0426e0622162ab24f6b9fb3d8f
Security report shows that this can cause leak token of different app.
Replace the functionality with a callback to the TaskOrganizerController
to restart activity when size compat restart button is clicked.
Bug: 186776724
Test: manually verify the restart button still works
Change-Id: I097b9f02e8435e6765695b9d5a531a4e165bac66
Merged-In: I097b9f02e8435e6765695b9d5a531a4e165bac66
For apps opted out of the new splash screen, we show the full background
drawable.
Ensure there has send the splash screen background color to
StartingWindowListener.
Bug: 182880656
Test: manual set useLegacy to true then verify legacy splash screen.
Test: atest WmTests:ActivityRecordTests
Test: atest StartingSurfaceDrawerTests
Change-Id: Icf662f3c5f368f447e718f82f78dc25b909ca9be
When create view with Context, there will also load some view
attributes from the Context and pre-set to the View object, to ensure
the splash screen view not affected by those attributes, clear padding
and background after create those view objects.
Bug: 191339594
Test: manual launch several apps from Launcher/Notification.
Tets: atest SplashscreenTests
Change-Id: I05be9c296a04cd49a0896ad8aef57643720d60ce
The SurfacePackageViewHost was never release, leading to a leak of its
surfaces.
This CL ensure it is released:
- Directly in the shell if the SplashScreenView was not copied
- From the client, through the window manger and then to the shell if
the splash screen was copied in the client process
Test: Manually tested with app setting by checking if the surfaces
are actually removed (winscope + logs) in the following scenarios:
- When the application registers an OnExitAnimationListener
and calls remove(),
- When the application registers an OnExitAnimationListener
and dies without calling remove()
- When the applicaiton does not register an OnExitAnimationListener
and the shell removes the splash screen
Bug: 189759180
Change-Id: Ib68bfffad6720911368739d7dd87d8a03034c589
Let empty-style splash screen do reveal animation.
Also remove the extra animation duration if the icon is empty.
Bug: 190695897
Bug: 190695665
Test: manual
Test: atest SplashscreenTests
Change-Id: I8b3b52369c12fbddc32af8c40f37650cc84a88dd
Provide a method ActivityOptions#setSplashscreenStyle to specify
splash screen style if needed.
If not set, the default option will be empty-style splash screen, so
without any other change, the activity launched from systemui with
ActivityOptions will become empty style splash screen.
Bug: 188023621
Bug: 189293785
Test: manual test start application from Launcher and Notification.
Change-Id: I299320db8f32fbd835c7ec0acaad3df3486a13f5
If the splashscreen uses an animated icon, we need to display it in a
surface view to avoid any jank if the view is passed to the client.
Test: CtsWindowManagerDeviceTestCases:SplashscreenTests#testHandleExitIconAnimatingActivity
Bug: 181757194
Change-Id: I7e2745a68626849374f5ebb9011c2e8c3b3b92c3
The generic rule to showing an empty splash screen is that if an
activity is launched from another visible activity besides Launcher.
So with this rule, when prepare the starting window for a launching
activity, we can tracking where the source activity comes from and
whether it has show splash screen or has drawn window before.
This can solve the inconsistent launch sequence when launching an
activity from non-system surface for the status either new task or
new process.
There will show an empty style splash screen if the launching
activity was drawn or it has show splash screen before.
Another coner case is that a process could start a new activity from
service, for the better UX we should also check whether there any
existing activities which were from the same process or same package
and has already at foreground.
We can still add "show icon_style_splash_screen" flag in the future.
Bug: 185433040
Bug: 185567723
Bug: 185448781
Test: atest SplashscreenTests ActivityRecordTests
Test: manual test
Launch browser from -1, empty splash screen
Launch calendar from launcher, icon splash screen
Launch work app from Settings -> Notifications -> Calendar show empty
splash screen
Launch Settings -> System update show empty splash screen
Launch Dialer -> call out -> show empty splash screen on InCallActivity
Change-Id: Id84f1f69de6c5e3f1c21cd249c62404958410193
The legacy icon on the splash screen should looks similar to it shows
on Launcher, a circle background wrap the icon bitmap in the center.
Bug: 182883560
Test: atest SplashscreenTests
Change-Id: I994f516bb7b5b1231ff9e5bb02a3a92aa5113a84
Since the width/height of the SC should not be used anymore,
we'll use the pre-resize bounds to scale the surface before
animating the crossfade.
Bug: 186669773
Test: Enter PIP in seamless resize demo, resize with seamless
turned off uses a crossfade animation with the correct size
Change-Id: I1405be9208ac9e7cc34283e3d97dc431f0cb643c
- Switch from PhoneWindow to FrameLayout
- Ensure the Action bar is not shown on the splashscree
- Do not show the contrast scrim under the system bars
- Use the latest insets API to layout fullscreen
Test: Updated CtsWindowManagerDeviceTestCases:SplashscreenTests
Bug: 181852475
Bug: 184941669
Change-Id: Ifc04bd2227394415cc74c20d2974f4726ec9c789
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
- Add a temp flag persist.debug.enable_reveal_animation so user can
enable reveal animation.
- Remove icon shift animation.
- For shift up animation, use AnimationAdapter to capture the surface
control and pass to Shell, then cancel the animation when
WindowState#removeIfPossible for starting window.
- Fix the flicker test fail issue caused from shift up animation, the
surface control should be release after the last frame was commit.
- Use SyncRtSurfaceTransactionApplier to synchronize the shift-up
animation, and use vsyncId to ensure the transaction doesn't applyied
too early.
- Do not play reveal animation for empty splash screen.
Test: atest SplashscreenTests StartingSurfaceDrawerTests
Bug: 183004107
Bug: 182815506
Bug: 184830058
Change-Id: I4fc8456633b3f4ecd69b168e0222915945210426
Add window container transaction APIs to indicate launch root for task
launching with FLAG_ACTIVITY_LAUNCH_ADJACENT. If launch adjacent flag
root is available, consider to launch to its adjacent task if the launch
is coming from the same root task.
Fix: 169271875
Test: atest WMShellUnitTests
Test: atest TaskDisplayAreaTests
Test: manual test FLAG_ACTIVITY_LAUNCH_ADJACENT behavior with adjacent
root.
Change-Id: I1716aaa48745d2c32cd413c8eac0b1d17810f0de
Add 2 cases with rotation change:
(a) Enter PiP from fullscreen.
http://recall/-/d6GxE5mVL8Ww2IPnx7Nk0o/hDfmdrhrBFjJNOdi1s66OW
(b) Launch fullscreen app with the existing PiP.
http://recall/-/d6GxE5mVL8Ww2IPnx7Nk0o/bUpHZ6Sh98zKZJnRM7oFy9
Steps of (a):
1. Task#setWindowingMode to PiP. If the next fullscreen activity
will change display orientation, start fixed rotation on it.
And start deferring orientation change.
2. PipTaskOrganizer#onFixedRotationStarted is called to mark it
will be a special case.
3. PipTaskOrganizer#onTaskAppeared is called and starts the PiP
rotation animation by animateResizePip with rotated destination
bounds from rotated DisplayLayout.
4. When onPipAnimationEnd, use WCT#scheduleFinishEnterPip to notify
that the animation is done, so the deferred orientation change
can continue to update (PinnedTaskController#setEnterPipBounds).
The end transaction of animation (reset matrix) is deferred
until fixed rotation is finished. Also freeze the PiP task
configuration one time, to avoid extra configuration change
(letterboxed) by rotation change.
5. The seamless rotation starts, the PiP surface is transformed
to previous rotation based on the bounds of previous step. So
the PiP task can show the same orientation as rotated display.
The frozen flag of PiP task configuration is cleared.
6. PipTaskOrganizer#onFixedRotationFinished is called. The final
PiP destination bounds and the deferred transaction of step 4
will be sent to WM.
Steps of (b):
1. Fixed rotation happens (PipTaskOrganizer#onFixedRotationStarted)
when there is an existing PiP. Apply fade-out animation.
2. PipTaskOrganizer#onMovementBoundsChanged is called to update
rotated destination bounds.
3. PipTaskOrganizer#onFixedRotationFinished is called to apply
fade-in animation with new bounds.
Other changes:
- WCT#scheduleFinishEnterPip was used to set bounds and notify
windowing mode change. That is already done by other config
change oepration of WCT. So this redundant operation is changed
to be a signal to notify that the PiP animation is done.
- Ignore calculating letterbox bounds for PiP activity because
it should fill the task.
- Add PinnedTaskController#DEFER_ORIENTATION_CHANGE_TIMEOUT_MS
to avoid using alpha animation after swiping from any task.
- Consider source rect hint with rotation.
Bug: 165794724
Bug: 175836469
Test: DisplayContentTests#testFixedRotationWithPip
PipAnimationControllerTest#pipTransitionAnimator_rotatedEndValue
Change-Id: I2c26b5d93996193caaf020bd0e2314c8e1789545
By default, the SplashScreen uses the manifest theme.
This API allows user to change the theme used for the splashcreen for
the whole application.
Test: atest CtsWindowManagerDeviceTestCases:SplashscreenTests#testOverrideSplashscreenTheme
Bug: 185109768
Change-Id: I64e24910f6529a0ea2867b67d7e5963b971164b4
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
- Pass TaskSnapshot to Shell directly.
- Parallel process: create a splash screen worker thread to create the
splash screen view and pre-draw the icon drawable, and use splash
screen thread to do stuff about window's lifecycle like add/remove
window. We don't use shell main thread here so the starting window
won't blocking any task execute on main thread.
- Trigger addStartingWindow directly when startActivity, also
removeStartingWindow directly without post the animation thread.
- Do not defer addStartingWindow for prepare surface, on the contrast
it should be execute before prepare surface.
- Remove ActivityRecordTests#testAddRemoveRace, it wasn't been test as
expected because in original logic the add and remove starting window
are post to animation thread, so the test was actually testing on
handler#postAtFrontOfQueue and handler#removeCallbacks.
For now it will only cause OutOfMemoryError.
Bug: 183665220
Bug: 182836977
Test: atest StartingSurfaceDrawerTests SplashscreenTests
Change-Id: Ie9a529c7d81f07f923394eb69944518f3e9010ce
A Window Provider Service is a Window-Context-like Service which handles
UI
components and is able to obtain the latest configuration.
The differences between a Window Context and a Window Provider Service
is that:
1. It is always associated with the primary display before
attachWindowToken() or WM#addView is called. It is suggested to
render UI
components after calling the APIs mentioned above.
2. A window context registers the listener in constructor and
unregisters it in finalize(), while a window provider service
registers the listener in onCreate() and unregisters in onDestroy().
3. Like the API Context#createWindowContext(int windowType, Bundle
options),
the users of a Window Provider Service need to override
provideWindowType and
provideOptions to pass the attributes.
4. When there's a configuration updates from the server side,
the Service#onConfigurationChanged callback will be invoked.(TBD)
It is suggested to use window context when possible. This class is to
migrate the
Service to show UI components to the window context concept. We can't
migrate them
to WindowContext directly because developers are used to use this kind
of Service as
the container of UI components and may change its property at runtime.
An example is that keyboard developers may apply a new theme by
InputMethodService#getResources#setTheme(newTheme).
Bug: 159767464
Test: atest WindowContextTests#testWindowProviderServiceLifecycle
Change-Id: I7d537fd2d128efa28aa6e771d77aa105fb497672
This CL instroduces WMS#attachWindowContextToWindowToken
and the corresponding API in WindowContextController to make
WindowContext able to associate with a WindowToken.
Test: atest WindowContextControllerTest
Test: atest WindowManagerServiceTests#testAttachWindowContextToWindowToken*
Bug: 159767464
Change-Id: I807a67fba149cbdc4267442bab0b64e6a95bd4b5
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
The non-activity window should be managed by the application itself.
Framework side doesn't need to handle it.
Also apps may remove the view after WMG#closeAll and cause
IllegalArgumentException "not attached to window manager".
Test: atest WindowContextTest
Test: atest WindowContextTests WindowContextPolicyTests
Bug: 183251523
Change-Id: I15ccb9a129f541f3be9733e8cd6121bb4c0fd6b8
Add a condition when launch activity from continuous package, consider
to show a blank splash screen since the activity might start from an
existing task, showing an icon on it might seems strange to user.
Bug: 183150443
Bug: 183108088
Test: atest StartingSurfaceDrawerTests ActivityRecordTests
Change-Id: Ia76648c291d602302725a1814991971a1d544549
- Add @UiThread on SplashScreenView:remove
- Add @UiThread on OnExitAnimationListener:onSplashScreenExit
- Add an API SplashScreen#clearOnExitAnimationListener, also update
some comment for SplashScreen APIs.
- Remove "millis" from getIconAnimationStartMillis and
getIconAnimationDurationMillis
- Return java.time.Duration for getIconAnimationDuration
- Return java.time.Instant for getIconAnimationStart
Bug: 182997416
Test: atest SplashscreenTests
Change-Id: If07252cc4b554dcde0c5dc4c4dec3f242ee47ae7
This enables launching multiple tasks (recent tasks)
within one transaction simultaneously with configuration and
hierarchy changes.
Bug: 182002789
Test: WindowOrganizerTests#testStartTasksInTransaction
Change-Id: Ic297eeae52e833286e7feede73d91354a5394e7c
Take the full transaction details passed from Launcher, including
position / windowCrop / scale / roundRadius and apply them in
RecentsAnimationController.TaskAnimationAdapter#onCleanup to make sure
the final state of autoEnterPip transition can be carried over.
Note: there are still several frames off when entering PiP from
landscape with autoEnterPip being enabled.
Bug: 179720719
Test: manually using the ApiDemos app
Change-Id: Ibfff75e09943960cfcd816d6c52a80d7a8af8fe8
