This CL adds clearAdjacentRoots() to WCT as the “inversion” of
setAdjacentRoots().
ARC needs this capability because adjacency of the split roots
depends on the device status and it should be possible to switch
that in runtime.
Bug: 245239136
Test: WindowOrganizerTests
Change-Id: I59fb28508d56973fe4643f4c4a7deee6d29cbb4f
This CL implements a mechanism to dump the state of back navigation
in BackNavigationController to a proto buffer which we can easily
check the state while runing test case.
This also add @TestApi for BackNavigationInfo.
Bug: 131727607
Test: atest BackNavigationGestureTest
Change-Id: I8918f0b8095177578e23eb92547bd705ccfa7ec1
Before, we check if there is any split rule meeting the bounds
requirement for the given Task bounds in order to determine whether or
not to override the animation.
This can cause issue when the apps later unregister the split rules
while there is existing split. Also, this is hard to determine as we now
have SplitAttributesCalculator which can change the split state for the
same bounds.
To fix these problem, we now check if the app transition contains any
embedded activity (embedded TaskFragment that is not filling Task), to
determine if the animation should be played by the organizer.
Fix: 242051445
Test: atest WmTests:AppTransitionControllerTest
Change-Id: Ie90ba085cab3d4072f47cc3599d0494324fa39a9
WindowProviderService to broadcast configuration changes to listeners.
This is needed to allow IME to listen to WindowLayoutInfo changes.
Bug: 237342281
Test: CTS InputMethodServiceTest
Change-Id: Id8ddce5889b52859172caf3b4f0763bb5010b5dc
By making IBackAnimationFinishedCallback synchronize call, the client
app won't have chance to create a transition before core receives
onAnimationFinished, which could play the second close animation from
that transition.
Note: Shell side change can be found in ag/20459278.
Bug: 131727607
Test: monitor client won't create close transition before core handled
onAnimationFinished.
Change-Id: Iad3c70c14727d438633d804a573000f8b71b023e
... of the secondary (or the primary) container.
The primary container was removed along with the secondary container
while the last Activity in the secondary container was finished by
back event. Therefore, starting window will be shown if starting the
app again from Launcher.
However, the last Activity in the secondary container should be
considered as a relative task root if the Activity is displayed
adjacently or being a companion with the task root activity.
The task should be moved to back vs. finishes the Activities to
speed up the launch next time, like commit 2dec42fa does.
Bug: 240669850
Test: launch Settings
Test: atest WindowOrganizerTests
Change-Id: I13b33afb8602f63062f6b33742453c3e93fdfc20
Application was crashed while starting an embedded Activity with
FLAG_ACTIVITY_REORDER_TO_FRONT, because the embedded Activity was
not the direct child of the Task.
In this CL, the embedded activity is now moved to the top-most
position of the Task and dismissed from being embedded in order
to honer FLAG_ACTIVITY_REORDER_TO_FRONT.
Bug: 255701223
Test: locally verified with app
Test: atest TaskTests
Change-Id: I491139e5e1d712993f1fef9aebbd75e9ccfc539e
This commit is part of a large scale change to fix errorprone
errors that have been downgraded to warnings in the android
source tree, so that they can be promoted to errors again.
The full list of changes include the following, but not all
will be present in any one individual commit:
BadAnnotationImplementation
BadShiftAmount
BanJNDI
BoxedPrimitiveEquality
ComparableType
ComplexBooleanConstant
CollectionToArraySafeParameter
ConditionalExpressionNumericPromotion
DangerousLiteralNull
DoubleBraceInitialization
DurationFrom
DurationTemporalUnit
EmptyTopLevelDeclaration
EqualsNull
EqualsReference
FormatString
FromTemporalAccessor
GetClassOnAnnotation
GetClassOnClass
HashtableContains
IdentityBinaryExpression
IdentityHashMapBoxing
InstantTemporalUnit
InvalidTimeZoneID
InvalidZoneId
IsInstanceIncompatibleType
JUnitParameterMethodNotFound
LockOnBoxedPrimitive
MathRoundIntLong
MislabeledAndroidString
MisusedDayOfYear
MissingSuperCall
MisusedWeekYear
ModifyingCollectionWithItself
NoCanIgnoreReturnValueOnClasses
NonRuntimeAnnotation
NullableOnContainingClass
NullTernary
OverridesJavaxInjectableMethod
ParcelableCreator
PeriodFrom
PreconditionsInvalidPlaceholder
ProtoBuilderReturnValueIgnored
ProtoFieldNullComparison
RandomModInteger
RectIntersectReturnValueIgnored
ReturnValueIgnored
SelfAssignment
SelfComparison
SelfEquals
SizeGreaterThanOrEqualsZero
StringBuilderInitWithChar
TreeToString
TryFailThrowable
UnnecessaryCheckNotNull
UnusedCollectionModifiedInPlace
XorPower
See https://errorprone.info/bugpatterns for more
information on the checks.
Bug: 253827323
Test: m RUN_ERROR_PRONE=true javac-check
Change-Id: I8446f9076a45ebf7e7ffa06cb0d4ddb1001b6c00
There can be 2 reasons that we need to apply compatible scale to a
window:
1. The app doesn't support large screen. We would layout the window as
if it is on a small display. And then we need to scale its window up
to match the display.
2. We put a running app into a container that the size doesn't fit. We
need to down-scale the app so that it can fit the container.
The scaling of case 2 is also known as size-compat-scale which is fully
controlled at the server side. The client shouldn't know about it. And
this CL refines the naming.
Fix: 258393096
Bug: 254187021
Test: presubmit
Change-Id: Ifbd2ca725bed231d9e6dd8190df3dc773d4402b7
for both shell and legacy transition system.
The general sequence will be:
1. Create animation leash in core, pass to remote animation runner.
2. Remote animation finish, collect finish transaction before
transition happen. Apply finish transaction here if back event won't
trigger.
3. Check whether next transition is triggered from back gesture via
checking the open/close targets.
The 3rd step introduce another change, which to let the back transition
happen. Instead of consume next transition, we should try to find out
whether the participant was the animation target, because we cannot
assume what the opening target will do in resume stage. For example,
the opening activity could finish itself, or start another activity at
onResume, so in either case, the opening activity will become closing
activity. We can only ensure that activity will participant in next
transition.
So the more robust way should be, find out those targets which were
animated. For shell transition, and add a flag to the corresponding
change, then the transition handler can determine what to do based on
the targets. For legacy transition, ignore those targets when estimate
the transition type in AppTransitionController#getTransitCompatType.
Bug: 238474994
Bug: 131727607
Test: varify transition can be handled for some unexpected scenario:
1. launch new activity when close app.
2. launch singleInstance activity when close app.
Test: do back gesture on both shell/legacy transiton system, verify
no flicker happen whenever the back is triggered.
Change-Id: I9364be25c608f7b5797577d26b57bc7d6f2dde9c
Allows WM Shell to indicate the start/end of drag resizing, which
core can use as a signal to reuse a single (larger) surface size
for the entire drag resize operation to avoid continuous buffer
allocations after each size change.
Bug: 249808500
Test: drag resize a freeform window, verify WindowLayout requests
a fullscreen sized surface; atest TaskPositionerTest
Change-Id: I27e2b44270d7ea4f701fa8037f93b20dc691284b
There was already a way to register for an entire SurfaceSyncGroup
completing. There just wasn't a way to tell what SurfaceSyncGroup
something was added to in order to register in VRI. Therefore, add the
addedToSync argument in the readyToSync callback, allowing VRI to
register a complete callback instead of exposing a new API.
Also renamed onReadyToSync to onAddedToSyncGroup to reflect what is
happening. Renamed SyncBufferCallback to TransactionReadyCallback since
there isn't a guarantee the transaction contains a buffer.
Test: SurfaceSyncGroupTest
Test: NotificationShade Sync
Bug: 237804605
Change-Id: Ib58735cd86593a976e3f4559997316275bd82cd9
This means WMShell/Core/Launcher are using the same
apply token.
Barring alternatives, this is necessary to make sure
that transitions work properly (since surface operations
span multiple process). Otherwise, even if transactions
are received by SF in the correct order, they can be
applied in a different order.
Bug: 256046837
Test: atest PipRotationTest_ShellTransit and check for leaked
tasks in surface dump.
Change-Id: I0424e66ed347576718f62b1e598ae116720aa70d
There may have multiple transitions when launching a task with
embedded activities. In the last transition info, it may contain
activities occluded by starting window and a closing wallpaper.
By default, all of them will be animated with edge extension,
that looks like showing some noise.
Because the animation of embedded activities under a task level
starting window is not visible, it can be skipped. But for
non-embedded activity, the activity level starting window can be
changed or closed with the host activity, so the case should not
be skipped.
Besides by default, wallpaper is no animation, especially it
shouldn't apply any task/activity style animation.
Also make sure the leash of starting window is always on top of
the task with embedded activities. This just makes the surface
hierarchy consistent.
Bug: 255269113
Test: No flickering when cold launch Settings on a large screen
device with support of activity embedded.
Change-Id: I8fd1137e806aeb4060a83a71dc5aa02acdc42429
* changes:
Describe requested visibilities in public types (3/n: server side)
Describe requested visibilities in public types (2/n: client-server)
Describe requested visibilities in public types (1/n: client side)
This CL introduces BackProgressAnimator which runs in app's main thread.
It receives target progress values from SysUI and drives the actual
progress value passed to the app with a high stiffness, no bounce
spring.
Bug: 238475284
Test: atest WindowOnBackDispatcherTest
Test: atest BackAnimationControllerTest
Test: atest TouchTrackerTest
Change-Id: I5183fc8e77ada4dfb985addd8d5193ef335a558a
This CL introduces BackProgressAnimator which runs in app's main thread.
It receives target progress values from SysUI and drives the actual
progress value passed to the app with a high stiffness, no bounce
spring.
Bug: 238475284
Test: atest WindowOnBackDispatcherTest
Test: atest BackAnimationControllerTest
Test: atest TouchTrackerTest
Change-Id: Ib0d3ebe43929c405b10681000fb4e7ef8bccce34
This CL makes the client send an integer (instead of InsetsVisibilities)
as the requested visible types to the server.
This CL also removes the usages of InsetsVisibilities from WM shell.
Bug: 253420890
Bug: 234093736
Test: atest ActivityRecordTests DisplayContentTests InsetsPolicyTest
InsetsStateControllerTest WindowContainerInsetsSourceProviderTest
WindowLayoutTests WindowManagerServiceTests WindowStateTests
WindowAddRemovePerfTest StartingSurfaceDrawerTests
TaskSnapshotWindowTest
Change-Id: I29d245e3c36a29f01bdd3347fe858727c3540ff8
The collected WindowToken's (e.g. status bar, navigation bar)
isVisibleRequested may be changed according to its WindowState's
visibility policy or the visibility of who is controlling the insets.
They are not aware of the WindowToken surface visibility, so keep
them untouched unless shell transition supports general window
animation or even insets animation.
Bug: 251214841
Test: atest FlickerTests:CloseImeAutoOpenWindowToAppTest
Test: Launch an activity that requests to hide system bars.
And use shell command to change display size at the same time.
After the launch transition is finished, the system bars
can still be visible when swiping from bottom or top.
Change-Id: I2403e2dcbc6684774c9c3b74768a32c7b7a3b8ae
1. When moveActivityToPinnedRootTask with creating a new Task for PiP,
make sure the Task's initial bounds is the same as the activity
parent TaskFragment so the animation starts from the correct bounds.
2. When exit PiP to previous Task, make sure we are animating the
correct window surface. For the previous implementation. there can
also be TRANSIT_CHANGE change for entering ActivityEmbedding split
(from PiP) in the same transition.
Bug: 207070762
Test: atest WmTests:RootWindowContainerTests
Test: atest WmTests:TransitionTests
Change-Id: Ifba090ad9ac9fb7033d343eab1c87c1a67bb9c11
1. When moveActivityToPinnedRootTask with creating a new Task for PiP,
make sure the Task's initial bounds is the same as the activity
parent TaskFragment so the animation starts from the correct bounds.
2. When exit PiP to previous Task, make sure we are animating the
correct window surface. For the previous implementation. there can
also be TRANSIT_CHANGE change for entering ActivityEmbedding split
(from PiP) in the same transition.
Bug: 207070762
Test: atest WmTests:RootWindowContainerTests
Test: atest WmTests:TransitionTests
Merged-In: Ifba090ad9ac9fb7033d343eab1c87c1a67bb9c11
Change-Id: Ifba090ad9ac9fb7033d343eab1c87c1a67bb9c11
The root cause is that TaskFragmentParentInfo wasn't be dispatched
when there's a display or visibility change because we didn't
implement getTaskFragment() in TaskFragment and it led to
the TskFragment can't return itself if the predicate function
returns true.
This CL fixes WC#getTaskFragment and changes to dispatch
Task#shouldBeVisible instead of Task#isVisibleRequested.
The reason is that the visibleRequested change is not early enough for
the scenario that device is folded from unfolded state, and lead to
Settings flickering.
Test: manual - open Settings and fold the device
Test: atest TaskTests#testGetTaskFragment
Test: atest TaskFragmentOrganizerControllerTest ActivityRecordTests
fixes: 249055633
Change-Id: Ie1c56758697d14b426c9ed713da84e49c9f880d8
