This change make the snapshot starting window holds the requested
visibilities when created from the task. Such that, when the window get
back from the background, the insets state in the window state can have
the correct visibilities.
Test: check getInsetsStateWithVisibilityOverride as described in the bug.
Bug: 196637509
Bug: 185729224
Change-Id: I54ab0791b169331c22cd89f7e6da640322bf7dd3
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]: I5fb0fa3a1e6a5e6210d3baf400a84c5892bd2e34
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
Also rename TaskFragmentAdjacentOptions to TaskFragmentAdjacentParams to
make metalava happy.
Test: build & run
Bug: 192442647
Change-Id: Iab256ce8c745635a51834f44e72493e204224f36
Placeholder activity was finished while starting the
task root activity from launcher because the task
root activity was set as singleTask launch mode.
Meanwhile, the primary TaskFragment was also removed
because of the split-rule finishPrimaryWithSecondary.
Sending the information of whether the last activity
on the TaskFragment was finished due to launch other
activity to client. So that the organizer can decide
whether the primary TaskFragment should removed.
Bug: 196179714
Test: relaunch singleTask activity with placeholder
Change-Id: I9a0369285adfbdef1edc5a7f2af944ec5b434566
The SurfaceView of the AVD icon should be create on splash screen
thread instead of worker thread, this can guarantee that the first
frame of the FrameLayout and AVD will be draw at the same frame.
And it also become faster by combining two view in same traversal
together.
Also stop the AVD animation after splash screen window removed.
Bug: 195736516
Test: verify no more Choreographer#doFrame on splash screen thread
after splash screen window removed.
Change-Id: I5942db8974f1272d9c26ac19b164312e4424be66
The FrameLayout and SplashScreenView are only used as container in
StartingSurfaceDrawer, so they do not need to be inflated by app's
context, which could be affected by app's resources.
Bug: 197936273
Test: cold launch test app and show splash screen.
Test: launch several apps to verify that everything is fine.
Test: atest StartingSurfaceDrawerTests
Change-Id: I6de444546b5dfba23fc1d7c9c4deb12787d667c5
This is in preparation for attaching some extra meta information
to remote transitions (eg. process token). Most of this refactor
just replaces references to the raw interface with references
to the wrapper class.
There is also a small refactor in RemoteTransitionHandler to
better-manage death-recipients. It is possible to have >1 filter
and >1 pendings referencing the same remote simultaneously, so
this arrangement properly handles the 1-to-many possibility.
Bug: 183993977
Test: refactor, so existing tests pass
Change-Id: Icae8f2128e0ffdf7aee51284cba106963450e3e7
Merged-In: Icae8f2128e0ffdf7aee51284cba106963450e3e7
When finishing a placeholder activity, the secondary container was
clean up, and the primary activity was also finished. However, the
primary container didn't remove and therefore was expanded to
fullscreen before the activity within completely being removed.
Which resulted in TRANSIT_OLD_TASK_FRAGMENT_CHANGE transition
after commit 118428b merged.
Bug: 198228078
Test: finishing placeholder activity and back to launcher
Change-Id: I3d55f0be8c7f6ab3970450d7b90dd95f3cfdd463
When all windows in the transition is belong to organized TaskFragments,
have the TaskFragmentOrganizer to control the animation on client side.
Bug: 196173550
Test: atest WmTests:TaskFragmentOrganizerControllerTest
Test: atest WmTests:AppTransitionControllerTest
Change-Id: I835467e23863286a5bd34380424cc9eca2c7372f
The embedded activity was destroyed immediately when being
finished because the next top activity was on the adjacent
TaskFragment and was already visible. Therefore, the finishing
animation was played before the organizer requested to
finish the activity on the adjacent TaskFragment.
Prevent the last activity of the embedded TaskFragment to
be removed immediately if the organizer requested to.
Bug: 189386466
Test: finish both activities on separate TaskFragments
Change-Id: I916eddc4dcf0de3bc7ed7264296f441d1b7bb726
Before WindowProviderService, Service can add windows with several
window types. This is previously not allowed for WindowProviderService
because a context can only associate with a window container.
However, it may cause regressions because Service is used to add
windows with multiple types.
This CL allows WindowProviderService to do so, but WindowProviderService
can only associate with the window type returned by #getWindowType.
This CL also extracts some methods to WindowContext interface so that
WindowContext and WindowProviderService can reuse the same interface.
Test: atest WindowContextPolicyTests StrictModeTest
Test: atest ContextIsUiContextTest ContextGetDisplayTest
Test: atest WindowContextTest WindowContextTests
fixes: 191959013
Change-Id: Ie16916b370a4cbb8a17ccaec9870d47b4b089390
Before, when KEYGUARD_GOING_AWAY is called before WAKE starts,it will
not be passed to the keyguard service to dimiss keyguard. Now, we
merge the flags and add check for that.
Bug: 193564917
Test: check with/without sEnableRemoteKeyguardAnimation
Change-Id: I28d40664b4fbdc0ea199baa32ccefba7dea473f8
Currently, an activity is relaunched from a resize only if
the activity does not handle SCREEN_SIZE config changes and
the new activity size crosses a width, height, or smallest
width resource qualifier. A change in activity size may also
change an activity’s screen layout. However, an activity
is relaunched from a screen layout change if it does not
handle SCREEN_LAYOUT config changes even if the screen layout
did not cross a screen layout resource qualifier.
This CL does three things:
(1) Propogates screen layout qualifiers through the same
path as width, height, and smallest width qualifiers
in the AssetManager to make it available to the
WindowManager.
(2) Prevents an activity relaunch if the screen layout
has been changed but does not cross a screen layout
qualifier.
(3) Adds tests for SizeConfigurationBuckets for the new
screen layout logic as well as for existing logic.
Test: atest FrameworksMockingCoreTests:SizeConfigurationBucketsTest
Bug: b/192369163 b/187529743
Change-Id: I41d28e6492b76c4284c4dca2c1f3f5904fc5e91a
Shell owns the whole display rotation animation now. So, we
can just provide enough information for it to decide when
seamless is requested/appropriate. The default behavior (when
not explicitly animating) is already a jump-cut/seamless, so
just skip the rotation animation if we are doing seamless
Bug: 194693472
Test: atest SeamlessAppRotationTest ShellTransitionTests
Change-Id: I64748f5910c04784fd9818818b029fa5f1339c6c
Creates and registers remote transitions that deal with situations
where keyguard might be occluded/unoccluded.
Bug: 191799478
Test: atest KeyguardInputTests
Change-Id: I625a810aef915de7a01ded9ddbe3042f0e124b52
These are needed for keyguard transitions. The ones added are:
A NOT requirement which will reject transitions with a matching
change.
The ability to match containers that aren't independent.
Checks for global transition flags as well as individual change
flags.
Match only if container is a task.
Bug: 191799478
Test: atest ShellTransitionTests
Change-Id: I963c6c91cdfc0b71a75ba9656261bb0e237f11f1
This also adds a WAKE transition type to handle situations where
a showWhenLocked activity is made visible during wake.
Bug: 191799478
Bug: 183993924
Test: atest ActivityStarterTests
Change-Id: I18f9f5a0af41766a52efd87855f6a3b074aa98f1
... to verify their behaviors in CTS
Also wraps ITaskFragmentOrganizer to TaskFragmentOrganizerToken
because we cannot make .aidl a TestApi.
Test: presubmit
Bug: 192442647
Change-Id: I848a33340449189af7d9d66a6468a9e397a0f53a
Similar to WCT#setAdjacentRoots, but can be called with fragmentTokens
in case the TaskFragments may not be created yet.
Bug: 190433129
Change-Id: I41dd515fb9722ea6e95d0c3fb040cc0d196ad78d
Test: atest WmTests:TaskFragmentOrganizerControllerTest
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
NEW_TASK flag was added by ATMS when #startActivityInTaskFragment
is called because the activity was started without source record.
Bug: 193846941
Test: starting CCT in sample app
Change-Id: Ida26034324f7ff761f1e688403d78959a01f010d
Splashscreen CTS uses its own HOME activity that gets placed
on top of the normal launcher. Prevent the launcher's remote
transition from responding in that case by adding a component
filter to the TransitionFilter class.
Bug: 194112093
Test: atest SplashscreenTests
Change-Id: Iaf4572279b84953ca20abd7e34c64d7e19700b09
Use this to implement Drag-to-split transition
BYPASS_INCLUSIVE_LANGUAGE_REASON=using existing API.
Bug: 192291727
Test: drag from taskbar into split and observe. Also,
drag same-app into split and observe no-op.
Change-Id: I710805c85c7d57ae8eebe18e5df7fca899f1b882
TaskFragmentOrganizer will be used by regular apps without the
permission to manage Task. We are allow it to apply transactions if it
is operating on TaskFragment that is organized by itself.
Bug: 193191599
Test: atest WmTests:TaskFragmentOrganizerControllerTest
Change-Id: I82e5d49260680bd496ff184c6795ec817c65d858
Migrate rotation animation in wm core to wm shell and used in
shell transition.
Bug: 190002115
Test: manual rotation the device
Change-Id: Ib3404eeb7ac647774ea3be2707c9515371ab0976
