| 4c36b55fc53b1d5f29fe530c00992f6be5c46e3e |
|
24-Apr-2018 |
Yuki Awano <yawano@google.com> |
Do not magnify if surface control is not set
Bug: 77938723
Test: None
Change-Id: I93fc306bf6287016ba86b4404507df4ae926dcad
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 8a4af9c3e830a5d456486593f3047e833f76b4b5 |
|
24-Apr-2018 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Update surface position once created." into pi-dev
|
| b1ea7ca7d3d0bb834056315cf7191524e043291a |
|
06-Apr-2018 |
Evan Rosky <erosky@google.com> |
Update surface position once created.
Otherwise starting freeform activities leaves the surface at
origin until something else updates it.
Bug: 72026789
Test: WmTestApp23 starts without offset surface. Added
WindowContainerTests#testAddChildSetsSurfacePosition
Change-Id: I707cd6924dab190ec84f4a05134c9dce4ff49468
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 39179062c5a0b8cde180344f7370ebb40e7851d1 |
|
18-Apr-2018 |
Jorim Jaggi <jjaggi@google.com> |
Animate home in separate layer
Such that it always stays at the bottom.
Test: Open app in split-screen
Test: go/wm-smoke
Change-Id: If713c6c04e6616ff04d8475ea2da0241ed863628
Fixes: 77144130
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| be4182939fc414adaa54cb1fd9b5185e83d64579 |
|
26-Mar-2018 |
Jorim Jaggi <jjaggi@google.com> |
Fix issues with z-ordering during animations
- Make sure to use DC pending transaction when updating z-layers,
as it could lead to reordering of z-order assignment due to how
we apply pending transactions in the hierarchy
- Create a separate boosted animation layer in which AWT with
zOrder=top animate, which happens above all stack. This brings
back the boosting logic in O without boosting non-boosted stack
above non-animating tokens
Bug: 70730519
Bug: 72649981
Bug: 72686618
Bug: 37953606
Test: Share link from Chrome to Clipboard, make sure disappear
animation happens properly
Test: go/wm-smoke
Change-Id: I3957daac76b991402bf3f520c4a3d3f519933f72
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 32ca41d02880686148cfa730897c575104cf045c |
|
21-Mar-2018 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Remove am/wm.proto which is redundant. The naming convention is defined in core/proto/README.md" into pi-dev
|
| 6c6e9cab42bccb44ebb4b30e7eab7394c0dbb759 |
|
21-Mar-2018 |
Yi Jin <jinyithu@google.com> |
Remove am/wm.proto which is redundant. The naming convention is defined
in core/proto/README.md
Bug: 72474563
Test: make sure the Android build
Change-Id: I2a90cbb6bb0b0c62fe4a0b81cb5bb3ea36381871
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 6728e2f3692df6e9684bd472244f483a1ea14e42 |
|
19-Mar-2018 |
chaviw <chaviw@google.com> |
Merge transactions to parent if layer is going to be removed.
Transaction objects are stored in each WindowContainer. There are cases
where a transaction is added for a layer by using the WindowContainer
transaction object. The WindowContainer can be removed before its
transaction is merged to the global transaction. If that occurs, the
layer can remain around in SF until gc cleans it up.
Bug: 74078662
Test: Open new app. The snapshot animation leash should be gone from
dumpsys.
Test: Open app in split screen. Exit split screen. Open app again in
split screen. There shouldn't be any empty stacks in dumpsys.
Change-Id: I31a61773edf1f541726691b4510c544bbd5beea4
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| f12f9d3ded0d947b1b0c9fd71cf75bdb83f5005a |
|
02-Mar-2018 |
Robert Carr <racarr@google.com> |
Assign leash layer when starting animations.
Currently AppWindowToken does this but WindowContainer does not
ending in a situation where WindowState level animations can cause
child windows to be ordered below the IME when they would otherwise
be above. I couldn't find any reason for the assignLayer call that
was here, as the parent won't view the leash as a child from the WindowContainer
perspective and thus assignment will never happen. I've just replaced
the old call with the new layer assignment.
Bug: 72173720
Test: Manual. go/wm-smoke
Change-Id: Iba57158645e27c2ff74ce6e0b59cd15b15bfe3f5
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 13b154893a19cbeb27e0e6d980d3c6f11d71c3e3 |
|
01-Mar-2018 |
Chavi Weingarten <chaviw@google.com> |
Merge "Use destroy in transaction for animation"
|
| 123e07a47f3056020d6f4d574acba2b7b37a423a |
|
27-Feb-2018 |
Winson Chung <winsonc@google.com> |
Fix issue with stack order positioning when ending recents animation.
- When moving the home stack from a higher index to behind a stack with a
lower index, the position does not need to be adjusted in order to move
the stack (since positionChildAt first removes the stack before adding
it). Updated the existing tests with a case to move the stack to a
non-bottom index to verify this.
Bug: 73901604
Test: atest ActivityStackTests
Change-Id: If1d3af0f35d60569d8a3d86898483bacaaa98bb9
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| b736e3215b8e0afeecd053a43fde6c002ca5c2a0 |
|
23-Feb-2018 |
Chavi Weingarten <chaviw@google.com> |
Use destroy in transaction for animation
Previously, the code calls destroy which will be invoked immediately so there
needed to be ways to delay destroy. This caused some overhead where there
needed to be Runnables to ensure client state updates were called before the
destroy. Instead, use the Transaction.destroy so the destroy doesn't get invoked
until apply is called. This allows any other client states to get updated before
the destroy is called.
This is specifically necessary for reparent calls since a Surface can be
reparented from a Surface that's about to get destroyed to a valid Surface
that's not getting destroyed. This change ensures that Surfaces will get
reparented before Surfaces are destroyed when Transactions are applied.
Original CL: ag/3573288
Reason for revert: Original issue is fixed in ag/3647191.
Fixes: 72953020
Test: SurfaceAnimatorTest
Change-Id: I8bc58e0efc2ae1558c122a40eb52e9c874c0c997
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| a860141390ad48b3606c38a8db934d35bd54dc4e |
|
16-Feb-2018 |
Chavi Weingarten <chaviw@google.com> |
Merge "Revert "Use destroy in transaction for animation""
|
| 38804384df93fb94a1e411ef8752e7aff2249bf4 |
|
15-Feb-2018 |
Chavi Weingarten <chaviw@google.com> |
Revert "Use destroy in transaction for animation"
This reverts commit 1aa12755a98488599de1b240732e16c44b0e3fe0.
Reason for revert: 73448047, 73448319
Change-Id: Ieb5d1f8a7bfd9ba0a2ac6df35dbf76f76698120f
Fixes: 73448047
Fixes: 73448319
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| b0707717315eae52161b363560636098a5c81b64 |
|
15-Feb-2018 |
Rob Carr <racarr@google.com> |
Merge "Assign animation layer above highest animation target."
|
| 2f8aa394f4c3cac043e67095f180db63e4790f6a |
|
31-Jan-2018 |
Robert Carr <racarr@google.com> |
Assign animation layer above highest animation target.
Rather than above all stacks. This fixes the case where when
transitioning to the minimized home state, the secondary split
screen app and home are in a transition, but this transition needs
to occur under the primary split-screen app which is not a part
of any transition.
Bug: 69553456
Test: Manual. go/wm-smoke.
Change-Id: I3069e4a1bc3a30a1567eb51731c44f927cc0cefc
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 1aa12755a98488599de1b240732e16c44b0e3fe0 |
|
07-Feb-2018 |
chaviw <chaviw@google.com> |
Use destroy in transaction for animation
Previously, the code calls destroy which will be invoked immediately so
there needed to be ways to delay destroy. This caused some overhead
where there needed to be Runnables to ensure client state updates were
called before the destroy. Instead, use the Transaction.destroy so the
destroy doesn't get invoked until apply is called. This allows any other
client states to get updated before the destroy is called.
This is specifically necessary for reparent calls since a Surface can be
reparented from a Surface that's about to get destroyed to a valid
Surface that's not getting destroyed. This change ensures that Surfaces
will get reparented before Surfaces are destroyed when Transactions are
applied.
Change-Id: I25bb94378de2c03565ee7df8ab5ef393b57f3aec
Fixes: 72953020
Fixes: 71499373
Test: Tested issue from bug
Test: Set animation duration to 0. Ensure no crash
Test: SurfaceAnimatorTest
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 2f0567b00d22edba0b87c0d06766c3cacaa0e041 |
|
30-Jan-2018 |
chaviw <chaviw@google.com> |
Use self's pendingTransaction object when setting position.
When iterating through each child to set its updated position,
the transaction object was passed to the children. This could allow
multiple transactions to update the same property on the same child.
If that occurs, then the merge does not guarantee the same order.
This could cause earlier transactions to overwrite later ones. Instead,
have each WC update its own transaction object.
Change-Id: Ie1bb758e4efd74fa012c7ec945d9c1c586162df4
Fixes: 72198558
Fixes: 72463091
Test: Issues from bugs no longer occur.
Test: go/wm-smoke-auto
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 55c47ab2e5b39dd66e7f8a16045b47d624161341 |
|
30-Jan-2018 |
Chavi Weingarten <chaviw@google.com> |
Merge "Added animations to dim layers"
|
| 2fb06bc31f06ac046c94e41dbcaf019623052de8 |
|
20-Jan-2018 |
chaviw <chaviw@google.com> |
Added animations to dim layers
Added animations to dim layers when dims are set for
WindowState surfaces since they're controlled by the system.
Test: Dims for dialogs now animate.
Test: DimmerTests
Fixes: 71841698
Fixes: 69553362
Fixes: 71614627
Fixes: 72333587
Change-Id: I34f6f3d7885d5c9c0075a941e40d68bc5618a016
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| a2a55b3b36831b609acb6da9a4d45787e453ec5a |
|
29-Jan-2018 |
Bryce Lee <brycelee@google.com> |
Merge "Do not propagate parent bound changes from task as onResize."
|
| 66f0026f3f27e71dfb764df438ce9016d7c5f08d |
|
26-Jan-2018 |
Winson Chung <winsonc@google.com> |
Merge changes from topics "reland_recents_animation", " reland_recents_animation"
* changes:
Fix issue with reparenting stacks on displays.
Revert "Revert "4/ Update SysUI shared lib for Recents transition""
Revert "Revert "3/ Add input consumer to capture touches during a Recents transition""
Revert "Revert "2/ Add support for remote Recents animation""
Revert "Revert "1/ Create display content window controller to position stacks in the display""
|
| e2d721781fc024cbd9a14929741e5b476242291f |
|
25-Jan-2018 |
Winson Chung <winsonc@google.com> |
Revert "Revert "2/ Add support for remote Recents animation""
This reverts commit 9f8518e532e41ba57916afc49bba72bc23ad3eda.
Reason for revert: Testing relanding changes with ag/3515280
Change-Id: I410bd752c815a5b998a719453def01e00a9d47c8
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 7f1fa997a9f0ff049406fba2c7717445769cbc4b |
|
10-Jan-2018 |
chaviw <chaviw@google.com> |
Don't take screenshot when no WSA surfaces are visible.
Currently screenshots are taken even when no WSA surfaces are visible.
This results in black screenshots geting taken and later used to show in
recents. Restore previous behavior where screenshots are not taken for
apps that don't have any WSA surfaces visible.
Test: Enter split screen. Put an app in the secondary screen. Exit
split screen and enter recents. App that was secondary should now contain
a correct screenshot instead of displaying a black screenshot.
Change-Id: I1417afa0bf6602f3ca7ed55e96fc94bce5f5b4fe
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 9f8518e532e41ba57916afc49bba72bc23ad3eda |
|
25-Jan-2018 |
Jorim Jaggi <jjaggi@google.com> |
Revert "2/ Add support for remote Recents animation"
This reverts commit 0026a5152c427f9cf2c04da2b23a5ece2fcdb36d.
Breaks presubmits
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 0026a5152c427f9cf2c04da2b23a5ece2fcdb36d |
|
17-Jan-2018 |
Winson Chung <winsonc@google.com> |
2/ Add support for remote Recents animation
- Allow the recents component to drive the animation from an app into
Recents using the remote animation framework. When initialized, the
animation repositions the recents activity behind the currently visible
tasks and provides the set of surface controls for the visible tasks.
Once complete, the recents component notifies the system whether it
has completed the animation into the recents activity, or whether it
should restore the previous state. In addition, there is a prescribed
delay after which the system automatically cancels the recents animation.
Bug: 70180552
Test: go/wm-smoke
Test: Manual, swipe up with suitable launcher build
Change-Id: Id32f03c7ad2288dce06231cfaa4b21916da511d7
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| d92ae48606fd89f0fffd570db8d3175cd6f82728 |
|
22-Jan-2018 |
Bryce Lee <brycelee@google.com> |
Do not propagate parent bound changes from task as onResize.
When a stack is resized on the WindowManager side, it does not
itself signal a resize in any children. The children themselves will
receive updated override configurations for this. It is therefore not
necesssary to propagate calls from the task to the children when the
stack is resized.
This changelist separates out the callback for parent resizing into
onParentResize. The default implementation is to call onResize. The
default implementation of onResize now calls onParentResize on its
children. For Task, onParentResize is overridden to prevent
propagation.
Change-Id: If7990c88f12245774d085650b15da9abc96bf622
Fixes: 70558903
Test: atest FrameworksServicesTests:com.android.server.wm.WindowContainerTests#testOnParentResizePropagation
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 6db6679a1a365fab545e9be5964645fafeb9a25d |
|
12-Jan-2018 |
Chavi Weingarten <chaviw@google.com> |
Merge changes from topic "fixTurnOnScreen"
* changes:
Remove TURN_ON_SCREEN from bulkUpdate and set mTurnOnScreen.
Revert "Revert "Call prepareSurfaces in applySurfacesChangesTransaction""
Revert "Revert "Revert "Revert "Avoid setting size/position on Transaction if not needed""""
|
| 3e751afd4e526d9e8627eabc57d15d6b357f4065 |
|
11-Jan-2018 |
chaviw <chaviw@google.com> |
Revert "Revert "Revert "Revert "Avoid setting size/position on Transaction if not needed""""
This reverts commit b38a6704e09b80b9b4fe4f3ad0d16ad6179f612e.
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| a28ed766c4c21da06b83faee93776225a4673897 |
|
11-Jan-2018 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Add WindowContainer proto definitions"
|
| b38a6704e09b80b9b4fe4f3ad0d16ad6179f612e |
|
10-Jan-2018 |
chaviw <chaviw@google.com> |
Revert "Revert "Revert "Avoid setting size/position on Transaction if not needed"""
This reverts commit 1e8c4c8c0c9111b7ae90e110c73122c7bff1df81.
Fixes: 71789344
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 04ab439865c0697940453380b05040044f2e04e3 |
|
10-Jan-2018 |
Vishnu Nair <vishnun@google.com> |
Add WindowContainer proto definitions
Bug: 64831661
Test: verified proto dump from winscope
Change-Id: Id4d595a58f4ce0ce1891b3731ecbb5ce9b938006
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 1e8c4c8c0c9111b7ae90e110c73122c7bff1df81 |
|
09-Jan-2018 |
Jorim Jaggi <jjaggi@google.com> |
Revert "Revert "Avoid setting size/position on Transaction if not needed""
Original issue will be fixed with CL in same topic
This reverts commit d70feb234f47d6088c751f8c5529a29ac3aa029b.
Bug: 71694437
Bug: 71692657
Bug: 71510789
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 4130a68a92b2c5264917d9ac37b51b74aa7993b9 |
|
09-Jan-2018 |
Jorim Jaggi <jjaggi@google.com> |
Fix SurfaceAnimator and SurfaceAnimationRunner tests
Since we marked mAnimator.mInitialized to true in the tests,
WM executed things from another thread during tests leading to
concurrency bugs.
Instead, we stub out addAfterPrepareSurfacesRunnable to a consumer
which executes the runnable directly during tests, avoiding the
need to let WM process animation frames.
Also attempts to fix flakyness in SurfaceAnimationRunner
Test: go/wm-smoke
Test: SurfaceAnimatorTest
Test: SurfaceAnimationRunnerTest
Change-Id: Ic9522e1afef6ce62667aefca80e58d6fb1db3424
Fixes: 71650763
Fixes: 71602314
Bug: 71719744
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| d70feb234f47d6088c751f8c5529a29ac3aa029b |
|
08-Jan-2018 |
Jorim Jaggi <jjaggi@google.com> |
Revert "Avoid setting size/position on Transaction if not needed"
Reason: Causes weird issues with transaction reordering
Fixes: 71694437
Fixes: 71692657
This reverts commit 88f620534f9fe2c3a32765b2a34d3092ab889b1a.
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 9454d58f576e0386b7cafcab567372415d9f7c18 |
|
04-Jan-2018 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Avoid setting size/position on Transaction if not needed"
|
| 88f620534f9fe2c3a32765b2a34d3092ab889b1a |
|
03-Jan-2018 |
Jorim Jaggi <jjaggi@google.com> |
Avoid setting size/position on Transaction if not needed
Passing the JNI layer is quite expensive. Avoid updating the
position/size if not needed by storing the last size.
Test: AppTransitionTests
Test: go/wm-smoke
Bug: 71510789
Change-Id: Ibb3660114fb0e573c9cd2144e5af11f57a96a9d6
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 596a199dd80e872a1b35c1e0af69786af190f98b |
|
29-Dec-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix z-order when transfering animations
We need to reparent the transfered leash to the the animation
layer, not the original parent
Test: Open Play Movies, observe correct z-order during cold-launch
Test: go/wm-smoke
Test: SurfaceAnimatorTest
Change-Id: Ic5a68c68514bb3560b6877a9a29c506aeccee2bf
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 619c9f7c5cd2a19912f9a4f2dbfe1a32d944a75b |
|
19-Dec-2017 |
Jorim Jaggi <jjaggi@google.com> |
Handle z-layering in animation layer
We use the prefix order to determine base layer within the
animation layer. This ensure that for the animation windows, the
z-ordering during animations doesn't change.
We then boost anything that needs a z-boost to 800570000 + prefix
order, such order within the boosted layers is preserved as well.
Also fix an issue where the thumbnail wasn't attached to the
animation layer.
Test: WindowContainerTests
Test: go/wm-smoke
Bug: 64674361
Change-Id: If5909bd87a12f1d8920c7232acab0f3d17be0f6c
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 23ee71c8c2a65382166db88423af2dbf2cfacfa4 |
|
18-Dec-2017 |
chaviw <chaviw@google.com> |
Set initial position for WindowAnimation and reparent animation leash.
1. Set the initial position for the WindowAnimationSpec to be the stack
position.
2. Reparent the animation leash to mAnimationLayer
3. Updated Surface names for clarity.
Test: Opening apps animate from the correct start location. When apps
are animating, their layers are reparented to the correct animation
layer.
Change-Id: I3e3a1e45f0a0cf9d471dee105abd9bce05d1e91d
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| e07246ad7bfa2fad8e6122301a460c2f6b783680 |
|
13-Dec-2017 |
chaviw <chaviw@google.com> |
Set stack size and position and update children surface position.
Update the stack's size and position to represent the bounds. Then
update all children's positions so they are in the correct place within
the stack's bounds.
Test: Split screen, pip
Change-Id: I0372a8d20407ec35d1e8c0fc8165253f68d2f18f
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 980c9de9766668f7d8899067fe34833560197108 |
|
17-Nov-2017 |
Jorim Jaggi <jjaggi@google.com> |
Lock free app animations (3/n): Implement transfering animations
Test: go/wm-smoke
Bug: 64674361
Change-Id: I2170c31c1a95cea049bcc66978bb7737337503b3
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| f5f9e12146a3857c28b8c0fc96c2fa68a2ae40de |
|
24-Oct-2017 |
Jorim Jaggi <jjaggi@google.com> |
Lock free app animations (2/n): Use SurfaceAninimator
This is the main CL that switches over from using the legacy
animation system to using the new SurfaceAnimator for app
window animations. Also moves applyAnimationLocked to
AppWindowToken.
AppWindowAnimator still has a bunch of state that needs to be moved
into AppWindowToken in future CL's.
Test: go/wm-smoke
Bug: 64674361
Change-Id: Ifc83cbac281ce0654ecd8a1c2ca9c24a4d87c1d1
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| a5e105728fb87264b9dc2e66b3703168f8864110 |
|
15-Nov-2017 |
Jorim Jaggi <jjaggi@google.com> |
Lock free animations (2/2)
Second CL that migrates WSA to use SurfaceAnimator
We start our synchronized app transition journey by showing that
the concept works by using WindowState animations as proof of
concept.
The main class in this CL are SurfaceAnimator and
SurfaceAnimatorRunner. When we start an animation on a Window, we
create a new bufferless surface, called "The Leash", in the
hierarchy and attach the surface of WindowState onto it, while
attaching the leash onto the old surface parent which is still
responsible for z-layering.
Then, we pass off the Leash into SurfaceAnimationRunner, which then
changes the surface properties of Leash in every animation frame,
without holding the WM lock. While it's doing that we can still
update the z-layering of the window, or even relayout the window
of needed - the important surfaces for this are still under WM's
control.
In case the animation is finished the window surface gets
reparented to its original parent, and the leash is abandoned.
Note that the reparenting is done in the same transaction as
processing the animation finish, such that we don't end up with
a flicker in case of a disappearing animation, where the window
surface gets destroyed.
In case the animation needs to be cancelled, WM can revoke control
of the leash by reparenting the window surface. Even if the
cancellation signal is heavily delayed, WM immediately regains
control over the surface by reparenting it within a transaction.
We also introduce the concept of animating a WindowContainer. We
clean up isAnimating:
- isLocalAnimating: is the container itself animating
- isAnimating: is the container or one of its parents animating
- isSelfOrChildAnimating: is local animating or any child
animating.
SurfaceAnimationRunner also needs it's own thread so it's not getting
bogged down by any WM lock contention by processing regular
animation frames. We call that thread android.anim.lf (lockfree).
Now, imagine that SurfaceAnimationAnimator would sit behind an IPC in
another process and instead of animating WindowState, we'd animate
AppWindowToken. Then, synchronized app transitions would be done.
Test: go/wm-smoke
Test: SurfaceAnimatorTest
Test: SurfaceAnimationRunnerTest
Test: WindowContainerTests
Bug: 64674361
Change-Id: Idf59daa90361af57fce1128d19a0c0dbf5971d18
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| ffe128d46dc45939df08231c8ec382b33306a77f |
|
30-Nov-2017 |
Jorim Jaggi <jjaggi@google.com> |
Optimize surface hierarchy
- Do not reset layer if layer doesn't change. JNI is expensive.
- Only assign child layers once if we have to do multiple passes.
- Fix issue where layouting the starting window caused the surface
to be resized, leading to a blocking SF transaction.
Test: go/wm-smoke
Test: adb logcat -b events | grep 319, inspect transition times.
Fixes: 69632880
Change-Id: I8fffca30591730fae87ed3aeb9df0bdf7d4b55dd
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| df262f5e8990405d3b5d3e4550556eac9b057278 |
|
08-Dec-2017 |
Wale Ogunwale <ogunwale@google.com> |
Don't send non-resizeable notification in some cases.
Don't send non-resizeable notification when putting other stacks in
the system in split-screen secondary windowing mode due to us entering
split screen mode since they won't be visible.
Also, added isVisible to containers in the window manager proto.
Change-Id: If83076514c160ad7b2a639e32d6f9fc85e70bd53
Fixes: 70355262
Test: go/wm-smoke and steps from bug.
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| ee4d4b96657ce45d8f555dffb2f7f200f667b2a4 |
|
22-Nov-2017 |
Robert Carr <racarr@google.com> |
Rip out WindowContainer#isScreenOverlay
Messes up ordering of the windows that should be above
the navigation bar and status bar. It seems better to
achieve the IME layering we need directly.
Bug: 69591927
Test: Manual
Change-Id: I69202bca0b84cec5d9f5176645e31c5bd0af767e
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| f3c6a47bdd009de616b6c490bbb52a82d11cc870 |
|
14-Nov-2017 |
Bryce Lee <brycelee@google.com> |
Store bounds in WindowConfiguration.
This changelist consolidates the usage of frame bounds in containers
into the WindowConfiguration. As a result, the bounds are now shared
across AM and WM. Any changes to the bounds on one side are
propagated to the other via override configuration changes. Previous
instrumentation to synchronize the two sides is no longer necessary.
This changelist does not attempt to consolidate common logic shared
between WM or AM components for setting bounds.
Bug: 68719294
Test: go/wm-smoke
Change-Id: Ia8978dba8525b83201640e159caefe16e626b7c1
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| f59b8ddd93a52b72a09150d0e19dbebb4b6ecf39 |
|
03-Oct-2017 |
Robert Carr <racarr@google.com> |
Reimplement DimLayer's using hierarchy.
Still missing the fade in/out animation. See Dimmer.java for details.
Bug: 64815723
Bug: 64816140
Test: DimmerTests.java. Existing tests pass. go/wm-smoke. Docked resizing Dim layer works, various dialog dim layers work.
Change-Id: I19a03f1b6b602475410fcfb2c9728aae1d0bed85
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| b1579c8d898811010b60eab4e996f3d071980155 |
|
05-Sep-2017 |
Robert Carr <racarr@google.com> |
Re-implement Z-ordering based off SurfaceControl hierarchy.
First steps in using the SurfaceControl hierarchy pervasively through
the WindowManager. For each level of the WindowContainer hierarchy
we instantiate a buffer-less SurfaceControl which is used to apply
constraints to all of it's children. For now we use full-screen surfaces
at every non-leaf level and so the only constraint we apply is Z-ordering.
Calculation of Z-ordering is done through the WindowContainer#assignLayers
pass and begins with DisplayContent. Changes are accumulated in-to a pending
transaction which is applied as part of prepareSurfaces (which now applies
to each level of the WindowContainer hierarchy rather than just windows).
Bug: 64815723
Test: Existing tests pass. go/wm-smoke. ZOrderTests.
Change-Id: Ib31bc3107c7fa398cf2ed72430fcb7596fad6fd5
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 4921ccf501717c378ae239f9f02b6170860472d4 |
|
28-Sep-2017 |
Adrian Roos <roosa@google.com> |
Add trim levels to writeToProto
Enables faster dumping without information that is not relevant in
certain scenarios.
Bug: 64831661
Test: adb shell dumpsys window --proto | hexdump -C
Change-Id: I10827f2dd092fb53b2d452bb12ef76a6adb50f41
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| ab5de37d093ba26b75796c614636aaee36a937d9 |
|
18-Oct-2017 |
Wale Ogunwale <ogunwale@google.com> |
Made creation of multiple stacks more intentional.
Previous it was unintentional due to the following fixes:
- Made ACTIVITY_TYPE_UNDEFINED compatible with stacks of
ACTIVITY_TYPE_STANDARD. Any request to create an undefined stack type
ends up creates a standard type, so it makes sense for them to be
compatible.
- Made standard types of WINDOWING_MODE_UNDEFINED compatible with the
display's windowing mode. Any request to cerate a stack in an undefined
windowing mode end up creating a stack in the display's windowing mode.
- Added 'dumspys activity containers' for dumping the activity
hierarchy.
Now it is more intentional where we always create a stack for specific
stack activity types and windowing modes when getOrCreateStack is
called.
Bug: 67747409
Bug: 64146578
Test: go/wm-test
Test: Existing tests pass
Change-Id: I85935e8681113a0c06dfc15ef9891e3f91b98a02
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 6191149c9c8d41a08c0167d94d21ac463c144b71 |
|
11-Oct-2017 |
Wale Ogunwale <ogunwale@google.com> |
Cache reference to stack objects we use a lot in WM.
This helps with fast access since we are no longer using stack ids
to look-up stack objects.
Test: Existing tests pass.
Test: go/wm-smoke
Change-Id: I98cb6f4eb1e6d6acb81b2077aee03265a075a227
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 0d5609ba8c64710dbab020d99c832f8d470c716a |
|
13-Sep-2017 |
Wale Ogunwale <ogunwale@google.com> |
Added WindowConfigurationProto and friends
Also added WindowContainerProto and ConfigurationContainerProto
Will be used by cts tests in upcoming CLs that replace StackId APIs.
Test: adb shell dumpsys window --proto
Bug: 64146578
Change-Id: Id6ca2a93e3d15ac696ab54cb241870e973985967
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| e7d2b85068dfda580983a510f60983984c37e7ca |
|
28-Aug-2017 |
Jorim Jaggi <jjaggi@google.com> |
Nuke everything obsoleted by task snapshots
Test: go/wm-smoke
Change-Id: If9c9c2e66d97d6a5fa94d0d62ae7459fdde2a9a0
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 7ff3ff33df372a00489c5c8761f8914698c4974f |
|
14-Aug-2017 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Switch WindowContainer to use ConfigurationContainer"
|
| 00d586d8f0bcd6233fd21970582ec27621fbceed |
|
29-Jul-2017 |
Bryce Lee <brycelee@google.com> |
Allow foreground AppWindowToken to influence orientation.
It is possible for an activity to request an orientation after
finish has been called, causing the system orientation to be
re-evaluated. Since the activity is closing, it will no longer be
eligible to influence orientation. If another stack/task is brought
to the foreground, it will as well won't be able to participate
since it is not considered an opening app and won't be visible. As a
result, we set the orientation to unspecified, leading to the
foreground activity to be resumed in the wrong orientation.
This changelist addresses the issue by allowing an AppWindowToken to
participate in orientation calculations if it is not closing and is
on top of the wm hierarchy, regardless of its visibility.
Change-Id: I0f316d6d824398d084c7648cf2dc2c2d07b4410d
Fixes: 63982461
Fixes: 63513655
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowTokenTests#testGetOrientation
Test: go/wm-smoke
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 98d6231f02bec2d55880db36fd7d49281333f286 |
|
12-Jul-2017 |
Wale Ogunwale <ogunwale@google.com> |
Switch WindowContainer to use ConfigurationContainer
To reduce implementation dupication.
This also involved moving ConfigurationContainer to the wm package.
Test: bit FrameworksServicesTests:com.android.server.wm.ConfigurationContainerTests
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerTests
Test: go/wm-smoke
Change-Id: Ibeca7e2ad2685f0984fccc66852d53ed9af0925f
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 64900ad13ccaa78b163d73783d484ccc4a7c607d |
|
19-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Take snapshot when screen is turning off" into oc-dev
|
| 51304d7380b6122ac55645fd9085ba071b04afa9 |
|
17-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Take snapshot when screen is turning off
Since we can't take a snapshot when screen is turned off, we need
to snapshot before we are turning the screen off. For this, we
- Add a callback from DisplayPowerController to give policy a
chance to do something before display will be turned off.
- Implement this callback by taking snapshots of all visible
tasks.
Test: Inspect logs/traces about screen off blocking to make sure
callback is working correctly.
Test: Insert artificial 500ms delay in onScreenTurningOff and make
sure we are unblocking screen off when turning on screen in the
meantime.
Test: Open Maps, go to recents, open maps again, scroll to another
location, toggle power button, make sure the old location isn't
shown during unlock.
Change-Id: I489f31358f838d418f894f996495946084f136a4
Fixes: 37107783
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 4448e1ebb2d00f31292abcc7c5161a4e6f050c2e |
|
16-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix GraphicBuffer leaks in system_server
IWindowId is being kept alive by binder in certain cases, which
will leak WindowState, which can leak a whole lot including
the snapshot GraphicBuffer.
- Fix a leak in WindowContainer.mTmpChain1/2
- When the window gets removed, make sure to release the reference
to the window state so even if Binder keeps IWindowId alive, we
don't keep WindowState alive
- Make sure that even if we leak TaskSnapshotSurface we don't leak
the GraphicBuffer.
Test: Boot, some basic sanity testing.
Bug: 36279079
Change-Id: I4a0a784b32bc2df47934b1bed1d62b0682beb2dd
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 612bb885bcef87034070e8e3bfc0b0e953c0f606 |
|
16-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Use ArrayList as children
Such that traversal is O(n) instead of O(n²)
Test: WindowContainerTests
Bug: 32668632
Change-Id: Ie52026a76a0f65c71ff6bd35d13b3d0c5d44bb3f
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 5e5a68dc063a3692ec8dcd9c07c9861680a18a52 |
|
25-Mar-2017 |
Wale Ogunwale <ogunwale@google.com> |
Fixed issue with SCREEN_ORIENTATION_BEHIND not working correctly
If an app specifies SCREEN_ORIENTATION_BEHIND, then use the orientation
of the app behind it regardless of the visibility state of the app
behind.
Fixes: 35281868
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerTests
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowTokenTests
Test: bit FrameworksServicesTests:com.android.server.wm.TaskStackTests
Change-Id: Ieba4e4bb1a7f47cd6f082491d37fcabcf5bd5199
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 55ddf8f9e5d8241130aeac6be7b4978860f41bf8 |
|
20-Mar-2017 |
Wale Ogunwale <ogunwale@google.com> |
Added support for maxAspectRatio manifest attribute.
- Allows an app to specify the maximum aspect ratio it supports.
- Support for overriding configuration and bounds at the activity
record and app window token level.
Test: cts/.../run-test CtsAppTestCases android.app.cts.AspectRatioTests
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerTests
Test: bit FrameworksServicesTests:com.android.server.wm.WindowFrameTests
Bug: 36505427
Bug: 33205955
Bug: 35810513
Change-Id: Ib2d46ed0c546dd903d09d6bb7162a98bd390ba81
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| a163b76570d15e0bbfd318b2962c4966a8a538e5 |
|
24-Jan-2017 |
Bryce Lee <brycelee@google.com> |
Allow opening activity to specify orientation.
An activity's window is initially not visible. This means it is not
accounted for until it becomes visible, which means requested
orientations will not be honored until after onCreate.
This changelist removes the visibility check previously used determining
the orientation.
This changelist also addresses an issue where an ActivityRecord member
variable tracking the last configuration sent was not being initially
updated.
Fixes: 33844887
Fixes: 33814250
Fixes: 34165818
Fixes: 34177026
Fixes: 33809086
Fixes: 34111451
Fixes: 33844423
Test: Verified reported issues fixed in apps mentioned in bugs
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerTests
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test android.server.cts.ActivityManagerAppConfigurationTests
Change-Id: If9243792b9f2d137dc5addbf6fb735a0048fa192
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 2ec59897cf892666146f378825d2adcf972248ac |
|
18-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge changes I01e81b9c,I532c2d74
* changes:
Add a listener when task snapshots change
When app dies, destroy snapshot
|
| 10abe2fe297ce1ec60c15a3bd947757aee5b14b3 |
|
03-Jan-2017 |
Jorim Jaggi <jjaggi@google.com> |
When app dies, destroy snapshot
Also destroy snapshot when we remove the AppWindowToken.
Test: runtest frameworks-services -c
com.android.server.wm.SnapshotCacheTest
Test: Open app, go home, kill app, make sure snapshots are
destroyed.
Change-Id: I532c2d7499a86164175f9fcbc8b77c6eb6bfeae6
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| c5cc301689649695e03f502e7d1c1492ef5e5d1e |
|
13-Jan-2017 |
Wale Ogunwale <ogunwale@google.com> |
Have better separation between adding, positioning, and reparenting task
Several methods in activity manager and window manager performed adding,
positioning, and reparenting a task operation and sometimes failed silently
when things don't work due the callers using the methods for a particular
operation, but getting a different operation due to programmer error.
This CL better separate the methods responsible for adding, positioning, and
reparenting a task and also fails hard when there is an error.
Test: bit FrameworksServicesTests:com.android.server.wm.TaskWindowContainerControllerTests
Test: Manual testing existing PiP doesn't leave the device in a bad state.
Bug: 34260633
Change-Id: Id64367da30fc6214eb6f95b2bd5e58ed0e953a88
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| e1fe7fa288a34ecaaab390f49ef540edc4a6c52d |
|
16-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added TaskWindowContainerController
For linking TaskRecord in AMS to Task window container in WMS.
Bug: 30060889
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowContainerControllerTests
Test: bit FrameworksServicesTests:com.android.server.wm.TaskWindowContainerControllerTests
Test: Existing test pass and manual testing.
Change-Id: I16248f3e96e5087ba24198a48a3bd10a12ae76a6
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 26c0dfed7a0cd54abafdd0ccbb5b757506d51c76 |
|
14-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Support for WindowContainer controllers and listeners
- WindowContainerController class allows a component outside window manager
to create a window container and communicate directly with it to make
changes. For example, the ActivityRecord class in activity manager uses the
AppWindowContainerController class to create and communicate with
AppWindowToken window container class which is its counterpart on the window
manager side.
- WindowContainerListener interface allows a component outside WM to get
notified of changes to a window container. For example, the ActivityRecord
class in AM implements the AppWindowContainerListener interface to get
notified of changes to the AppWindowToken container.
Bug: 30060889
Test: Existing tests pass and manual testing.
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerControllerTests
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerTests
Change-Id: I2896bfa46a80b227052528c7da8cf4e56beab4bc
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| cd5dcb8b3d7d8b6759232a02c0a5c8ae21e22e33 |
|
04-Jan-2017 |
Andrii Kulian <akulian@google.com> |
Always place stacks below pinned stack
When positioning or adding stacks we must make sure
that no stack is above pinned stack.
Bug: 34049027
Test: runtest frameworks-services -c com.android.server.wm.TaskStackContainersTests
Change-Id: Ic92a4e07e9cde42deed53912ac1419fde4ab2f08
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| d276563b38907647ce70940e1e90603826df6ab4 |
|
13-Dec-2016 |
Andrii Kulian <akulian@google.com> |
Add positionChildAt method to WindowContainer
Added method to change the position of a child among siblings.
It accepts int value, which can either specify a target position
or POSITION_TOP/POSITION_BOTTOM.
When child is moved to top or bottom, there is an option to also
perform same action on parents. This will effectively move the
entire branch of the hierarchy tree to top/bottom.
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerTests
Test: #testPositionChildAt
Test: #testPositionChildAtIncludeParents
Test: #testPositionChildAtInvalid
Test: bit FrameworksServicesTests:com.android.server.wm.TaskStackContainersTests
Test: bit FrameworksServicesTests:com.android.server.wm.TaskStackTests
Change-Id: I6ade787487055f1c9a305afea64270c243196614
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 72919d2c310db04fdb860e926ccb0bfe6e3aef08 |
|
09-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Untangle creation of Task from addition of AppToken in WM.
Makes it easier to follow what is going on and also clean-up in
preparation of stand way for AM to interact with containers in WM.
Test: Existing tests pass and manual testing
Change-Id: I91754b6d974dce2f696453cdaed175efb0f10c73
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 1e129a4212ec3b388c65db8f6ce18896362ac35c |
|
21-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Reduce object allocations in WM in some frequently called methods
With the use of lambdas to get all windows in the window container
hierarchy, we need to be careful in frequently called code paths to
make sure the number of objects we allocate isn't crazy. This CL
converts some commonly called code paths that use lambda to use a
method reference for the lambda so we only need to allocate once vs.
each time the code path is executed.
Test: Perform some common operations on the phone and make sure
the object allocations that show-up in Allocator Tracker for
window manager seems reasonable
Change-Id: Ie0f245980de96ec68a4e62e76130db7d98c3f7d9
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| ee41d4afcb089eac6a6a569557905f71bdd33f6c |
|
21-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Introduced WindowContainer.mConsumerWrapperPool
WindowContainer.forAllWindows(Consumer<WindowState>...) requires a lambda
to be allocated each time it is called since we need to capture the callback.
Switched to using an object pool for the process to reduce allocations.
Test: Run the allocation traker and make sure there aren't lambda allocations
for WindowContainer.forAllWindows() method.
Change-Id: If49c1b0bd2e0a5d6d7a30ff686b5235e69a61750
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 6213caa42d89cc446de4f8f9ba00630f166f23cc |
|
02-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Revert "Revert "WindowList be gone!""
This reverts commit ffa5a9de0c127cb77ddec625fea101ddddb7ad32.
Bug: 33098800
Bug: 33098294
Test: Existing tests pass.
Change-Id: I5803a010c5a224dd1cf452a4a7beb3a4c0a043f4
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| ffa5a9de0c127cb77ddec625fea101ddddb7ad32 |
|
23-Nov-2016 |
Jorim Jaggi <jjaggi@google.com> |
Revert "WindowList be gone!"
This reverts commit 4551c8bbee4114fa884938dbe90ac0d06ca78fc5.
Reason for revert: Broke a lot of things!
Bug: 33098800
Bug: 33098294
Change-Id: I307b1c7ee39445d6155a4bbce2bf5f289de55285
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 4551c8bbee4114fa884938dbe90ac0d06ca78fc5 |
|
10-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
WindowList be gone!
The use of DisplayContent.mWindow list to track all windows is
no longer needed as we can now get windows through the window
container hierarchy with methods like forAllWindows. The window
list was also a very complicated logic to understand and maintain,
so it won't be missed :)
Bug: 30060889
Test: Existing tests pass
Change-Id: I590cb33aa0f42bcd4a26ddce102f05e657f54144
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| f4ebe2e2ccfcbce9de7ad0c3b5399971201f66fd |
|
09-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Removed WallpaperController dependency on WindowList.
WallpaperController now accesses the container hierarchy directly
to determine the state of the wallpaper windows and targets.
Bug: 30060889
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test \
android.server.cts.ActivityManagerTransitionSelectionTests
Change-Id: Ib70beaf340f257ad4e1093cc127f81e7adf41636
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| d1880960581d526cbaed0566d522987d9301b293 |
|
08-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Removed used of DisplayContent.getReadOnlyWindowList()
Changed the call points to use DisplayContent.forAllWindows() to
get windows on the display.
Test: Existing tests pass.
Change-Id: I6f8bf15ba246fac69c4a496ebb1d9e0b9b6a95a2
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| b783fd8a0866ad0c18dff333af73e2d49ff2b680 |
|
04-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Traverse window hierarchy without window list
Added support for to get all windows in the hierarchy without needing
to use WindowList concept which is a very complicated implementation
in the code base.
This implementation walks the hierarchy node by node returns windows
in order to the caller using a callback.
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
Change-Id: I2719f7c96f26dad23f91c1c589be88712bd224b8
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| fe762344f4475a3a336bb46aef2d59c1fabf32ab |
|
13-Oct-2016 |
Jorim Jaggi <jjaggi@google.com> |
The big keyguard transition refactor (1/n)
The heart of this change are two things:
1) Instead of using the force hide mechanism to hide windows behind
Keyguard, we actually make the activities invisible in activity manager.
2) When Keyguard is going away, we change the visibilities in activity
manager and run an app transition.
At the very core we move the responsibility of hiding activities to
ActivityStack, which checks whether Keyguard is showing, and then
hides all non-show-when-locked activities. For that, we need to check
whether any window of an activity has SHOW_WHEN_LOCKED set. We
introduce a callback from WM -> AM in case these Keyguard flags have
changed.
Furthermore, we decide whether to occlude Keyguard in KeyguardController,
which just checks whether the top activity has SHOW_WHEN_LOCKED set. When
this state changes, we prepare an occlude/unocclude app transition, and
in PWM we just inform the Keyguard about the animation so SysUI can play
along this animations in a mostly synchronized manner.
Since we now use an app transition when unlocking the phone, we get
lockscreen launch animations for free - window manager automatically
waits until the activity is drawn, or directly executes the transition
if there is nothing to animate. Thus, we can remove all the infrastructure
around "waitingForActivityDrawn".
The logic to show/hide non-app windows is moved to policy, and we add the
ability to run animations on non-app windows when executing an app
transition.
Test:
1) runtest frameworks-services -c com.android.server.wm.AppTransitionTests
2) Manually test unlocking Keyguard:
2a) Without security
2b) With security
2c) With security but trusted
2d) Portrait while activity behind is in landscape
3) Test launching things from Keyguard
3a) Without security
3b) With security
3c) Launch camera without security
3d) Launch camera with security
3e) Launch camera with securtiy and trusted
3f) Launch voice affordance
4) Set no notifications on lockscreen, drag down, make sure you get
the correct animation
5) Test clicking "emergency" on bouncer
5b) Test "Emergency info" on emergency dialer
5c) Test clicking edit button on emergency info, should show pattern on
Keyguard
Bug: 32057734
Change-Id: Icada03cca74d6a612c1f988845f4d4f601087558
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| b94292e5fe18a459aa521b9b9631d2db0485ac1b |
|
19-Oct-2016 |
Andrii Kulian <akulian@google.com> |
Fix NPEs when display is added or removed
- In WindowContainer set parent of the child after it is actually
added. This way if the child class depends on this in overridden
methods it will be in correct state.
- Reconfigure display only if it is attached. Otherwise there is no
corresponding DisplayContent record with configuration.
Change-Id: I20c51522d82f9d0ca98f098070585e6472a23e98
Test: Updated WindowContainerTests.
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| b0f3b836b9fe98d395fdbadf2cdd3603f4e0145a |
|
17-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Clean up use of DisplayContent from WindowState.
Follow up to ag/1483993 where WindowTokens can now only be on one display.
Clean-up some existing code that dealt with having WindowTokens on
multiple displays.
Test: Existing tests pass.
Change-Id: Ie908eda37bc44097dea773b0fc163d35cc9baf35
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 360a8bce7386dc9b231c698af1730e04362b6c2e |
|
10-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Switch WindowState to get display content from its window token
WindowState no longer needs to track what display it is on now
that the window token can only be on one display.
Test: Existing tests pass.
Change-Id: Ia0530d73da0b1ecc17f596ec62c933637bd1c2c3
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 02319a61927041cc4d3632e94c501b7277f0bda5 |
|
27-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Associate WindowToken object with only one display at a time
WindowTokens were global objects that contained windows that could
be on multiple displays. This model does not work with the
WindowContainer hierarachy as children (window tokens) can not have
mulitple parents (displays).
We now:
- Track the mapping of binder tokens to window tokens per display
instead of globally . So, you can have a binder token map to
individual WindowToken objects per display.
- WMS.addWindowToken is used to create a WindowToken that clients
can then later add windows to. However, when addWindowToken is called
we don't know the display the client(s) would like to add window to.
So, we track binder tokens that we are allowed to add window for in
the RootWindowContainer and create a window token for the binder on
a specific display when we try to add a window.
Bug: 30060889
Test: Manual testing and existing tests pass.
Change-Id: I81a52a32b01c33ed32169d2da0506b688ea9bc8a
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 9d9d8f1c0f66172d89e50e8fd12a8c2a3de221ac |
|
29-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Cleaned-up RootWindowContainer.applySurfaceChangesTransaction
- Move functionality for determining interesting and all drawn states
of an app token based on the current window we are processing into
AppWindowToken.updateDrawnWindowStates() since it is mostly touching
AppWindowToken variables. Some of the fields can now be made private.
- Removed WindowContainer.updateAllDrawn() and related overrides. We
now have RootWindowContainer collect the app tokens that need to be
processed and call them directly.
- Move code to report window move to client into
WindowState.reportWindowMovedIfNeeded().
- Move WMS.updateResizingWindows() functionality to
WindowState.updateResizingWindow() as it mostly updates window state
internals.
Bug: 31794753
Test: Manual testing and existing unit tests pass.
Change-Id: I7588217d05d3e8971ce61795cb8568d835779c5e
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 441e4494682144aec2ec7f19060464af3d29c319 |
|
30-Sep-2016 |
Andrii Kulian <akulian@google.com> |
Add override and merged config to WindowContainer
This consolidates usages of override and full (merged)
configs in WM objects and also adds support of per-display
configurations. Having full configs allows us to get
current applied config at any level.
Test: Manual tests pass. Added some new to WindowContainerTests.
Change-Id: I996770433c80da41265f3e14048bd23cead097f9
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| ba51ca2c8c100ccd5f1bb7a5f34f674b12184399 |
|
23-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed some test failure and log warnings.
- Make DisplayContent.attachStack and moveStack use the same code
path for adding child stack so they both account for the presence
of pinnded stack.
- Don't call DC.attachStack on a stack that is already on the
display. Use DC.removeStack instead to just make sure it is at the
right z-order on the display.
- Use WindowContainer.getName() when for exception messages to have
a more concise print-out for the error.
- Only try to remove a task from a stack when positioning if the task
is contained in the stack.
- Throw an exception if we try to remove a task that isn't contained
in a stack.
- Skip checking of exiting or waiting for replacement when rebuilding
window list for app tokens that are exiting.
- Properly display and intent output from WC.dumpChildrenNames().
- Have DisplayContent WindowContainer type always return true for
fillsParent() and isVisible() as displays always fill their parent
and always visible for now.
Bug: 31624623
Test: Failing test passes.
Change-Id: I8a84770feb1fd278716755cdec2900fddb9940de
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 1012458343643e899ed8ca2684380b92d73fb47b |
|
16-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Switched DisplayContent to use WindowContainer
Bug: 30060889
Test: Manual testing and existing tests still pass.
Change-Id: I99f2e38da417f62e8aa65bb6582aba53fd528c1b
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| f6192868fa4fcf85130ef40a90d0c96fbbca761d |
|
10-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Switched Task to use WindowContainer
Bug: 30060889
Test: Manual testing and existing tests still pass.
Change-Id: Ia56767e47ad3df400e3aa2650f6386cca14659a7
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| d90546abd1425873f9a8baa8e6ba6c8fa35f970d |
|
10-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Changed WindowContainer to take child type as a generic
Removes the need for sub-classes to cast the children list.
Also means the children list can only contain a single type,
but that is okay.
Bug: 30060889
Test: Existing unit tests still pass.
Change-Id: Ie880f389b8ab790ee65adcdba23b32bdb568854f
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 3f4433dadb7627153939ebb7d88d080c132b7f7f |
|
19-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made Task.mAppTokens private scoped
Also, remove TaskStack.getTask() method.
Bug: 30060889
Change-Id: I1ed9710ff630b390d28e6f2146db4202e2bc860b
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 9adfe5776d42c9ddfd4394958993304c9d355229 |
|
09-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Moved rebuilding of display WindowList to DisplayContent
Some of this is also in WindowContainer and its children.
However, I hope we can remove the concept of window list in
the future.
Bug: 30060889
Change-Id: I9e531327643c28a0ba35baa812b9c2942993d7b7
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 63d4ecc7a5c23f1ebbd3d71e5054041d90df9762 |
|
09-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Moved window focus calculation to DisplayContent
In prep. for using WindowContainer.
Bug: 30060889
Change-Id: Ide3022b3129b3d190f631a07d7589a27c434e0c3
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 5136249a7147fb205e1b861c1d42a7d1f13b73cc |
|
09-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Support for specifying orientation in WindowContainer
Also,
- Fixed failing tests when they are ran as a package vs.
individual classes due to multiple window manager instance.
- Correct some isVisible logic to so a window container that
is invisible is not said to be visible, because one of its
children is visible.
Bug: 30060889
Change-Id: I1bb8730361be2a9f5ce88cd59b7d57d5a459bde6
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 44f2180c554684d8ce015116ad057dca06bba87d |
|
02-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Introduced WindowContainer.hasContentToDisplay
We have lots of "is visible" methods and this change is an attempt
to rename one of the methods to match closer to what is actually does
and differentiate it from other "is visible" methods.
WC.hasContentToDisplay() returns true if the container or one of its
children as some content it can display or wants to display
(e.g. app views or saved surface).
WC.isVisible() returns true if the container or one of its children
is considered visible from the WindowManager perspective which usually
means valid surface and some other internal state are true.
Bug: 30060889
Change-Id: Ifbd6c277eb65a53b8035b6f34fc45196962632c1
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 571771c3fc912e63f83b75693c0f3c85ec9622da |
|
26-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added WindowContainer.removeImmediately to support immediate removal
There are 2 types of window conatiner removals. The ones that happen
immediately and the ones that are deferred until the system is in
a good state to handle them. WindowContainer and its child classes
now support both through WC.removeImmediately() and WC.removeIfPossible()
methods.
The method names create a consistency in the codebase and also makes is
obvious what the methods will do.
Bug: 30060889
Change-Id: I459c2eef17e20cefc42e9cc542c9a3c69fc9b898
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| d1c3791659572529dbc749b70d1c33bda1bdbc32 |
|
16-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Switched WindowToken/AppWindowToken to use WindowContainer
Bug: 30060889
Change-Id: Ia82aedfd9ea86410acdcd3a55a7a7fc456be2fc3
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| 9bc47736362d03b3f099bf018255571457403c1f |
|
10-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Removed child windows from WindowToken window list
With the window container hierarchy model, containers should only
link to their direct children and delegate any operation on
decendants of their children to their children.
Bug: 30060889
Change-Id: I99ca0d181d54cfe75bbe24c1b0daaa06cf7cfd9a
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|
| d63594a8d116b9fb25a031cb489ca033f716226a |
|
18-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added WindowContainer and WindowContainerTest classes.
The WindowContainer class defines common functionality for objects that
can hold windows directly or through their children
(e.g. WindowState, Task, AppWindowToken, ...). The WindowContainerTest
class as the name implies contains tests for the WindowContainer class.
Bug: 30060889
Change-Id: I1dd2c460c56cfc82aee67c033032a96843ed051d
/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java
|