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
Add an API in DWPC to monitor the Pip is allowed in the streamed display
by policy controller. If not allowed, pop up a warning toast for user.
Bug: 229837382
Test: manually, atest WmTests:ActivityRecordTests
Change-Id: Id1f39e8b54cd9c388c49b3886b9e798144ba5bf1
Activity could call setTranslucent during a transition playing, if the
task of an activity was in transition and that activity should become
invisible, it would be defer until transition finish.
However, since the activity wasn't participant the running transition,
there won't do commitVisibility for it after transition finish.
To correct the visibility status, trigger another transition so the
activities which visibility changed can be collect and commit.
Bug: 246518648
Test: atest testConvertTranslucentOnTranslucentActivity
Test: atest testConvertTranslucentOnNonTopTranslucentActivity
Change-Id: Ic1cda79da37162cca2a1a3fbc73311cc325b3874
When back animation finished, it will invoke the real back callback and
cause a new transition started.
In this CL, we introduce the back transition handler to consume the
incoming transition request and takeover the whole transition if the
transition info contians same departing window token.
This also seperated the behaviors of enabled/disabled shell
transition.
Bug: 238475694
Test: Enabled shell transition, atest BackNavigationControllerTests
BackAnimationControllerTest
Change-Id: I57e7c89ce6cb7a99ab3af403704b9dd948f26151
In previous design, it would create all necessary leashes when starting
back navigation, and they would be carried by `BackNavigationInfo` and
`BackEvent` and would finally deliver to the shell and animator side.
In this CL, we will use the adapter that wraps a back animation runner
to deliver all leashes in next surface placement after back navigation
has started.
In shell side, every animator should be registered by type, so the
adapter could deliver leashes via IRemoteAnimationRunner to the
target animator, and invoke callback when it finished.
This also eliminated all unecessary fields from `BackNavigationInfo` and
`BackEvent`.
Bug: 241808055
Test: atest BackNavigationControllerTests BackAnimationControllerTest
BackNavigationTest
Change-Id: I8bbec0d8d9631110c3d2788d958b50ae487520a7
If shell is starting an existing transition, it doesn't need the
returned transition token so it can be an async call then it won't
block shell's thread to execute other operations.
If shell is starting a new transition, then use the new added 2-way
startNewTransition which is the same as the original path.
Bug: 248550757
Test: atest ShellTransitionTests
Test: CtsWindowManagerDeviceTestCases with shell transition
Change-Id: I5f64d19475d5b857a461775dd6f3002567e93ad8
Before, we call Activity#finish() to finish activities when removing
TaskFragment. This may start a CLOSE transition before the organizer has
a chance to request the actual transition type.
Now, we allow the organizer to finish activities through WCT so that the
operation is atomic and the organizer can request the correct transition
type.
Bug: 240519866
Test: atest WmTests:TaskFragmentOrganizerControllerTest
Test: atest CtsWindowManagerDeviceTestCases:TaskFragmentOrganizerTest
Change-Id: I54671fb2dd34dca952468305429a90d89953de69
