This removes the corner animation flickering happening when
starting a letterboxed app after a configuration change
(eg. Dark/Light mode)
Test: Manual
Fixes: 234107097
Change-Id: Iad9f4aaeb8edeeb56b0c88d7d0239843cd66a8f9
Prepare for windowless starting surface. Attemp to decouple the drawing
methods from window related handling.
Move most of snapshot drawing method together to a utility class
SnapshotDrawerUtils, so SystemBarBackgroundPainter now can shared for
shell and core.
Bug: 131727607
Bug: 257857570
Test: atest SnapshotDrawerUtilsTest StartingSurfaceDrawerTests
Test: hot launch an app, and verify snapshot starting window show up
without issue.
Test: cold launch app, verify icon style splash screen can show.
Change-Id: I4d2c04e41d375cf6c8711a60977b8f24dddd41c0
Even though these surfaces/transactions are unreachable, it still
takes time for the GC/NativeRegistry/FinalizerQueue to actually
flush/free references (even if you force GC, it won't flush the
NativeRegistry/FinalizerQueue). This skews the results of our
memory benchmark tests since they measure instantaneous memory.
So, add logic to manually release Transactions/SurfaceControls
when we know they won't be used. This is extra tricky due to
unparceling creating new refcounts. To resolve this, we assume
that all remotes are getting a COPY of all surfaces and then we
make deep-ish copies on the CALLER side if the binder is actually
local. We can't alter the logic on the receiver side because the
binders are one-way and thus PID information isn't available.
Bug: 258913831
Test: systemui-notification-memory-suite-demo and check aggregates
Change-Id: If094e7eeb248a8674e8094cf5cf3019b2cd58047
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
