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
This CL extracts the logic which is going to share with
WindowProviderService. It is also the preparation to introduce
WindowProviderService.
Bug: 159767464
Test: atest WindowContextControllerTest
Change-Id: Ib5a4cc8d7853bb01bde1081af091d1069865e3a0
In this way, we can clarify the owners and it is easier to maintain.
Also refactor to move WindowContext creation logic to ContextImpl.
Test: atest WindowContext WindowContextTests WindowContextPolicyTests
Bug: 159767464
Bug: 152193787
Change-Id: I78432aa18aa97e001f5a9a04321109e456fd137b
It looks like the empty branding view was causing the underlying
view to bleed through it so ensuring that it is removed if empty.
Bug: 182708883
Change-Id: I868931768bed5b083433fd5222720724bfe3e60e
Add new API for developer to customize starting window, set a
background color behind the icon.
Also masking the AVD and icon background like AdaptiveIconDrawable.
Ref doc: go/improved_app_launch_animations
Bug: 73289295
Test: atest SplashscreenTests
Change-Id: Ibba49ecc3ca020022cf775fed302e383908be327
Remove the internal timeout to clean up the starting window, for now on
the developers are responsible for removing it.
- Also clean up some redundant members.
Bug: 181838419
Test: atest SplashscreenTests
Change-Id: Iebcccbca454eb7fda4bed637cb5866deec36cf6b
This puts display-content as another WC in a transition. It then
adds WC rotation to change tracking. If there is a rotation,
the shell-side handlers will play the transition.
This replaces ScreenTransitionAnimation, seamless-rotation, and
fixed-rotation:
ScreenTransitionAnimation implementation will move to shell.
seamless-rotation is redundant because the rotation setup is
intrinsically "seamless": it requires shell to imbue an
animation onto it rather than just doing the jump-cut.
fixed-rotation is now just a custom animation where we
counter-rotate the closing app on frame 1 and then perform
the normal open animation on the opening app.
Bug: 179270750
Test: DisplayContentTests#testShellTransitRotation
enable shell transitions and rotate the device or launch
and close apps in different orientations.
Change-Id: I4bc23b2e614ba85bf9752f62da4c3f8d0c90436d
Otherwise they get out-of-sync and sometimes AR will not relaunch
the app, but the app client will think it needs to be relaunched
Bug: 181697795
Test: app configuration tests pass.
With 3-button nav, open app in split and observe launcher
reconfigure properly.
Change-Id: Idc8d71d92d9ae107e3adb949a2137de6c08908e9
1. Register TestStartingWindowOrganizer to mock add/remove starting
window.
2. Do not show starting window if not occluded.
3. Add ReadFrameBuffer permission so Car can get TaskSnapshot.
4. Correct package path for shell.startingsurface.
5. Do not show starting window for home type.
Bug: 73289295
Bug: 131311659
Test: atest TaplTestsLauncher3
Test: atest WmTests StartingSurfaceDrawerTests TaskSnapshotWindowTest
Test: atest CtsWindowManagerDeviceTestCases
Change-Id: I89930d2e8a05cca6197c36c780ee1843fe454354
Implement default exit animation on the view of splash screen, there
will be a two layers switch happen when playing exit animation. For
the detail please reference
go/improved_app_launch_animations and go/app-startup
Note: For this version we skip shift-up animation, need to fix the
flicker test so we can enable it.
Note2: Fix the possible missing splash screen view issue, but could
make the first window draw slower, keep tracking.
Bug: 73289295
Test: build/flash
Test: check splash screen starting window.
Test: atest StartingSurfaceDrawerTests ShellTaskOrganizerTests
WindowOrganizerTests SplashscreenTests
Change-Id: I796811d010ac70f256169dd03d5e05ef0ed79d28
Create splashscreen thread with priority -10 in shell for starting
window controller, the definition is moved from
AMS#TOP_APP_PRIORITY_BOOST to Process#THREAD_PRIORITY_TOP_APP_BOOST.
Create and set SplashScreenView object on the starting window after the
first simple view on the starting window drawn, in this way the
transition can be prepare early than wait the actually view was draw,
which can save some time.
Bug: 73289295
Bug: 131311659
Test: atest StartingSurfaceDrawerTests ShellTaskOrganizerTests
Test: atest SplashscreenTests
Change-Id: Ibb430a66d6b329e74d62de047fbf37205cb66a96
