| 38d44ec857a75ebc98818743d08addf81ddc923e |
|
15-Jun-2017 |
Jorim Jaggi <jjaggi@google.com> |
Remove snapshot when screen gets rotated in mean time
We also need to wait for windows that are not gone for layout, as
otherwise we'd unfreeze before the surface is actually created.
Test: go/wm-smoke
Test: Open Camera in landscape but home screen locked to portrait
Change-Id: I0fc7a016445e18af1eead292665702b768b4e95b
Fixes: 38261533
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 486bbb73c8190e6b377ea0bdf6b598503f3b0d04 |
|
30-May-2017 |
Robert Carr <racarr@google.com> |
Prevent unnecesary Surface preservation.
We don't save the Surface's pixel format, and so any time
there is a change in the pixel format as described in the params
we trigger a surface preservation. However if an app is switching
from forced translucent (due to HW accel) to explicitly translucent
even though the layout params have changed we don't actually need
to trigger a format change, just toggle the OPAQUE flag.
Bug: 38324871
Test: Launch Chrome Custom Tabs with Lateral Transition Animation from News and Weather App. No black bars. go/wm-smoke
Change-Id: I2151b4470fd7c395fba7aad7d6ffca4c51e55476
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e4b0f28a47097b7b0c04f3ae80507e2a15e3314f |
|
17-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Enable starting window logging
Also extend it to make sure we catch the bug!
Test: Open a couple of cold/hot apps, make sure logs look accurate
Bug: 37888853
Change-Id: Ied394969748d4d2d40359af15e0b491a2dc2b078
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 99fbd00ac595a3783b2cbadd6eb28a32426ed098 |
|
16-May-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix interaction of magnification and Final-crop." into oc-dev
|
| ef090ac32df0f9fbf0300c343dbb733f281569d4 |
|
16-May-2017 |
Robert Carr <racarr@google.com> |
Fix interaction of magnification and Final-crop.
In the case of magnification we simulate a transformation to screen space
by transforming all windows with the MagnificationSpec values. This means
we need to transform other values which are in "real screen-space" as well,
like final crop.
Bug: 36129852
Bug: 38322835
Test: Manual
Change-Id: I3215ffb75ba66a29135a79bcb23da51c828739fc
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| f5b6818009a70d77a272ca9b7b2aa167507dfd07 |
|
16-May-2017 |
Rob Carr <racarr@google.com> |
Merge "Preserve non-floating state when entering pinned stack." into oc-dev
|
| 027f4753bcdbef5a830ed877f974701727e98d19 |
|
12-May-2017 |
Wale Ogunwale <ogunwale@google.com> |
Fixed exceptions during test tearDown
- Acquire WM lock when tearing down test. Prevent the handler thread
from modifying state at the same time.
- Don't set surface boundaries on window states without a surface
control.
- Avoid exception if process can read screen-edge-insets for Pip.
Change-Id: If4a2438032866eaec84ed79c30c1d716e0f89758
Fixes: 38113905
Test: this is it!
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 18f622f08ce84bfb1a6cf19bca33d3ef0ad4aca9 |
|
08-May-2017 |
Robert Carr <racarr@google.com> |
Preserve non-floating state when entering pinned stack.
When transitioning between the fullscreen and pinned states
we often have a situation where we go from having a navigation and
status bar in the window to not. We'd like to use the source bounds
animation to crop these out rather than a sudden jump or scaling
but in order to do so we need to ensure they last until the end
of the animation. We track this state, and return the appropriate
value from isFloating. Furthermore, we add support to the bounds
animation to use the content frame as a source bounds when there
is no source bounds present, this means that we can crop out the
navigation and status bar so they will be invisible by the end of
the animation.
Bug: 37531386
Test: Manual
Change-Id: I72c549e3a3318534428d17b68ebee5832c32e6d7
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 002c8e1f58714660750779688ac8bc1957cc7347 |
|
28-Apr-2017 |
Robert Carr <racarr@google.com> |
Fix cropping in docked stack.
In some cases in the docked stack we end up using the final crop,
but we need to be careful not to expand it for the SurfaceInsets like
we do for floating tasks.
Bug: 36238776
Test: Manual from bug
Change-Id: Ieb51d9f4b1b9aa01523dd41a1c54b6d526488b40
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 89a28ab018d5ee3e16c99f2d5b4f4f8e05ca6125 |
|
25-Apr-2017 |
Robert Carr <racarr@google.com> |
WindowManager: Take care with Surface lifetime during relayout to invisible.
In the relayout to invisible case where we choose not to apply an exit
animation, we would call to WindowState#destroyOrSaveSurface bypassing
the app stopped check. Notice WindowManagerService.java L1953 we could
enter the relayout to invisible even if the client has not requested it
if clientHidden were set to true (but not yet processed by the client). This means
we can destroy the surface ahead of any notification to the client. We instead
need to use the WindowState#destroySurface variant
and respect the app token mAppStopped flag. #destroySurface expects
mDestroying to have been set by the exit animation, so we will also need
to set that. If destruction is deferred, it will be completed later by
AppWindowToken#notifyAppStopped
Bug: 36561071
Bug: 37533373
Test: Manual from repro in bug.
Change-Id: If91b4c75fdbcbf87007551860f9eb64dbec9e032
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| ecc06b32305ac234db24e3f76bcae0199b80c395 |
|
18-Apr-2017 |
Robert Carr <racarr@google.com> |
Delay PiP transition to fullscreen until activities draw.
To avoid awful stretching.
Bug: 37473110
Test: Transition app fullscreen verify no awful video stretching.
Change-Id: I810a72207e45b8f83a63c9f0b3cc9a433569852c
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 8bca9e47c17c86a3092d5384b14713c5b50dd78c |
|
17-Apr-2017 |
Winson Chung <winsonc@google.com> |
Schedule PIP mode changes at the beginning/end of the transitions.
- When transitioning from fullscreen to PiP, ensure all PiP/MW/Config
changes come after the transition completes, and inversely, from PiP to
fullscreen, ensure that all changes come before the transition up starts
- Add a series of tests to verify the callback state when the animation
is canceled
- Also fixes an issue where the surface is preserved when we don't want
Bug: 37169080
Bug: 37103000
Test: bit FrameworksServicesTests:com.android.server.wm.BoundsAnimationControllerTests
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: I6425c95df358358ed76d9cc8a130606c2124062e
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 40a5f935acea488086ea1b6df7d5d09e74ea518f |
|
14-Apr-2017 |
Winson Chung <winsonc@google.com> |
Fixing animating bounds regression.
- Prior to ag/1954388, we used getAnimatingBounds() to get the final target
bounds if animating or the current otherwise, but since we needed the
target bounds to calculate the window scale even after the animation
completes, the clearing of mBoundsAnimationTarget was removed.
This inadvertently broke the check in getAnimatingBounds() from ever
returning the current bounds (as it's never empty)! This CL fixes the
issue, and renames the related methods to better reflect what they are
doing going forward.
This caused a regression when calculating and notifying SysUI of the
movement bounds, which was never the current bounds, but the default
bounds. Leading the IME change to trigger the PIP to move down.
Bug: 37242422
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: Source hint rect animation still works
Change-Id: I532b0928ebfeaf95e9754a0254306af6fbb35833
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| af422a8c5b902831cbd2c97c71bbeed71604dd2e |
|
11-Apr-2017 |
Robert Carr <racarr@google.com> |
Stack APPLICATION_MEDIA_OVERLAY windows with relative layering.
See accompanying frameworks/native commit
"SurfaceFlinger: Add parent-less relative layering" for a full explanation.
Test: Manual of bug repro steps. Plus tests for new SurfaceControl functionality included in frameworks/native.
Bug: 36693738
Change-Id: Ic54598117c1f44a206d33f03d0cc463fbef43fcc
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 2b33162e82ba0c0d4af45c1c73157745a0adc061 |
|
30-Mar-2017 |
Rob Carr <racarr@google.com> |
Merge "Remove code for seamlessly rotating SurfaceView's." into oc-dev
|
| da61ba9d4e6a826a4921e3a9c69e46a9497f891d |
|
30-Mar-2017 |
Robert Carr <racarr@google.com> |
Change layer stack when moving displays.
Previously we only change layer stack when creating a new surface.
This isn't enough for moving existing activities between displays.
Test: Try moving existing activity to new display.
Bug: 36002411
Change-Id: I536f26cba43fc4fd1b60c8b504355076e2fb162e
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 897215d76ae2e7cbca63a505113f5d90ef892d81 |
|
29-Mar-2017 |
Robert Carr <racarr@google.com> |
Remove code for seamlessly rotating SurfaceView's.
No longer required :D
Bug: 36230754
Bug: 36727915
Test: Rotate camera in different modes.
Change-Id: I7708d61646a36bc0c35cfa91d441296eb49eff9a
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 08f81890bc70a0c8f4d25817a1dd0c93f8927e78 |
|
03-Mar-2017 |
Winson Chung <winsonc@google.com> |
Adding source bounds hint to support better PiP transition.
Bug: 35396882
Test: Start a transition with source bounds hint.
Change-Id: I4897242af84744bc05a093111a15ea52e49815e8
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 6914f0838e460666e9ec260213e1feb6aa7443dc |
|
21-Mar-2017 |
Robert Carr <racarr@google.com> |
Fix various flashes when moving stacks.
In this CL we fix two new pinned stack reparenting flashes and
implement a new approach to an old docked stack flash fix, which had
been broken in refactoring.
First we examine the case of dismissing the docked stack and
WindowState#notifyMovedInStack. Previously we invoked this
when reparenting from the docked to the fullscreen stack
(by way of position in stack). It was used to solve an issue
where we were visually hidden by the docked stack crop, but we were
still waiting on an animation pass to set the hidden flag. Our old solution
was if mJustMovedInStack was set, we would just defer updating our crop until
one animation pass had occurred.
We broke this incidentally in refactoring by not calling the
method that sets it anymore. However it's somewhat brittle so I was
hesitant to restore it. The fundamental requirement is for the
ActivityManager to perform multiple operations (change stack, update
visibility) in a single atomic step and this wasn't expressed clearly.
This mirrors some challenges we have with the pinned stack transitions
as well.
1. When dismissing the pinned stack, we move the task to the
fullscreen stack. We need a mechanism to prevent its bounds from
updating before its visibility is updated.
2. When moving to fullscreen while over home, we have layering issues
with the home stack, as we will be moved to the fullscreen stack before the
fullscreen stack is brought to the front of the home stack. This may
not seem like a visibility issue, but if the home activity were simply
hidden the layering wouldn't matter!
Evidently, all three of these issues can be solved with a batching
mechanism from ActivityManager to WindowManager. As all changes are
ultimately Surface changes, SurfaceControl.open/closeTransaction
provides such a mechanism. The only additional complication is that
normally visibility updates on SurfaceControl are deferred to the
animation thread, which may not execute within the bounds of our
transaction. This however, is easily dealt with: In AppWindowToken, if
we are becoming hidden without animation, then we simply apply this
change without waiting for the UI thread
Bug: 35396882
Bug: 34857388
Bug: 36393204
Bug: 36462635
Test: Intensive manual testing of dismissing docked and pinned stack + pinned->fullscreen transition.
Change-Id: Ic110797670cc7ff656a580fd186d4deb44fa54dd
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| d5c7dd6da810a6b89151b337bea79fd817e6b72a |
|
08-Mar-2017 |
Robert Carr <racarr@google.com> |
Modify SurfaceView to use SurfaceFlinger child surfaces.
Here we have SurfaceView bypass the WindowManager and speak
directly to SurfaceFlinger using child surfaces. We also
implement some logic in the WM to handle child surfaces
in various Surface replacement scenarios.
For those following along in the revert Saga, this
also includes the follow up CLs to the original CL.
- Surface inset calculation
- Animation fixes.
The error causing the revert was an incorrect JNI signature
around deferTransactionUntilSurface. I've noted it inline.
Bug: 28858420
Bug: 31518219
Bug: 34888808
Bug: 35588318
Bug: 35396882
Test: Existing tests still pass (except for the ones that don't and will be deleted).
Change-Id: Ie56b6f7ab16f32d7fc459b8eba26594337ad55de
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 5aec7b90310ba05f9816fd89030ba41ce48c568e |
|
08-Mar-2017 |
Wonsik Kim <wonsik@google.com> |
Revert "Modify SurfaceView to use SurfaceFlinger child surfaces."
This reverts commit cd4aeef88052571365d4e193a2c41e2e6d145491.
Bug: 36027342
Bug: 36015884
Change-Id: Ifd5b69caf64d65a8cd6570b7fe1fb6abe90e30b8
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| cd4aeef88052571365d4e193a2c41e2e6d145491 |
|
03-Mar-2017 |
Robert Carr <racarr@google.com> |
Modify SurfaceView to use SurfaceFlinger child surfaces.
Here we have SurfaceView bypass the WindowManager and speak
directly to SurfaceFlinger using child surfaces. We also
implement some logic in the WM to handle child surfaces
in various Surface replacement scenarios.
For those following along in the revert Saga, this
also includes the follow up CLs to the original CL.
- Surface inset calculation
- Animation fixes.
The error causing revert was a deferTransactionUntil(-1)...-1
cast to uint, defer transaction until MAX_UINT.
Bug: 28858420
Bug: 31518219
Bug: 34888808
Bug: 35588318
Bug: 35396882
Test: Existing tests still pass (except for the ones that don't and will be deleted).
Change-Id: Ib37236950a1dd3c4f9f4b58fd41ef9003c0557ef
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 3896db14751f16f4053e8fa4a82c3d6803054e5b |
|
03-Mar-2017 |
Jeff Tinker <jtinker@google.com> |
Revert "Modify SurfaceView to use SurfaceFlinger child surfaces."
This reverts commit 693f3432ae77d1fcfaaf9d168de861192aacb4c4.
P0: When playing encrypted content the Fugu displays a blank screen.
Test: with topic "surfaceview-without-wm" reverted, encrypted playback
works on ToT oc-release. See repro steps in 35917840#12.
bug:35917840
Change-Id: I37fa1e427daff3a1c18ed1c92d035421d891f67c
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 693f3432ae77d1fcfaaf9d168de861192aacb4c4 |
|
19-Dec-2016 |
Robert Carr <racarr@google.com> |
Modify SurfaceView to use SurfaceFlinger child surfaces.
Here we have SurfaceView bypass the WindowManager and speak
directly to SurfaceFlinger using child surfaces. We also
implement some logic in the WM to handle child surfaces
in various Surface replacement scenarios.
Bug: 28858420
Bug: 31518219
Bug: 34888808
Bug: 35588318
Bug: 35396882
Test: Existing tests still pass (except for the ones that don't and will be deleted).
Change-Id: Icb7259365b51ebe8c7f6c7cd4f9ba29f9fce08a4
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 0edf18f34c4dc81e45580bc0a3b3b9b072caa725 |
|
22-Feb-2017 |
Robert Carr <racarr@google.com> |
Correct SurfaceControl matrix parameter names.
DsDx is used for the X scale but DtDy is used for the Y scale, it
seems like this is a simple mix up. Correct before documenting
SurfaceControl.
Test: Animations and such work.
Change-Id: Ic52b67596bf576f58346e4db66661b06ea1bdc2f
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 8f0a3ad8c7ee6495eba8c0b6ddae42ca48403f56 |
|
16-Feb-2017 |
Robert Carr <racarr@google.com> |
Pinned stack animation: Prevent window preservation during animation.
When moving to the fullscreen stack, we were triggering the
resized while not drag resizing logic, causing a window preservation
in the middle of the animation.
Bug: 35396882
Test: Move skeleton pinned app between states. Verify no freezes or size jumps during animation.
Change-Id: I4a72945742241b3a039b997a8da6aba89e935346
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 47eddecc533e4655828885d47acb7e7e8421c9a8 |
|
16-Feb-2017 |
Robert Carr <racarr@google.com> |
Pinned stack animation: Correct scaling calculations.
Previously we were scaling to the clip rectangle which included the Surface
insets. When we changed to scaling to the stack bounds, we didn't update
this code, and reversed the insets in a situation they weren't applied.
Bug: 35396882
Test: Move skeleton pip app from fullscreen to pip, ensure it reaches correct final size without jump at end.
Change-Id: If2dc272f40f90383e35d509f7220c21e0e0be5b1
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 7f7b84794bcd0df6f0524bac10772213c68091d9 |
|
16-Feb-2017 |
Robert Carr <racarr@google.com> |
Pinned stack animation: Also clear finalClipRect.
The code calculating it doesn't understand our scaling of Surface insets
and so it clips us too small. Since we scale to the stack bounds anyway
there is no sort of "draw over other apps" risk.
Bug: 35396882
Test: Move skeleton pip activity between states, ensure there are no cut off portions during animation.
Change-Id: I973db1879dd588d829e3fe828e9350f2647cdc2c
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 34a06d148ec0218a5e065b7b9c7cf338c3d20df6 |
|
03-Feb-2017 |
Matthew Ng <ngmatthew@google.com> |
Revert "Fix window transformation related issue"
This reverts commit 867210c1de62e533880da7ac64b8eaa837e6ed6a.
This commit is being reverted because the logic it tries to fix does not
make sense and caused a regression causing all animation positions to be
offset incorrectly but applying the animation metrics before applying the
window offset (mainly for bottom screen in multiwindow). The original
case this tries to fix is for older apps like gallery2 which crashes
(ramdump) when trying reproduce the steps.
Fixes: 34769878
Test: ran original case that this tried to fix and played with recents
related to the new bug it created
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| fd4c9891f332292e3116b913b2a0c5e8e2273c43 |
|
01-Feb-2017 |
Robert Carr <racarr@google.com> |
Scale PiP to stack instead of crop.
When changing stacks the finalCrop or crop may not be set
so relying on either one for the scaling factor is error prone.
Just scale to the stack size. I initially avoided this because I
thought some of the crop code may be relevant in computing the size
we wan't...but I'm now pretty sure it won't.
Test: Expand PiP back to fullscreen on phone, verify no crash.
Change-Id: I172daade74bec7374b5fd3310c1bf554e46d8832
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| f9a880ae0898ffc25a15f161d5a7dc871aef21a7 |
|
01-Feb-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix PiP animation errors introduced in crop refactoring."
|
| 8e7be8e808b0e7f27e745985c4f3672437f3ee2f |
|
31-Jan-2017 |
Robert Carr <racarr@google.com> |
Fix PiP animation errors introduced in crop refactoring.
Firstly, pinned stack now uses final crop only, so we need to scale
to the width/height computed there, not as computed for the crop.
Furthermore mTmpClipRect is no longer used directly to set the crop,
so clearing it in the pinned animation code had no effect. This fixes
the worst of the visual errors so people stop filing bugs while I
rework this logic entirely.
Bug: 34823229
Bug: 32881014
Bug: 33245930
Test: Manual with PiP activities on Fugu.
Change-Id: I45d2def5138f3cc278408a9209b5e5c40cece80b
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 3bf2e57f8d8823f02c4e1d7bc954c4ed7c68ab84 |
|
22-Nov-2016 |
Albert Chaulk <achaulk@google.com> |
Propagate surface type and owner through to SurfaceFlinger.
This allows VrWindowManager to identify things like permission
dialogues in the list of SurfaceFlinger layers that show up while a
VR application is running and display them without leaving VR mode.
Bug: 30984984
Test: Run VR application, request permission at runtime, observe and
accept permission in VrWindowManager without leaving VR mode.
Change-Id: I347313b5fcd08dea3cd6fddfaeb15640938e3a87
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| ba41f4b9e3629c097cdd7b6538c5bcf4602728b8 |
|
15-Dec-2016 |
Jorim Jaggi <jjaggi@google.com> |
Clean up starting window to prepare for saved surfaces
- Move all starting window logic to AppWindowContainerController
- Use startingView to hold any kind of contents for startingWindow
- Remove some conflicting code which looks very old and doesn't
apply anymore.
Test: Make sure starting window still works.
Bug: 31339431
Change-Id: I018dd013ab7e64a44932b6d54ae9bb4a47f315d3
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 1bdb5e2442f9b3e34809441ff2e8e212b4286453 |
|
27-Dec-2016 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Fix window transformation related issue" am: 8760e60da5 am: 1200cfb48d am: a4a4cfc8f5
am: 8d4fa7f6b6
Change-Id: Icd2d42a026c4f514cc3efbd5883fcf4a0ee7d0e2
|
| 8760e60da528ed0dd1a956bb13b2c9e2e76afc82 |
|
27-Dec-2016 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Fix window transformation related issue"
|
| ca9e061256861a86d7d1c2770c666451d3fb53de |
|
02-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Allow some app windows to display above the IME.
- Display child windows of the current IME target above the IME.
- Display app windows above the current IME target above the IME.
Regression in the functionality was introduce in
I6f8bf15ba246fac69c4a496ebb1d9e0b9b6a95a2 when we switch away from using
the window list for z-ordering and using the hierarchy which has the IME
above all app windows.
Change-Id: I399aab7fd5ad7327ef6bc29d48f6d9bf48a6ac6c
Fixes: 33128382
Test: bit FrameworksServicesTests:com.android.server.wm.WindowLayersControllerTests
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| fbbde85b045dde25450ce5cef075934102e28339 |
|
18-Oct-2016 |
Robert Carr <racarr@google.com> |
Some cleanups for window cropping functionality.
At a high level I had two sorts of goals:
1. To remove the weird pinned logic in setSurfaceBoundariesLocked
2. To seperate base crop calculation, and animation exceptions, between
window state and window state animator.
Itemized changes are as follows:
1. Rename updateSurfaceWindowCrop and calculateSurfaceWindowCrop to
applyCrop/calculateCrop. It doesn't feel that "SurfaceWindow" was
adding much.
2. Split screen space and window space (final v non) clip rect
computation, to make clarity about when each one should be used.
3. Eliminate weird case for pinned stack in setSurfaceBoundaries by
building it in to calculateFinalClipRect.
4. Extract calculateSystemDecorRect to WindowState as it mostly accesses
window members.
5. Extract part of calculateCrop to WindowState as
"calculatePolicyCrop". This was the part that fills mSystemDecorRect.
6. Extract wallpaper animation logic outside of calculatePolicyCrop
Test: bit FrameworksServicesTests:com.android.server.wm.WindowFrameTests
Change-Id: I8ff1dc6ec1206a34994f50ba44d765ab619efbff
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.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/WindowStateAnimator.java
|
| 0303c5723edfdb4f2db37543544d7cbe9b14df97 |
|
20-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Have DisplayContent be the call point for adjusting wallpaper windows
4th step in trying to make the WindowList private to DisplayContent
Have the rest of the system call DisplayContent when they need to
adjust the position of the wallpaper windows in the window list
instead of calling WallpaperController directly. That way the display
content can control the window list that the wallpaper controller sees.
Test: Existing tests pass and manual testing.
Change-Id: Iaa7f421d7cd24d36e5a83e091f77b4a08d0ae123
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| c69694abbdbfa3f0bedb034e7cc86823a72ff781 |
|
18-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Have DisplayContent be the call point for assigning window layers
First step in trying to make the WindowList private to DisplayContent
Have the rest of the system call DisplayContent when they need to
assign layers to windows instead of calling WindowLayersController
directly. That way all the various call points don't need to get
the WindowList from DisplayContent to pass on to WindowLayersController.
Test: Existing tests pass.
Change-Id: If869abf7ba1c33b575908006ae5ad1557abc361c
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 867210c1de62e533880da7ac64b8eaa837e6ed6a |
|
14-Oct-2016 |
Qiushi.Han <qiushi.han@spreadtrum.com> |
Fix window transformation related issue
In some cases, for example, a window containing a SurfaceView,
when pressing switch button, the window animation of SurfaceView
and it's attached window are not sync, which leads animation not
behaving correctly.
To avoid this, apply the translation that applies the position
of the window before the app transformation.
Google issue:
https://code.google.com/p/android/issues/detail?id=225134
Change-Id: Ie8ddb875e895942c7f28e6fc83c4f92568512efb
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| d2753b5478690db844d33f774bbbf290731aaa4a |
|
13-Oct-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix bounds rotation logic"
|
| 4dfb9c4bbb014ac4625dcae419b212d00f541ef0 |
|
12-Oct-2016 |
Andrii Kulian <akulian@google.com> |
Fix bounds rotation logic
Reuse code that computes window bounds for seamless rotation in
DisplayContent#rotateBounds. Also make sure that we operate with
display rect adjusted for the requested orientation.
Bug: 31005451
Bug: 29586417
Test: Tests in ActivityManagerAppConfigurationTests pass.
Change-Id: I921ec184c9eaad6dbd15ac3e0def1f5e623a363e
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.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/WindowStateAnimator.java
|
| 255bc6a4afba98a10c0fe6641c089f1a2629992d |
|
11-Oct-2016 |
Andrii Kulian <akulian@google.com> |
Fix bounds rotation logic am: 781240d9bb
am: 7778de938a
Change-Id: I63e892677234e6b79f2d9dc3f2aa8729da46561e
|
| 7778de938a311637850cd1857195a33356cc7e39 |
|
11-Oct-2016 |
Andrii Kulian <akulian@google.com> |
Fix bounds rotation logic
am: 781240d9bb
Change-Id: I64a81112b8384a3281cde20bf0f4a6e1628d746c
|
| 9538380376d301d126d5aedd830868622cb32559 |
|
08-Oct-2016 |
Colin Cross <ccross@android.com> |
resolve merge conflicts of 5e664d9 to master
Test: mm -j
Change-Id: I86391311447efdfac47d2d33425dae7ea3057fd1
|
| 5e664d99574aad35f498b80cb5847e1801b9c834 |
|
06-Oct-2016 |
Robert Carr <racarr@google.com> |
Prevent any rotation while seamless rotation is pending. am: b14d4abc16
am: eb461fca5a
Change-Id: Id88cf66355fccf6d141f7177f4323124efec7e9c
|
| 781240d9bb2f8988c7f16c30540a87888d8a505d |
|
05-Oct-2016 |
Andrii Kulian <akulian@google.com> |
Fix bounds rotation logic
Reuse code that computes window bounds for seamless rotation in
DisplayContent#rotateBounds. Also make sure that we operate with
display rect adjusted for the requested orientation.
Bug: 31005451
Bug: 29586417
Change-Id: Ie18ac2c84c7a3ea474e00e7108c3b3c21114e719
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| b14d4abc16ec7dd48737ab829e3f84b12017db7c |
|
04-Oct-2016 |
Robert Carr <racarr@google.com> |
Prevent any rotation while seamless rotation is pending.
Various errors occur when using even the normal rotation animation while
seamless rotation is pending. So we just defer the rotation like we do
for the normal animation. Since we are doing this, we need to track
when seamless rotation finishes so we can perform a post-rotate
rotation if required.
Bug: 31749456
Change-Id: I99f189306c690ce868496460e9ca7dcc95e4ccdc
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 43d846aeead1228dc71fb6fa5c22232b84e29558 |
|
04-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Fix window animation flash issue" am: 1a02a26838 am: bb5f6db56a am: 63993f20a4
am: b3ec06630c
Change-Id: I4ce2edb5ad4154676adf58f13447ffd19159d67e
|
| b3ec06630c52258feb2733783fff444556e54cc4 |
|
04-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Fix window animation flash issue" am: 1a02a26838 am: bb5f6db56a
am: 63993f20a4
Change-Id: I4b9d03bd48c6fb4a676c8ef3746fd757eb1f3943
|
| 32fed96632f6216ff5ec983a1aa13bdb2117c3c8 |
|
01-Oct-2016 |
Qiushi Han <hanqiushitju@gmail.com> |
Fix window animation flash issue
The original logic cuts down the mShownPosition, causing 1 pixel offset,
sometimes this will cause flash.
To fix this, Use Math.round() instead.
google issue:
https://code.google.com/p/android/issues/detail?id=224185
Change-Id: I8a2fe55a2df6eaa9eda4ba78966a74ea492ab8ea
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 2b06bfc6e90aa293c7058fc6b1d1cf22fbb2ada2 |
|
28-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made DisplayContent.mLayoutNeeded private scoped.
And, added accessor methods for it to make it easier to
debug who is setting it.
Bug: 31794753
Test: Existing tests pass.
Change-Id: I517c3e5cc7535cb90c47c112d42fa1dbf0b81583
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e05f5014905569d69d33ff323a3c62c046552789 |
|
17-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added RootWindowContainer
RootWindowContainer will be the root/head of the window hierarchy.
Also, moved all access of DisplayContent into RootWindowContainer.
Bug: 30060889
Test: Manual testing and existing tests still pass.
Change-Id: Icdf80a4c053578fb91221e6f2b672e197054a6bf
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.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/WindowStateAnimator.java
|
| 68e5c9e93a8f1542cd988ac01ba1d98381ff4893 |
|
14-Sep-2016 |
Robert Carr <racarr@google.com> |
Log transaction state to RemoteSurfaceTrace.
Test: cts-tradefed run singleCommand cts -o --module CtsWindowManagerHostTestCases --test android.server.cts.SurfaceViewMovementTests#testSurfaceMovesWithParent
Change-Id: I2aeda867f0071bf6ac715153ab842a9f16cafa44
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 3b716249cc2f94aa9842576b618998c28593be90 |
|
17-Aug-2016 |
Robert Carr <racarr@google.com> |
WindowManager RemoteSurfaceTrace infrastructure
Add "wm surface-trace" command which enables tracing of surface
commands to be switched on at runtime. Primarily intended for use
by WM CTS tests. First target in CTS will be to use show/hide
events to eliminate polling in WM tests and increase speed. Next up
looking at things like verifying various transitions and relaunch
scenarios are flicker free. Later we may want to look at a smarter
or more structured format...but it's really not much hassle to parse
the commands off a pipe so I wanted to get us started.
Test: cts-tradefed run singleCommand cts -o --module CtsWindowManagerHostTestCases --test android.server.cts.SurfaceViewMovementTests#testSurfaceMovesWithParent
Change-Id: I1ff912c405a6cb9996ee9b6e2c465d57706191ba
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 24ad15ecee1c4e453b74bc432534a0a3649ca48d |
|
09-Sep-2016 |
Robert Carr <racarr@google.com> |
resolve merge conflicts of 6540c23 to master
Change-Id: I9557b4f7aae5bb64d256da26a290b326f39c9104
|
| 5dc3f284bd4d4163738a5d133448a9193595fde3 |
|
08-Sep-2016 |
Robert Carr <racarr@google.com> |
Remove reuse of pending deferred transactions.
Only defer transactions originating from repositionChild. There is
no guarantee the frame we are suggested to synchronize to will ever
arrive and synchronizing WM originated transactions to this can
interfere with implementation of system policy. Anyway this code
originally was fixing a case where transactions pushed by pulling
down the notification shade, would interrupt animating SurfaceView's
by pushing an undeferred transaction for those SurfaceView's. This
doesn't seem to be occuring anymore even without this code. Furthermore
even if it was occuring, we should prevent transactions from pushing
updates for Surfaces where nothing has really changed, rather than
attempt to chain the deferred transactions.
Bug: 31293950
Bug: 27098060
Bug: 28858420
Change-Id: Ifb83fe78bb4e7d18376e53a743709648aa1e03bc
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.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/WindowStateAnimator.java
|
| 71896dcea1975fdea6ef4d7036824cfde2a06ef9 |
|
13-Aug-2016 |
Robert Carr <racarr@google.com> |
Fix build break due to merge.
mAttachedWindow was refactored away.
Change-Id: I4706b2ccf3418511ba91af63e29585519a99770b
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 481ba560d2d68c1c2046ef3ecb8779f4d398d7e9 |
|
13-Aug-2016 |
Robert Carr <racarr@google.com> |
Fix NPE in deferToPendingTransaction. am: c24078f1a2 am: 885452fe7c
am: 409484440c
Change-Id: Ia7494ade982bcc0eec871cea6c0cd8b930602283
|
| 80f585897fbaa268f2b08777bff9e4f3a7d45437 |
|
13-Aug-2016 |
Robert Carr <racarr@google.com> |
Account for scaling of surfaceInset area in magnification. am: 298f9278fd am: b207428305
am: 23f27428f2
Change-Id: Ice16e3fcaf22faa41b80020d1b1bd8e7694d38be
|
| 885452fe7cd2e99ebc92f56a9cf0520a78ee359a |
|
12-Aug-2016 |
Robert Carr <racarr@google.com> |
Fix NPE in deferToPendingTransaction.
am: c24078f1a2
Change-Id: I9755399b591ab66e35884bdd37432a2350ad68e0
|
| 4a86fbc4d9500c8a85c534f239c8fb415b0def50 |
|
12-Aug-2016 |
Rob Carr <racarr@google.com> |
Merge "Fix NPE in deferToPendingTransaction." into nyc-mr1-dev
|
| c24078f1a2500dd7227b8be556999968ba51c24b |
|
11-Aug-2016 |
Robert Carr <racarr@google.com> |
Fix NPE in deferToPendingTransaction.
Just because a child window has a surface doesn't necessarily
mean the parent window will have a surface. destroySurfaceLocked()
only takes care of setting mAttachedHidden so the child surface
will be invisible, but it may not be destroyed until a later point.
Bug: 30813094
Change-Id: Idb1b03fd61a7537ebfe33bafc93f278c0e6751f4
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 298f9278fdcdbadf83f67f277992ff8b2fda8e99 |
|
09-Aug-2016 |
Robert Carr <racarr@google.com> |
Account for scaling of surfaceInset area in magnification.
We don't want to scale the actual size of the surface as we
were doing prior to ag/1101405 but we do need to adjust the top
and left corners so that the content will be at the same position
despite the inset area being scaled up.
Bug: 30399709
Change-Id: I30df4d3ef593d4f2869fdf378ee9bc3469619d5d
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e4da0c145e89274f98c683d4e045644400ea1a18 |
|
29-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made WindowToken.windows protected.
Pre-clean-up before switching class to using WindowContainer.
Bug: 30060889
Change-Id: I2a0c09e99b742fa32e9cbe96e3bf97e5415da2c3
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| caa53afa0cae85a69da1b5bfb9b8368b152c917b |
|
17-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made WindowState.mParentWindow private scoped.
Bug: 30060889
Change-Id: Ic1d702cb6329fb2f03d006939f5610681d1d07bd
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| adde52ee32b656bb436f7e92f39f7d0d97cc9306 |
|
16-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made WindowState.mChildWindow private scoped
This involved:
- Moving method that operated on mChildWindows and mostly touched
WindowState fields into WindowState class.
- Creating new methods for getting information about child windows
outside WindowState class instead of accessing the child list directly.
- And, tests ;)
Bug: 30060889
Change-Id: I339cecb926b44b5db7ead1970e356304d5429c8f
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 9d14790d299d1e2b96db287601c86f82850019c9 |
|
16-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Track hidden state of window in itself vs. all child windows.
It makes the code easier to follow if the hidden state of a window
is tracked in itself vs. all chils windows. Child windows can call
WS.isParentWindowHidden to get the hidden state of their parent window.
Also, moved the performShowLocked method from WindowStateAnimator to
WindowState since most of the fields modified in the method belong to
WindowState.
And, don't forget the test for the change ;)
Bug: 30060889
Change-Id: I5be13b936a2284fd8fe10218b80fe41cc197d1a7
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 7ed4d37b74850e2ed5dfd50109dc6fa919904c7c |
|
10-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Rename WindowState.mAttachedWindow to WindowState.mParentWindow
Helps with code clarity and reduces confusion for upcoming WM
object modeling changes.
Also, along the same lines changes locations that check to see if
WS.mAttachedWindow wasn't null to determine if the window is a child
window to use WS.isChildWindow method instead.
Bug: 30060889
Change-Id: I9b975ab9ff9bf09cdd3c0dcaddd3bf9232e88be8
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 8784be6fe485939c3ae758edbcbbcb85d2b123ae |
|
29-Jun-2016 |
Chong Zhang <chz@google.com> |
Add a few trace points for animation loading.
Also make sure focusMayChange is set as before commit 8c5d42.
We only want to skip the applyAnimationLocked if animation is
already set, make sure the rest are equivalent.
bug: 29405575
Change-Id: I8342b82d9e6e02fab002e16ffcde4a7479bf6867
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 3ccc52731523dfa26948dfacdda48a19a70b1e4f |
|
21-Jun-2016 |
Robert Carr <racarr@google.com> |
Enable resize during relayout fix for all stacks.
Follow-up to ag/1080938/. Brought in now as the scenario occurs
quite frequently during unfrozen rotation.
Bug: 28559097
Change-Id: I78d116ea61f5737458f22c6743540a66ae804dd0
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 6da3cc0237d2483ead16a7013d1326bccc5112af |
|
17-Jun-2016 |
Robert Carr <racarr@google.com> |
Implement seamless rotation mode.
Add a rotation mode which does not require freezing
the screen. For situations like Camera where only small
elements move on screen, this allows for seamless changes
of display orientation. This is achieved by transforming the
windows with their current buffer in the same transaction that
we rotate the display. We set things up so the windows are
frozen this way until they submit buffers in the new orientation.
There is a special case in the Camera window itself, and it's use
of NATIVE_WINDOW_TRANSFORM_INVERSE_DISPLAY. In this case the buffer
contents are rotated by SurfaceFlinger and will never resize, for these
windows we just need to update the scaling matrix.
Bug: 28823590
Change-Id: I52dc6a86fcb3c08f736f0977ba3975a24fb8136c
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 4320d33a065173dff97ddb462c8a6a0a649a41e5 |
|
11-Jun-2016 |
Robert Carr <racarr@google.com> |
Restore setCropInTransaction HiddenForCrop behavior.
Prior to c/1106850 setCropInTransaction hid the surface
for crop width and height <= 0. That CL allowed
setting -1 for crop width and height which SF
determines as clearing the crop. Other portions of the code
depend on the old behavior though for negative values, so restore
the behavior of setCropInTransaction and use a new clearCrop
method for the new code.
Bug: 29276588
Change-Id: I728666009c362ff635c7ebfb3ef2e83428fb03fe
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 4663b4e806c1e35dee385bfc1cf6a1f069a5b0b3 |
|
10-Jun-2016 |
Phil Weaver <pweaver@google.com> |
Merge "Stop magnifying surface insets." into nyc-dev
|
| a9408d4a4809dd229fb7fb8f9594cb6db4b1da64 |
|
03-Jun-2016 |
Robert Carr <racarr@google.com> |
PiP animation: Move window with resize when ending animation.
At the end of the animation (when going from larger to smaller),
we are left with a scaled surface, that we want to seamlessly
resize to an unscaled surface of the new size. Because we have scaled
the shadow region of the surface, the position of the content
will differ before and after the resize applies. We use new
SurfaceFlinger API to cause position updates to apply after
resize. Because we have to switch into SCALING_MODE_FREEZE,
we could end up prematurely cropping the window, so we
switch to using screen space crop for the pinned stack.
Bug: 28899837
Change-Id: I9b762a237413e4fa3d432e67d30c7125bfef484c
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 0409211e7f993bb793e920bb0afa97a38821002d |
|
02-Jun-2016 |
Robert Carr <racarr@google.com> |
Ensure pinned animation scaling is consistently applied.
For the pinned stack animation, we have the special mode
where setSurfaceBoundaries computes additional scaling
factors to force the window to occupy the stack size
(which we animate). We need to make sure prepareSurfaceLocked
also respects these scaling factors or we have issues when
switching in and out of the fullscreen stack.
Bug: 28899837
Change-Id: I72ccba54b38993693ff6771882fb99ef82af5827
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| a4b32b963beaa48d50a3aafdf038cfd1dc160765 |
|
02-Jun-2016 |
Phil Weaver <pweaver@google.com> |
Stop magnifying surface insets.
Apparently magnification never should have touched the insets, but
the effects were small so we got away with it before. Now messing
with them disrupts the size of pop-up windows when magnification is
enabled.
Bug: 29048161
Change-Id: I4ab84f4f14cb92ca29b9085aaba7b854580f2c48
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 2957d9d604a1d6cda9be33ba75ba1ad7d7185a22 |
|
02-Jun-2016 |
Chia-I Wu <olv@google.com> |
Merge "Fix clipRect transform rounding errors" into nyc-dev
|
| c5fc6c602c16f0e985d8f8ba7f94075229e52320 |
|
27-May-2016 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Close IME when attaching dock stack" into nyc-dev
|
| 0b56cc2804a8cd60bc4a4a0c2870236ffa15e68a |
|
27-May-2016 |
Chong Zhang <chz@google.com> |
Merge "Revert commits related to wallpaper cropping" into nyc-dev
|
| 3c5d0f104109048ba55308f81ca0ce7fa1afb626 |
|
25-May-2016 |
Jorim Jaggi <jjaggi@google.com> |
Close IME when attaching dock stack
So we don't end up with animation weirdness.
Bug: 28905720
Change-Id: I04124995dd99fa26d2e9be467c5976d7b20810a7
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 741c0ba8aa84f2879c50884f53955bceb5b6e7f2 |
|
27-May-2016 |
Chong Zhang <chz@google.com> |
Revert commits related to wallpaper cropping
bug: 28763785
related-to: 27989717
related-to: 28887408
Revert "Fix wallpaper crop during unlock animation"
This reverts commit 616c7c10b9ca461da44a1eead2a6cb8260c82b22.
Revert "Fix wallpaper cropped too soon when unminimizing dock"
This reverts commit f0b76b071c8434fbf4a76798e9cdd56ab67e523d.
Revert "Set final crop on wallpaper instead of intersect clip with stack bounds"
This reverts commit dcf0183cea1f93f20073cb04fa64f111ea880005.
Revert "Crop wallpaper windows to their current target stack bounds"
This reverts commit e6cb450b0db119d71601a8329bed380bb2b4e275.
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e6bcaf134aed92a00dc5c9ee789e8a7185ffb861 |
|
27-May-2016 |
Chia-I Wu <olv@google.com> |
Fix clipRect transform rounding errors
For clipRect.right and clipRect.bottom, we need to round them up.
Bug: 28864193
Change-Id: I2bd30eec8a8093e0fdcc7ce8484a0610fd068792
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| fed100742011bbc3092925c37e9f2df4ab04b6b5 |
|
26-May-2016 |
Robert Carr <racarr@google.com> |
Ensure surfaces only resize during relayout.
For clients which use an indeterminate measure spec in their
layout params (MATCH_PARENT). We could try and change their window size
due to a stack resize, before the client calls relayout. This isn't
safe as the client never had an opportunity to pause rendering, so it
could be in the middle of producing a frame for the old size to suddenly
find the buffer size change underneath it.
Bug: 28559097
Change-Id: I3982936fdf85c22def2f9c754d5508e029e4a84d
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 616c7c10b9ca461da44a1eead2a6cb8260c82b22 |
|
24-May-2016 |
Chong Zhang <chz@google.com> |
Fix wallpaper crop during unlock animation
Do not crop wallpaper if the wallpaper target is animating but stack
clip mode is not STACK_CLIP_AFTER_ANIM. We can't crop wallpaper with
final bounds as the crop needs to apply before the transform.
bug: 28887408
Change-Id: I62b9a5ca818c3ca8d0af26d807318f63747b8ac4
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 7fae7be59514ba6a7fdc10bdb47c9a9fe09d2cef |
|
19-May-2016 |
Andrii Kulian <akulian@google.com> |
Merge "Clear mResizedWhileNotDragResizing flag after reporting" into nyc-dev
|
| bc9edc7ccb4d876bfc5c706fbb64dab9a2768b52 |
|
18-May-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fixes for ending PiP animation." into nyc-dev
|
| 54a3dd53fe6028db1f1c797ed6be12ccb6263ecf |
|
18-May-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Correct PiP inset adjustment." into nyc-dev
|
| c7294607fc0debc54e92abac18bec2601a21ce27 |
|
13-May-2016 |
Robert Carr <racarr@google.com> |
Fixes for ending PiP animation.
During the PiP animation, we have two basic requirements:
1. We need to scale windows to the pinned stack bounds.
2. We need to halt resize and movement notifications to the client.
As we end the animation, we need to disable these states at differing
times. First we need to deliver a final resize and movement notification
to the client for it's new position. However, Surfaces may not
immediately resize (in particular in the case of child windows,
it may be some time!), furthermore Surfaces may resize at different
times so we need to persist scaling on a Surface by Surface
basis after reenabling resize notifications.
Bug: 28559097
Change-Id: I6d52a3e213e08a34f4c0eea892b2a84cd4c20e18
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| bc133764497bcc4d9990ecc07a8d1053b2a1b46d |
|
12-May-2016 |
Robert Carr <racarr@google.com> |
Correct PiP inset adjustment.
We want to calculate the scaling factor we need to have
the content area of the surface (not including insets) to reach
our desired size, otherwise we will seem to scale the insets
up or down over time.
Bug: 28559097
Change-Id: I86dbd5fc902b5d380d33dba626c6694b3c57ff25
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| cbbcc0f79582b0157c03325074166da53e617c73 |
|
18-May-2016 |
Chong Zhang <chz@google.com> |
Request a traversal when a saved surface gets redrawn
When a saved surface gets redrawn, we need to return true in
finishDrawingLocked, so that a traversal is requested. This is
needed to update allDrawn/allDrawnExcludingSaved. Some delayed
window removal may be waiting for these flags.
bug: 28797800
Change-Id: I0b58b356e9c580422eb3ff81e8afb2a164cf6e43
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| cc3eccf57830ba1996266cb0fd0b01b9a07c65c3 |
|
17-May-2016 |
Chong Zhang <chz@google.com> |
Apply final crop during surface preservation
Apply stack crop to the preserved surface so that it doesn't stick over
the dock divider.
bug: 28567495
Change-Id: Ib7a9d8ec82a7752ecbef60a86f441e35e16ac877
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| eb1d322d1cfc8c7547967bc7e20b1fe3499ec90d |
|
17-May-2016 |
Andrii Kulian <akulian@google.com> |
Clear mResizedWhileNotDragResizing flag after reporting
Currently mResizedWhileNotDragResizing flag is not cleared after
reporting resize to client, which causes sending lots of resize
messages and relayouts on app side.
This CL introduces another flag to track reporting to app.
Bug: 28696195
Change-Id: Ib5b6ea3e5f499c96057182f4b20583734dea56c4
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| dcf0183cea1f93f20073cb04fa64f111ea880005 |
|
14-May-2016 |
Chong Zhang <chz@google.com> |
Set final crop on wallpaper instead of intersect clip with stack bounds
Wallpaper's clip rect is offset by its window offsets, it can't be
intersect directly with stack bounds.
bug: 28763785
Change-Id: Id87d668c9e59832498c9c62730617d0a5a9207c2
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 663330a325c4b324eb19cdb4f83189f342e01060 |
|
12-May-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix surfaceInset adjustment." into nyc-dev
|
| bc5446cba502eeda3b4e0e81f512e673b6b55caa |
|
11-May-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Crop wallpaper windows to their current target stack bounds" into nyc-dev
|
| e6cb450b0db119d71601a8329bed380bb2b4e275 |
|
11-May-2016 |
Wale Ogunwale <ogunwale@google.com> |
Crop wallpaper windows to their current target stack bounds
Crop wallpaper windows to the stack bounds of their current target to avoid
them showing behind transparent windows in other stacks in split-screen mode.
Bug: 27989717
Change-Id: Iff7cec201dd8061026e32af0f44380862fc37705
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 9214704eac0af4b0d138a195bcea6fecef523ea5 |
|
09-May-2016 |
Chong Zhang <chz@google.com> |
Fixes for restoring more than one child surfaces
App may have more than one windows and subwindows. Remember which ones
are visible at the last setAppVisibility time, and restore only those
that was visible then. If the app itself requested to hide a window
before that, we don't want to use the window for early animation.
Also move mAnimatingWithSavedSurface into WindowState as it needs to
be tracked per window.
bug: 27455025
bug: 28296945
Change-Id: I3ed1879634fa7709de699d4518d8fcfc91a85554
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| eb66557eeb923cf33a4c2e133776ab8cbc9aa571 |
|
10-May-2016 |
Chong Zhang <chz@google.com> |
Make sure preserved surface is removed when it's no longer needed
Preserved surface might be used for format change as well as surface
size change outside a drag resizing. We currently remove the preserved
surface in prepareSurfaceLocked() after the window is shown, but
sometimes app gets stopped before any animation pass is run.
bug: 28546172
Change-Id: I7f883f4b5c6da4dce70f94173b368a912056d062
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e22006d936e0928b4a335646f19a8ca18a7fb1e2 |
|
09-May-2016 |
Chong Zhang <chz@google.com> |
Fix a flicker when opening app again quickly while it's exiting
If the app is waiting for an opening animation with a dummy placeholder,
we need to skip the surface placement (in addition to the animateLocked).
Also, when animating is changing from exiting to entering, the mAnimating
flag needs to be cleared until the new animation starts. This prevents the
surface placement to place it wrong before the new animaition starts.
bug: 28599295
bug: 27742244
Change-Id: I26f0ead80ee9993a6c766ae8686ab11d1729519c
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 93873e4985c2e36772a5ffcdaed6351249e7a6eb |
|
30-Apr-2016 |
Chong Zhang <chz@google.com> |
Do not update surface for dummy animation as long as transition is set
Transition is not set to ready until it's executed, which could happen
a bit later after the setAppVisibility where we set up the dummy.
It is rare, but an animation pass could still slip in between, and
since the transition is not ready, it modifies the scale and show a
bad wrong frame.
bug: 27742244
Change-Id: I97fb1955e810c7c4f01dc55a28d2e4ce4f47d5eb
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 7021174287eeb9447cb5a2bf7b17c5588db76133 |
|
29-Apr-2016 |
Chong Zhang <chz@google.com> |
Do not change surface properties when waiting for transition to ready
Window could become drawn before transition is ready, when transition
is waiting for the animation spec. If we show the surface too early,
one or more frame will be shown with wrong scale.
bug: 28296945
bug: 27742244
Change-Id: I34e84ed8a37ecdb71eb975351f1ee39d14dfba25
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 9848c84d026186aa9a186d4587b615aae06a2ef6 |
|
27-Apr-2016 |
Robert Carr <racarr@google.com> |
Fix surfaceInset adjustment.
surfaceInsets are relative and have the same
sign direction for left/top/right/bottom. This means
we want to subtract the left/top insets and add the
right/bottom in order to expand the surface. The current code
is adding the left/right insets before adding them to the right,
while still subtracting from the left. This ends up expanding the
surface by 3*inset pixels instead of 2*inset pixels.
Bug: 28368990
Change-Id: I6495e39283c7d2494c962f89e95672c5f1f6e1cd
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e67960ecae2ba008a7d1d364b5fdb1b95a179e52 |
|
22-Apr-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Force pinned windows to always be scaleable." into nyc-dev
|
| 5c80c41ee0ef808e7c8234087c5538531a16f5bb |
|
20-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Final fixes for growing recents transition
- Make sure to reposition windows during animations to avoid that
they lag one frame behind.
- Don't put windows that are gone for layout into resizing mode.
- Don't layout windows that are gone for layout, to avoid resizing
the surface but the client won't draw anymore.
Change-Id: I809feffef00f9a086b44504126e03f509eb7f190
Fixes: 27855229
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 1b5ea72b3cd946ae27e92743339f1fcb117a0520 |
|
20-Apr-2016 |
Robert Carr <racarr@google.com> |
Force pinned windows to always be scaleable.
Otherwise we have a race when switching it off at the end
of the animation when we don't move to fullscreen. Ensure
SCALE_TO_WINDOW is always enabled for windows while they
are in the pinned stack.
Bug: 27793381
Change-Id: Ia92465fd0d854f799caa8ed31edb4621af9fdecd
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 50c410c1c91922e91fb8d1b873f6a541d1e2fd6c |
|
20-Apr-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix wrong transition when recents is growing when entering" into nyc-dev
|
| db21bbd2caf05322864f09ec45a0c572cf071123 |
|
19-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix wrong transition when recents is growing when entering
Bug: 27855229
Change-Id: I050305d16df6fe53abf5e74e1f9ee6c882dd7ead
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 4e9a9dfb67ebc48028b1613a03144101d94f7d92 |
|
20-Apr-2016 |
Rob Carr <racarr@google.com> |
Merge "Force windows to be scalable during pinned animation." into nyc-dev
|
| 4c5aa51717b1858132ffc5c9804f409a161283ec |
|
19-Apr-2016 |
Wale Ogunwale <ogunwale@google.com> |
Don't crop windows not on defualt display to stack bounds.
There are some windows that live on other displays while there app
and main window live on the default display (e.g. casting...). We
don't want to crop this windows to the stack bounds which is only
currently supported on the default display.
Bug: 26782253
Change-Id: I45648cc6fe8729e35f5b28eb06207aac6c263cdf
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 1ca6a33f36357281b3445e85d9e67cacd1a12ede |
|
12-Apr-2016 |
Robert Carr <racarr@google.com> |
Force windows to be scalable during pinned animation.
We resize windows at the beginning of the pinned stack
animation when animating to a larger size, and so for some
duration a resize will be pending. We need to force the window
out of SCALING_MODE_FREEZE so we can animate during this period.
Bug: 27891386
Change-Id: I5cff599ed67f2c179e938662b6f0d99bd790aaba
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 7a4fd5e1f287963c97bf25f265b940c289d6ecf6 |
|
15-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix minor issue with IME
Because we only "carve" out the area for the IME once it's actually
visible now, we need to relayout the windows when we show it - else
they won't update the insets until the next real layout happens.
Bug: 28175599
Change-Id: Ie0af1225da03905bfcb52044e212812c892c88a9
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| bb9fb194f85225fcf0360fc53da51f12a649bd1b |
|
15-Apr-2016 |
Rob Carr <racarr@google.com> |
Merge changes Id603816c,I86e41324,I025d0558,I44d8dbac,Iabfc2e81, ... into nyc-dev
* changes:
Only set mResizedWhileNotDragResizing for base windows.
Fix Task dim with docked resize.
Correct window replacement string comparison.
Replace DimLayers with windows.
Prevent premature window replacement.
Correctly prevent entrance animation for replacing windows.
Replace secondary app windows across activity relaunch.
|
| ff71d20ff357a33c30e1e3b474e51ad47d5c5d3a |
|
14-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Put windows into resizing during IME adjust animation
Because the IME animates in with translucency there was a black hole
visible at the bottom. This CL puts the window into resizing mode,
waits until the change is commited, and then starts the animation
Bug: 28175599
Change-Id: Ib31c1e765639e5490208bccba77b25318ec8dc71
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| eb88d83fc5da8ea05033c03bbb9f0d4b804ba162 |
|
14-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Add nice animation when adjusting for IME in multi-window
- Run a separate animation when we need to adjust for the IME. We
can't use the attached animation because the adjustment animation
needs to be longer than the IME animation.
- Also run an animation when IME is disappearing.
- Adjust IME exit animation to better match with adjustment exit
animation.
- Make sure to update adjust for IME when entry/exit animation of
IME is starting, to avoid flickers.
- Don't update the IME window in PhoneWindowManager for layout
until the animation has started. This lead to an issue where the
content inset was set too large too early.
Bug: 27154882
Bug: 28175599
Change-Id: I09a33413e307f84d6c3cf4ae928c280f7ad48348
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| fd950bd6ff659f87fd87dd435207899bac65d991 |
|
15-Apr-2016 |
Rob Carr <racarr@google.com> |
Merge "Synchronize future unsync transactions to last sync." into nyc-dev
|
| b439a63fdf9398e46ca44811fbfde35fd02911c4 |
|
08-Apr-2016 |
Robert Carr <racarr@google.com> |
Correctly prevent entrance animation for replacing windows.
Prevention of entrance animation for seamlessly replacing windows,
was not working for non child windows. To correct it, we simply bail
from applying the app entrance transition.
Bug: 26668339
Change-Id: I4349e6aef55c3957d81a0a168cf6ac1d7c8866f1
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 3fb1c81394f98b025b488774916b7580f9e31dab |
|
13-Apr-2016 |
Wale Ogunwale <ogunwale@google.com> |
Merge changes Ieefeb843,Ic2a94b09 into nyc-dev
* changes:
Update surface insets on window elevation changes.
Fixed bug with cropping out drop shadow for pinned stack.
|
| d7f6e7c7694305c3231a575cf709ba13075bfe48 |
|
12-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Clip mWinShowWhenLocked if Keyguard is not showing
Bug: 28076605
Change-Id: I80ae6dbd09d419c258efd79639a62dce8c2fbe79
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| b918f1bfb81fefa156282c98929248f28035efd7 |
|
08-Apr-2016 |
Rob Carr <racarr@google.com> |
Merge "Do not crop children to task bounds while resizing." into nyc-dev
|
| 679c807210e4d741b4c65ac67d298d1d56abf3ee |
|
08-Apr-2016 |
Robert Carr <racarr@google.com> |
Synchronize future unsync transactions to last sync.
This ensures we don't push through an unsynchronized
update while a synchronized one is pending. If the
synchronized one is no longer pending, then our
transaction is applied anyway and things continue as normal.
Bug: 27098060
Change-Id: I08fe8f848848d25d01b1696e0340fcce61ac554f
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 7c3912e4abc71886ad41e7be67d4eff41974d21f |
|
08-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Dismiss docked stack when opening non-resizable activity" into nyc-dev
|
| d53f09254ed48365d3a5149d640437d76aed2e5d |
|
07-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Dismiss docked stack when opening non-resizable activity
- Also move the toast to SysemUI as a cleanup.
Bug: 27341740
Bug: 28026841
Change-Id: Ic6196ed75511751c6fadb12fa24574c881100f65
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 246c209e4fe704c0745224be0ab05225e8431d11 |
|
07-Apr-2016 |
Wale Ogunwale <ogunwale@google.com> |
Update surface insets on window elevation changes.
Window manager factors in the surface insets when calculating the
right crop for a window surface. Without the surface insets been
updated and new param forwarded to window manager, the window crop
will not be the right size and the window drop shadow might not show.
Bug: 27364161
Change-Id: Ieefeb8435543f3137672a065269cdeefca371111
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 2487ce70a7c28313d5e2c7a5cc8ef3d999d05ac9 |
|
08-Apr-2016 |
Robert Carr <racarr@google.com> |
Do not crop children to task bounds while resizing.
When we are resizing the task bounds might be smaller than
the stack bounds. We don't want to clip to the task bounds here,
so we use an expanded rectangle, making sure to expand it
large enough for giant surfaces.
Bug: 27676101
Change-Id: I1a324a474a89e4652ccd15ebd853b0b8815a48f5
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 6bab4cf52d53074b7d353738ebd014c72366774d |
|
07-Apr-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed bug with cropping out drop shadow for pinned stack.
The surface crop we apply to windows in the pinned stack was based on
the stack bounds. However, the windows in the pinned stack have a
drop shadow that extends outside the stack bounds to make them appear
floating so they were out displayed. We now extand the crop for windows
in stacks that have shadows and occupy the entire stack space to that
their drop shadows are visible.
Bug: 27364161
Change-Id: Ic2a94b091a93e7145a5455b494f0b689118eb5e3
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| f3df0aaa326538085adc8aca35a3eaff85ab3c70 |
|
07-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix flicker when docking task
Bug: 28051193
Change-Id: I191c01f90c775a26fce6e6f73a0573a0be91a61f
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e1d43614978ee5b50fb8ea179c9d4961885b472b |
|
02-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix screen rotation animation
Bug: 25019187
Change-Id: I65b5a76147b93e081466035bfc3cce0c9473610e
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 0b46f3c72c324bc9b8890ed9b81951bbeec70fdd |
|
14-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Implement transition for docking task in recents #2
- Put window into resizing mode when docking it from recents,
so it fills the "void".
- Send whole task bitmap window as the thumbnail, to make
the transition smoother.
Bug: 27607141
Change-Id: Ib647d44d9777f1155deab818d1fd5425c1bdd3d1
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 6a7c90a12b5e5250e0350d35ca6547b26630653f |
|
11-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Implement clip modes during animation
Introduce modes how surfaces are clipped to the stack bounds
during transitions.
Use setFinalCrop to implement STACK_CLIP_AFTER_ANIM.
Add logic to determine which stack clip mode to use.
Bug: 26559810
Change-Id: I8edc47de3aaf1ef12055cefd8ceb8df536c5109a
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| f3b72c7b4dfc1e858340552f792f8f47ebd515e3 |
|
22-Mar-2016 |
Robert Carr <racarr@google.com> |
Transform app animator crop to child window space.
The AppAnimator will not know about child windows
relative offsets to the containing frame and so
will express crops in the wrong coordinate space.
Bug: 25986646
Change-Id: I3af291aa60455b753c2e61d4eebb77ace902ff15
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 24aac8adc0a7ddd936e3f33541aa8587d769083e |
|
17-Mar-2016 |
Chong Zhang <chz@google.com> |
Merge "Apply temp inset bounds to child window if it's not empty" into nyc-dev
|
| ae35fef616c14f721cf12d6a0f78bef9fef5df9d |
|
16-Mar-2016 |
Chong Zhang <chz@google.com> |
Apply temp inset bounds to child window if it's not empty
bug: 27676101
bug: 27687126
Change-Id: Iab1129cc0224194e7a9d11d0454bc7af6897a6e8
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 477e720696970d8ab3cc4e6569022f1db0272d43 |
|
16-Mar-2016 |
Chong Zhang <chz@google.com> |
Apply stack crop to docked stack during animation
If device goes to sleep with docked stack visible, the docked stack
will be minimized after unlock. Due to "force hide enter" animation
and the entering animation of the app itself, the app will be animating
for the initial few frames. Not applying the crop causes the app to
be seen in full briefly, then minimized.
Docked divider doesn't use a final stack bounds but changes stack
bounds continously during docked stack resize, so we can apply the
bounds even during animation.
bug: 27592767
Change-Id: I12f4eb46a95c9a7dd2147b68c362e17609a8b410
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| d5c2db630fc816e2d9154a61ccbd6770bc57cff8 |
|
09-Mar-2016 |
Adrian Roos <roosa@google.com> |
Don't show wallpaper when backdrop is visible
Hides the wallpaper when it's not needed and fixes
the unlock animation to not unnecessairly show the
wallpaper if neither the Keyguard nor the underlying
app need it.
Also fixes a bug where the enter animation had a background
set, which led to uglyness when no wallpaper is involved.
Bug: 27533740
Change-Id: I667c6f7ca6c0e1ff7e9f793c6ddc13f6da8387b1
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 33fde7d098d6fb68bfacc390f5f5a2cf865a203b |
|
06-Mar-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed IndexOutOfBoundsException when removing child windows
The size of the list reduces when a child window is removed from the
list. So, we copy the window list and loop from the last entry to the
first when removing to avoid IndexOutOfBoundsException.
Bug: 27345523
Change-Id: I15986e418d29ee5035dc9d4c4f728ad33bfe6999
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| adef831761017d6d84d7bd4a388714a04fb73d66 |
|
03-Mar-2016 |
Rob Carr <racarr@google.com> |
Merge "Reimplement PIP animation to not use drag resizing." into nyc-dev
|
| 0d00c2e25bf8816dbd99f4fcd5c8221e80826a95 |
|
01-Mar-2016 |
Robert Carr <racarr@google.com> |
Reimplement PIP animation to not use drag resizing.
When using drag resizing it is difficult to keep big surface
surfaces (e.g. main app windows) and child windows in sync
as we resize. Furthermore it's difficult to resize child windows
quick enough to achieve more than a few frames a second as we have
to propagate through the client UI thread. Our new implementation
uses window scaling.
Bug: 26454664
Change-Id: Iac96619cefc075b1412cfeba3d3c9bcd7ce22f52
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 2728bf4bf9c4bc73837f41d3bf0251a7de6c9e16 |
|
03-Mar-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added more log points for add/remove in window manager.
Bug: 27286867
Change-Id: Iecb522a1ff7e093a8feef27fdd68c50b9a80d553
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 6f9e1039d582c1e2aef27f13551d152420c02f48 |
|
27-Feb-2016 |
Chong Zhang <chz@google.com> |
Merge "Do not apply stack bounds if the window is above lockscreen" into nyc-dev
|
| bcb8d82513de4936d3fba04616574b427c67d853 |
|
27-Feb-2016 |
Chong Zhang <chz@google.com> |
Do not apply stack bounds if the window is above lockscreen
bug: 27208572
Change-Id: I4cd3af47474c93180d95a2f51ac7b52a21ddd999
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 9017ec0b150ee19ca1041b61c2560dff759686d7 |
|
25-Feb-2016 |
Wale Ogunwale <ogunwale@google.com> |
Remove starting window whenever the acitvity is stopped
The main app window will never finish drawing at this point so there
is nothing to trigger the removal of the starting window.
Also, set ActivityRecord.mStartingWindowShown to true for some cases
where we were telling WM to show starting window but not setting the
flag that would later be used for clean-up.
Bug: 26659857
Change-Id: I7a8582521853f1f95b77d8b08f4dd0cf778f8cbf
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 5e6968db630d26872306c4b23aa2c600d83ed454 |
|
20-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix disappearing windows after moving divider to side
Because we only hide the surface when the clip rect got empty
but never showed it again if it got non-empty, app windows
disappeared after moving the docked stack divider to the
edge of the screen. Now we reshow the surfaces if the clip-rect
gets non-empty.
However, this introduces another bug while dismissing the docked
stack: Because we move all windows to the fullscreen stack, we resize
them but until the app transition starts, it can take a while and
during this time the app surface would be visible with the wrong
bounds. To fix this, we notify the windows that we are repositioning
ourselves in our stack. When applying the clip-rect, we detect that
situation and then we set the clip rect to empty if it was just empty
before and we just moved in the stack, to fix this very specific
issue.
I'm really not proud of this solution but at this point we can't
revisit how app transitions are executed in terms of timing and
ordering, so I thought this little hack is the best solution at
this point.
Bug: 26588506
Change-Id: I78305f7f7ef6c3da3c126a58d751117fcee23ca9
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| c48a354733ff150e4a07f6b0743009001aa4f48d |
|
20-Feb-2016 |
Wale Ogunwale <ogunwale@google.com> |
Clean-up WindowState if exit animation is done before app finishes
In ag/862571 we prevent window states from been removed before the
app is stopped since it can still be rendering to the surface.
The CL also left WindowState.mExiting as true after the exit
transition animation runs. This is okay if the app finishes before
the exit animation is done, but if the exit animation finishes before
the app finishes, then we will always think we need to run an exit
animation and not remove the windows when the app and later activity
manager tries to remove the windows.
mExiting is used to mean exiting animation is running, if it is set to
true then all the code assumes an exit animation is still running and
doesn't remove the window state.
- Always set mExiting when animation is done.
- Renamed mExiting to mAnimatingExit so it is more clear what it is used
for
- Allow window state to be removed is the current surface isn't shown.
This should be save since there won't be any visual effect to the user.
- Rename WindowState.mClientRemoveRequested to WindowState.mWindowRemovalAllowed
and move setting it to true into WMS.removeWindow() so it catches all cases.
- Cleaned-up the code some to be a little clearer.
Bug: 27112965
Change-Id: I6f03d3c75b5b7728e42ceadc8703df40a3b4ae63
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 722ff89fd1684179c342c3e9b6014c5499f90b90 |
|
18-Feb-2016 |
Wale Ogunwale <ogunwale@google.com> |
Protect against surfaceController and hasSurface getting out of sync.
WindowStateAnimator.mSurfaceController is set to null whenever a
surface is destroyed and WindowState.mHasSurface is set to false
shortly after that. However, it is possible for them to get out
of sync in a couple of places due to exceptions or duplicate destroy.
Consolidated the call to set WindowState.mHasSurface inside a finally
block in WindowStateAnimator.destroySurface
Also, cleaned up the code a little to that it is more obvious what is
going on.
Bug: 27235356
Change-Id: I7e6d0c1fb015531c393ac86dcaebebd134fad612
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| b9b0fec9642e0a4e1a9dc881fa82f53a726e7006 |
|
12-Feb-2016 |
Chong Zhang <chz@google.com> |
Fix flicker when tapping quickly on dock divider
- Only add preserved surface to removal list when the new surface is shown
- When surface mode change again before the previous preserved surface is
removed, don't do nothing, instead, destroy the current surface which is
of wrong size.
bug: 26545679
Change-Id: Ifd548a0fa9ccdcbc9609ca38bb701cc7256cc6e1
(cherry picked from commit ec63381f7596d89719fd3528b181ed1820a4cb84)
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e05db74fd275ea25d10074825a43cc5c7683ae01 |
|
17-Feb-2016 |
Chong Zhang <chz@google.com> |
Remove AM/WM traces
Change-Id: I75f70ce18bf133527b33d42148c71c3fd1be9311
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 2b79af1e8a45776ba57cd38a50afe4a6c2f719aa |
|
11-Feb-2016 |
Chong Zhang <chz@google.com> |
Mark activity as visible and not stopped after resume-relaunch.
After a resume-relaunch, the activity is assumed to be in resumed state,
and we'll not run the normal code for resume. But it needs to be marked
visible otherwise it will stuck in invisible state.
Also trade some AM traces for WM traces for further debugging.
bug: 27123118
Change-Id: I50ce5cde29f441115675db54523090ef86d95ea8
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e12aece4cad849efbbe6a806f132613a56699230 |
|
03-Feb-2016 |
Robert Carr <racarr@google.com> |
Ensure surfaces stay alive until activity stop.
Prior to this commit in this case of activity pause, with finishing=true
the activity manager will notify us of app visibility and we will begin
an exit animation. When this exit animation finishes, we will destroy
the application surface (unless its eligible for saving). However there
are two cases where this breaks down:
1. The exit animation finishes before the activity thread handles
the stop transition. Many activities stop rendering on Pause
but many do not and it is totally legal to do so. Sometimes this
results in non fatal dequeue buffer errors and sometimes results in
fatal errors with Pixel Buffers, etc...
2. We may resume the activity shortly after asking the window manager
to pause it. If the window wasn't eligible for animation, we will
immediately destroy it after being told of the visibility change
following PAUSE_FINISHING. It's possible for this to complete
before we process the resume. On the other hand the client
happilly processes the resume and transitions back from PAUSE
and then crashes once it attempts to use it's surface.
In this commit we have the activity manager notify the window manager
when an application has actually finished (or we have timed out
waiting). For windows which have not been explicitly removed by the
client, we defer destruction until we have received both this signal
and the animation has completed.
Bug: 26793431
Change-Id: Ib6ee8fbdd1f03450fbbfd62468a19e97774befab
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 0464a9345e7e3e666a84a3489cfffd5e45a21353 |
|
03-Feb-2016 |
Chong Zhang <chz@google.com> |
Disable WM loggings
bug: 26819496
Change-Id: Ib5258391101293c9aaca3b865e1f1580234bcbe3
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| d7e4acba06057a40d9716c54ce49708608aa6f8c |
|
02-Feb-2016 |
Rob Carr <racarr@google.com> |
Merge "Ensure Surface matrix set even when size unchanged."
|
| e1034cc39a574c3e8dc481810fb8f24571c41d70 |
|
01-Feb-2016 |
Robert Carr <racarr@google.com> |
Ensure Surface matrix set even when size unchanged.
Simple error preventing transform matrices from being
updated when the size isn't changed.
Bug: 26454664
Bug: 25287371
Change-Id: I0e1a71ceda725e26d49786593665cf0865213c91
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| bfc2f8f6c8ac4156e76a50c88a9ac36d864cee36 |
|
30-Jan-2016 |
Chong Zhang <chz@google.com> |
Some fixes for saved surfaces
- If we have a saved surface, and app relayouts to visible before we
started entry animation, we need to restore the saved surfaces.
Otherwise the surface might get stuck in the saved state, because
we may not get to run any animation after this relayout.
- Keep track of the allDrawn while we're using the saved surfaces,
so that we can rely on allDrawn itself, instead of whether we're
using saved surfaces.
- If the app is set to visible when it's exiting, clear the exiting
flags. Also, save the surface if we cancel an exiting animation.
- More debug logging.
bug: 26819496
Change-Id: Ie42c6eea7879632d82f24ed09c3b6e737dd6d8a4
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| b1faf60b896afe235175354ffd90290ff93a54b4 |
|
27-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Use resizeMode integer instead of resizeable boolean.
Changes activity manager and window manager to use resizeMode
as defined by ActivityInfo#resizeMode instead of a boolean.
Bug: 26774816
Change-Id: I8cef46d9fba6bfdd21df7da63ed5d5330ad03d4b
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| a8975bd3696278445cb6ffd426eade0ac2449dd7 |
|
29-Jan-2016 |
Chong Zhang <chz@google.com> |
Enable logging for surface create/destroy.
bug: 26819496
Change-Id: I969b87122126df994c5bd5af177b672bcab5b7dd
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| eb22e8ed42bb146060e8ffc94444f70ea47fda04 |
|
21-Jan-2016 |
Chong Zhang <chz@google.com> |
Fixes for broken saved surface
- Reset and restore the visibility flags and hasSurface states when
surface is saved or restored. When the surface is in saved stated,
we have to make the rest of the system believe that the window has
no surface.
- Set app windows to 'mExiting' when we start a transistion because
window manager changes the visibility of the app. We can't rely on
receiving a relayoutWindow from the app to invisible. We need to
mark it exiting so that when the transition is done, the surfaces
get removed (or saved if possible) promptly.
- We need to save the surface if the app token is the last one in
a task, regardless of whether it's visible, this means the whole
task is going into background. But if the app has another visible
token on top of it, we don't need to save it. For example one
activity launches another activity, in this case we don't want to
save the surface of the activity on the bottom.
bug: 26573100
Change-Id: Id845f87b30cda1cebcc12ad2ac8dbf19a068a86e
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 198dcbf5231761b7b644d9d7fbceb23e1f0f9aec |
|
18-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Fix several small logging issues.
This includes:
1) invert HIDE_STACK_CRAWLS to SHOW_STACK_CRAWLS so it's immediately
clear from the config file that something is enabled (if anything is
true).
2) Merge stack collection code into a method, so we can remove the
repeated code.
3) Remove copying of some constants in AppTransition and just import
them directly.
Change-Id: I3190ee0a5963720ac6285b4f48b2705e84f04ab5
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| f66db43063e4409206f1572fa1bac4f87c431f9a |
|
13-Jan-2016 |
Chong Zhang <chz@google.com> |
Several fixes for docking non-resizeable tasks
- Keep track of original task bounds and scrolled bounds separately,
so that we can reset the scrolling when the it's no longer in effect.
- Calculate the vertical offset for the toast on top half using the
content rect. The original toast position was relative to the bottom
of the content rect, not the display rect.
- Move toast display to prepareSurfaceLocked, as performShowLocked() may
not be called if the app surface is already shown.
related-to: b/26451625
related-to: b/26447921
Change-Id: I82113683c9e3c3beb4938dbd0829d0abf491efd9
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| dc249c4ae7c7838928f53f151bfda8a6817b8784 |
|
15-Dec-2015 |
Jorim Jaggi <jjaggi@google.com> |
Change behavior when resizing docked stack
- Add an API resizeDockedStack to resize the docked stack
and supply temporary task bounds, which can be different from
the stack bounds.
- Use that API in SystemUI to only switch task bounds when
crossing thresholds, so we have less flickering and more
predictable resizing.
Bug: 25015474
Bug: 26311778
Change-Id: Id5c9277dd908ccc28f95dab023efc914757a50d0
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 50bf96b86dc11194f4fb8a4dc97599cbe3b1eea7 |
|
28-Dec-2015 |
Chong Zhang <chz@google.com> |
Crop to stack bounds during animation if docked task is non-resizeable
When a non-resizeable task is docked, it's running in fullscreen size, its
visible area should always be cropped to docked stack size. Otherwise wrong
size might show through during animation.
bug: 26163416
Change-Id: Idcbf4b86ae0976d86a2f91e78ccc2113dd86af62
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e6ed195615c5d04564eab32721fec91b992e3470 |
|
21-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Remove confusing logging about surface size.
Change-Id: I377cb6dd25c5db9939a6b7f87fef634426d6c2b4
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 92e432c30e2304272c2f5b1b33366f32c3d763cf |
|
16-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Refactor and improve window layering.
This CL moves layer calculation into a separate class, so the whole
logic can be encapsulated. It also extracts special cases from the
general loop and instead applies them at the end. This simplifies the
logic in the main algorithm and makes it clearer what needs to happen
for special cases.
Bug: 26144888
Change-Id: I87347bf0198bd0d3cd09e4231b4652ab979f2456
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 28ba3832142a963d800ba9fa56c1e06cc1dd97f7 |
|
15-Dec-2015 |
Rob Carr <racarr@google.com> |
Merge "Move window replacement tracking to window state."
|
| a1eb439eee65138280c560f96e2a6896f9c9112c |
|
10-Dec-2015 |
Robert Carr <racarr@google.com> |
Move window replacement tracking to window state.
In preparation for supporting replacement of child windows
we make replacement per window rather than per app.
Bug: 26070641
Change-Id: Ifa332086599c125611e430219c9497bae7e2ce31
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 15bfdf57be0686316f104c772d9c1b99cccc6000 |
|
13-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Merge "Don't log bad surface size before layout is done."
|
| 96b906f57723e9a829dd2b4fdeaa29a3f0d72ba5 |
|
12-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Don't log bad surface size before layout is done.
The surface dimensions are calculated when the surface is created.
This might happen before the window had a chance to relayout itself,
so the dimensions passed to the surface will be wrong. This doesn't
happen on subsequent recreations of the surface, because the window
has previous dimensions, but will produce a bad log when the surface
is first created.
Bug: 26061934
Change-Id: I670bbb6d64f5ec7efabe3bd838a116a1d48e74f2
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 51a1b875c2ba1bf086c849871dd340cfee2ccfaa |
|
08-Dec-2015 |
Robert Carr <racarr@google.com> |
Apply cropping to resizing surfaces.
Apply crop to surfaces even while we resize them. In the case of
SurfaceView, the SurfaceView will be much slower to resize than the
main window. Without crop, this causes the SurfaceView to jut past
the bounds of the main window as it is shrinking. With crop we can
ensure the crop moves with the border in the same SurfaceFlinger
transaction.
Bug: 26010823
Change-Id: Ifb32422de8d18363bd956a457e9efe8cf26678e5
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| f34a04cca9b7f34eff533866ec11233777876ebf |
|
08-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix freeform to recents animating window being cuttoff.
The window will appear cutoff during the animation if the window was
cropped due to stack or decor bounds before the animation started. We
need to disable the cropping (both from decor and from stack bounds)
for the duration of the animation.
Unfortunately, by disabling cropping of a freeform window to the stack
bounds, we will make it appear above the docked window during the
animation (because the animation will lift the layer). To fix this, we
need to treat the docked stack like the pinned stack and assume it's
always on top for the layering purposes.
CL also includes refactoring of mSystemDecorRect and
mLastSystemDecorRect which can be moved from WindowState to
WindowStateAnimator and made private there.
Bug: 24913782
Change-Id: Idbea99ba04e9449d0563d0c02636f8b4b63087f7
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 0bd180d8880b3d1b9677f154c034a2af840b4796 |
|
08-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Improve debugging setup for window manager package.
This moves debug flags to a dedicated class and also provides a
mechanism to either have fine grained tags or one common tag for easier
grepping the logcat. This mimicks the approach in activity manager
package.
Change-Id: Ie8c08b9a3d8b182335ee5547ee05d21b5933db6b
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 13f7be9e0424266be4bf3b5c8c7fdc161e4fe091 |
|
03-Dec-2015 |
Robert Carr <racarr@google.com> |
Move surface save state tracking to WindowState.
In the current set up, surface saving is managed by the app window
token. So when destroySavedSurfaces is called, all saved surfaces
assosciated with a given app will be destroyed. This causes pretty weird
behavior where hiding child windows can destroy the parent window. We
move this tracking to WindowState and allow child windows to exempt themselves.
Bug: 25780116
Change-Id: I3ab92221d83297092dfd98a71e6a5fe96381de8b
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| c806d90e656a24dc8f50ef0d3f8bc99b9ac65afe |
|
30-Nov-2015 |
Chong Zhang <chz@google.com> |
Show toast for non-resizeble docked task under the task itself
Move the show toast code to WM, so that we can schedule to show the
toast when the app becomes visible. Otherwise the toast always shows
up a long time before the app itself.
bug: 25433902
bug: 25873338
Change-Id: I879f8e0570829934fac806c2861bda9f65e08969
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 19723a4a2bca0660f7ee7c29926af285d94ab5a2 |
|
26-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Revert "Destroy docked divider surface when it's hidden."
This reverts commit cb5f57bc580d7f73b93c8f504daa4dcd74cdce72.
Change-Id: I1f77e1ccd5382ed57b8e4165afd79db5223f51c1
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| cb5f57bc580d7f73b93c8f504daa4dcd74cdce72 |
|
24-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Destroy docked divider surface when it's hidden.
Also includes bunch of small refactorings:
* destroying surfaces is now fully contained within
WindowManagerServices and mDestroySurface can be privatized;
* WMS.isDockedStackResizingLocked can be removed;
* mScreenCaptureDisabled changes from being SparseArray<Boolean> to
SparseBooleanArray, which not only avoids boxing but also makes code
simpler (no need to check for null)
Bug: 25844096
Change-Id: I0e5462760ffbc947ce6dc52ef429fa270ffc6786
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 95cdbd6f6d0fd8f4ec9d68a3ed8845a1ac6aa541 |
|
23-Nov-2015 |
Chong Zhang <chz@google.com> |
Merge "Fix black wallpaper when docking a non-resizeable task"
|
| 0abb20f37425fcde40f56e8dcaf7f191db820415 |
|
19-Nov-2015 |
Chong Zhang <chz@google.com> |
Fix black wallpaper when docking a non-resizeable task
Separate WindowState.isFullscreen into two methods, isFrameFullscreen()
that returns whether the window frame is fullscreen, and
isObscuringFullscreen(), which returns whether the window is actually
covering fullscreen.
In case of a docking task that's non-resizeable, the window frame is
fullscreen but since the stack is not fullscreen, the window is cropped
to stack bounds and is not obsuring the screen.
bug: 25433902
Change-Id: I7cd80381601fdc1fe87d04608b6a453806920590
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| c954780a5a257fb00244f433c228eb55928f609a |
|
20-Nov-2015 |
Rob Carr <racarr@google.com> |
Merge "Prevent SurfaceView flash while resizing."
|
| 84b0574cecf7eba313c78fa8d9176ac0d34ef103 |
|
18-Nov-2015 |
Robert Carr <racarr@google.com> |
Prevent SurfaceView flash while resizing.
We need to make sure we do not preserve
and destroy attached windows when entering
drag resize as we will not swap these windows
to the big surface. On a similar note,
we need to make sure we do not hide child windows
when destroying the parent window for preservation.
Change-Id: I98e02f08d0ea2d5f0032ec7691e865c536df19c6
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| f52dd205b9d31e0edcfdfff4ed98259c07ca38b7 |
|
16-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Don't animate move triggered by resizing using dock divider.
Also includes some small, nice refactoring:
* move code that sets the move animation into WindowStateAnimator;
* a few fields can be made private in WindowStateAnimator this way;
* one boolean flag in WindowStateAnimator popped out as unused after
being privatized, so could be deleted.
Bug: 25690109
Change-Id: I8144114244892c4f27aff21455e8e76eddbd039f
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 5b2f199c85824af4659601f55a96340d77e7863c |
|
14-Nov-2015 |
Chong Zhang <chz@google.com> |
Notify client of surface size change if it's changed from last relayout
Not just when it's changed during this relayout.
bug: 25596610
Also add the delayed surface to removal list regardless of the show
result, it won't be destroyed until window is ready to show but we
need to add it to the list first.
bug: 25666160
Change-Id: I6fceada1bdc1de0a5b5a4d6dc261957164817330
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 16b83907d133e7cf216dcf7f586584057969d410 |
|
13-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Fixed bug where stack crop wasn't applied when it should"
|
| f4abc2b701c23978e8bd5e4fc3e183e519aede4a |
|
13-Nov-2015 |
Chong Zhang <chz@google.com> |
Need to updateSurface if surface size was changed in relayoutWindow
On some chips, SurfaceControl.setSize will not take effect for several
frames. We have to also do a updateSurface/invalidate (which destroys
and creates the EGLSurface) to get the size right.
Keep track of SurfaceControl size changes in window manager, and pass
that to ViewRootImpl, so that a updateSurface is done either the surface
itself or its size is changed.
Note that we don't use frame size change to trigger updateSurface, because
frame size could be different from the surface size that window manager set.
For example during drag resizing, the surface size is fullscreen although
frame size changes constantly. Doing updateSurface upon frame size change
could cause us to do many unnecessary updateSurface.
bug: 25583942
Change-Id: I1989613a187bb6ef1c179bd2800c6a7b01fcdb3a
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 69cf50f759e264aea0fc7d389ae85cd3121e4cb9 |
|
13-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed bug where stack crop wasn't applied when it should
- Apply stack crop if window isn't animating when replacing window.
We were previously not applying the crop if replacing window regardless
of the animation state.
- Apply stack crop if the current docked window isn't animating.
We were previously not applying if any window in the system is animating.
- Also created setter/getter methods for WindowAnimator.mAnimating
to make debugging easier.
Bug: 25645069
Change-Id: I671549626e218358a7dea9e78bd0b2a1f1b3a51e
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 98e7eafea21a8979efa1646176fc7499b1844aba |
|
13-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Merge "Refactoring: deduplicate surface bounds calculation."
|
| 69cbc35b12fd49113bcf6c93265edc5fff3819ec |
|
11-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Refactoring: deduplicate surface bounds calculation.
This merges code from WindowStateAnimator.setSurfaceBoundariesLocked and
WindowStateAnimator.createSurfaceLocked. We calculate the final surface
size and position in both of these methods in very similar way. The
minor differences seem like small mistakes that aren't visible, because
they happen during surface creation and get fixed very soon after when
the boundaries are set.
Change-Id: I321cb17831888f97619b0cae73fdaf9cbbc762fb
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 4c9ba52acad52f1c1087415e04b2a17614707e40 |
|
11-Nov-2015 |
Chong Zhang <chz@google.com> |
Fixes for dim bounds and touch bounds
- Change dimming and touch related usage to use task's "max visible
bounds", which is the app within a task that's covering the maximum
visible area looking down from top. This solves the problem where
an app pops up a dialog window. We should dimming (and allow touch)
the entire task area, not just the dialog's visible area.
- Fix initial bounds used in drag moving/resizing, this should be
visible bounds of the app main window, not the original task bounds.
- Fix touch region set up for freeform apps, even when task is not
full screen, we should get the max visible bounds first (as freeform
app could have dialogs too).
bug: 25494928
bug: 25487005
bug: 25613403
Change-Id: Ib1c6a1665fb83ded2fcb0a7ea92cf1def5372edd
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 29ffd06d469ffb9931b8cfb29565f8ec82f18917 |
|
10-Nov-2015 |
Chong Zhang <chz@google.com> |
Merge "Don't hide wallpaper if surface is destroyed due to drag resizing"
|
| 6e21cf449af9858b69d7a6ae735d28dedbf2f4de |
|
09-Nov-2015 |
Chong Zhang <chz@google.com> |
Don't hide wallpaper if surface is destroyed due to drag resizing
We change surface from small to fullscreen size upon resizing,
and keep the old surface around until first draw finishes on the
new surface. This shouln't affect wallpaper. Hiding the wallpaper
causes the background to black out on every surface mode toggle.
bug: 25439788
Change-Id: I28c957dfaf1cc7f28e28cc00d8e97b8efb905349
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| ae814fb63e4ebdc2941c6e69f26bb37871edbddd |
|
09-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Added removed null checks around calls to WindowSurfaceController"
|
| f9e0978a053edde92ce3c1bfadaec2c02bc89ddc |
|
09-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Added removed null checks around calls to WindowSurfaceController
The checks were removed in the refactor in
e6a8351bc715999d1e42dcc1003a6eda6c318dd9
Bug: 25564523
Change-Id: Ia7c571fa48bc5c14bb76c3aa5b6fcbcc7323ed2f
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 78a08ee876794586e1d429e67d4b94209415ea5a |
|
09-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix blink when docking a window.
We need to be very precise about removing the old window when the new
one is shown. The right moment is immediately after the first frame
of the new window entrance animation gets commited. This requires
more infrastructure and flags, rather than depending on the old ones
and hoping that they will match our needs.
Bug: 25075151
Change-Id: I0fdbf38d0915ded3300d75fc7268e619b574bcf5
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 8f3978fc35e1084a763e206a1a2a3ec79ecb2eb1 |
|
06-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Merge "Fix windows disappearing when resizing freeform or docked."
|
| 10a80e0b5b2efb3a65b66dfa8b6fee6d0904ea42 |
|
06-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix windows disappearing when resizing freeform or docked.
Also includes some code clarity improvements: mHasSurface is set using a
setter, some fields get private.
Change-Id: I2f834880493c008fdccf07ff6ebfebd2e26690a9
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| dcf467ca36130aa719a4954da7578217147b20a0 |
|
05-Nov-2015 |
Jorim Jaggi <jjaggi@google.com> |
Fix flicker at the end of docked stack divider animation
Because w.isDragResize() was still true but we already
cleared the flag of the divider controller that it was
resizing, there was a frame at the end of the resize
operation at which all stack surfaces were placed at 0/0,
leading to a flicker.
Fix flicker at the end of docked stack divider animation
Because w.isDragResize() was still true but we already
cleared the flag of the divider controller that it was
resizing, there was a frame at the end of the resize
operation at which all stack surfaces were placed at 0/0,
leading to a flicker.
Change-Id: I126765a31703e5405687bcc511960a41024eb652
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 253a20fad8703e21c7298fe66e0f3f53d4e63c14 |
|
03-Nov-2015 |
Jorim Jaggi <jjaggi@google.com> |
Fix black holes and flickering in docked resizing
When we start a resize with the docked stack divider,
set the surface background to be full-screen, and use
the traditional surface clipping/positioning in window
manager to adjust the size. This ensures that we don't
have any black holes because of asynchronicity (except
at the very beginning, but this can be worked around
later), and the position of the right/bottom activity
is always in sync with the position of the divider.
Also fix a bug in NonClientDecorView where the first
request to draw was dropped (because the thread hasn't
started up yet), and the main thread was waiting for it
indefinitily.
Bug: 24507122
Change-Id: I623bd48d5be64fac2fba45241b84f265944d200d
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 63a35e2343468a04e360f0514c6c9dc03068c185 |
|
06-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix minor problems when resizing/maximizing docked window.
When maximizing the transition should originate from visible bounds, so
the first frame matches what is visible to the user. When switching to
the big surface, we only need to increase the layer by one, instead of
having artificially large value. If we use the large value, it will
cause a flicker over system windows.
Also includes some cleanup, like static imports and necessary logging.
Bug: 24913915
Change-Id: I84d7594622aa639e2008c662f941edf9c20b3202
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e6a8351bc715999d1e42dcc1003a6eda6c318dd9 |
|
04-Nov-2015 |
Robert Carr <racarr@google.com> |
Extract application window usage of SurfaceController.
Abstract the usage of SurfaceController from wm w.r.t
application windows in to a new WindowSurfaceController
class. This class tracks boring book keeping, logging,
errors, etc...to lend clarity to difficult policy
code in WindowStateAnimator et al.
Change-Id: Ifcd5d48a51e68564f49e799ae793b320cac88645
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 57f76f1c549f37ffb4c0eaac40b6ab633404b0f7 |
|
05-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Animate the dock divider appearance/disappearance.
We want to animate the dock divider appearance only after the entrance
animation of the docked activity finishes, so these two don't clash. For
disappearance they will animate together.
Bug: 24913915
Change-Id: Ibe5c3960f21fcc5e64039b158605fa09017c5c34
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 14b4e57c1ba427f07186dbff8491242162028c71 |
|
04-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Remove blink during the freeform -> recents transition.
We achieve the desired result by prolonging the last frame of the
animation until recents tells that it drew its content. The CL also
includes cleanup that moves code that depends heavily on WindowState
fields into that class.
Bug: 24913782
Change-Id: I5ee5b18504dd4a86c24033d17eca21cd31936bca
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 112eb8c1f76fff6a670d7c5f85e8c3d656cd3aa8 |
|
02-Nov-2015 |
Chong Zhang <chz@google.com> |
Save window when an app died while it's visible
- If an app died visible, keep the dead window and leave it on screen.
- Apply 50% dim over the dead window to indicate it's no longer active.
- Monitor touch inputs on the dead window and restart the app on tap.
bug: 24913379
Change-Id: I911da4e6135f2bffaf3b1bbe6f911ff689a278ff
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| c356b2a5371627992084f05bf5ab7b95d80d3967 |
|
02-Nov-2015 |
Rob Carr <racarr@google.com> |
Merge "Ensure crop rect is scaled appropriately."
|
| 1a5203dfd5264104db018b8a09d50075b1af9b2d |
|
30-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Hide recents during freeform to recents animation.
Bug: 24913782
Change-Id: I6a5d3a638640571a902e095c4c0650b88eea0fb6
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 58f2913f179f430439b4806bc15f8fd1ca6d24e4 |
|
29-Oct-2015 |
Robert Carr <racarr@google.com> |
Ensure crop rect is scaled appropriately.
Crop rectangles are scaled to layer space. Previously
we were doing this for transformation applied crops but
failing to do so for stack applied crops. This ensures
we never fail.
Bug: 23974105
Change-Id: I82f59a8696b87253f92cd89fe675aaeab0ecb38d
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| bef461f6129044bc092f0c3693bfc122d1acb6d1 |
|
27-Oct-2015 |
Chong Zhang <chz@google.com> |
Several fixes for saved surface
- Do not save if the exiting app is no longer top of task
- Mark saved surfaces as invalid when recoving memory, they will
be reclaimed if they're hidden.
- Save surface when visibility changed to GONE
- Discard saved surface after rotation
- Misc minor fixes and clean-up
bug: 19940527
Change-Id: I5760c7a7b4bf37ef6bdd39cae793a97cf7579429
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| db20b5f7a1fdb847f2266df0fbae6046dc95c757 |
|
23-Oct-2015 |
Chong Zhang <chz@google.com> |
Use saved window surface to start entering animation
When app is paused, keep the window surface around. Use it to start
enter animation if size remains unchanged on next launch.
bug: 19940527
Change-Id: Icf88d81f08b59e8bd946e410611f5098b253eb10
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| b6e66624629448b7a8c8d5d1ec62f87ba109546d |
|
26-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Improve infrastructure for replacing windows.
We need to be more precise when removing the window that is being
replaced. We used to depend on the fact that we can remove it after
the first draw of the new added window. However, due to resizing the
old window might reset its draw state and that will trigger a removal
of that window.
We need to add an information about the window that is replacing the
old one and only when this new window draws itself, we remove the old
one.
This improves the transition after maximizing docked window. This is
a situation where first resize operation finishes and immediately
after we have a replacement operation.
Bug: 24914011
Change-Id: Ia8e5bb7872787e663ba23f26588f9c4db1a5e574
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 2981ca469e76edb31f38f34d96f8da6484502212 |
|
25-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Remove incorrect log statement about showing window surface.
This log statement is purely confusing. It is logged as if it was
performing a surface operation of showing a window, but in reality
it does no such thing. Because of this the log doesn't match the
reality. Even though the window should be visible at the end of the
transaction, it isn't - the real show will be called when the
first step of the animation is performed.
Change-Id: I2b207c5df5274a67b8d650a5e84beadd7448162c
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 1ee48c4f4b756b08b4bad41910c1053323e3d445 |
|
21-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Make stack crop be aware of the big surface during resizing.
When resizing we are using big surface, so we can't depend on the
window frame to determine how to crop it to its surface.
Change-Id: I6aaa32433c5db59dfe7ccb930a0485688e6e2503
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| b8fbfb4c9f7509fe92aed262dc275342aa62cbba |
|
20-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix recents from/to full screen app transition.
The window would get cutoff at the bottom due to the way we calculate
the stack crop. The crop seems to be applied on the window before
scaling/translation is applied, so we need to use windows frame
coordinates instead of surface position.
Change-Id: I0015b9c1d1fe8e7ce8b6d94dacb5a465ff956a0c
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 955b2fc732382022959889e90694801c36b8a71a |
|
15-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Disable stack cropping for docked animating windows only.
Non docked windows should be cropped by the stack bounds when they
animate. An example of this is having both a docked activity and a full
screen activity resuming together. The full screen activity should be
cropped.
Bug: 24913915
Change-Id: I35ed71e7625f2fcdb5c51649be9f33d5773c162c
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| efd3d1b41f5c9ced2b6eed4ab6f95a267bcde9f2 |
|
14-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix misaligned from and to recents animation.
Because of the small translation that accounts for the status bar, the
animating window gets cropped at the beginning of from recents and at
the end of to recents animation.
Change-Id: I36878c6ff84903db05335890b03199878174c5af
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 2a6a2c2de8ce2743679f488f056f22cd1adfd726 |
|
14-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Change WindowState.mShownFrame to WindowState.mShownPosition.
We never use this field as a rectangle, we only depend on its left-top
corner. Using a frame is only confusing about the purpose of this field.
Change-Id: I5d6e6321db4fa3203bb7e0f1975ae6ddd1ec09bb
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 97782b4042f3189c4e06463f8ab8122b26e77a29 |
|
08-Oct-2015 |
Chong Zhang <chz@google.com> |
Fix flash due to not freezing screen when start/end resizing
Instead of freezing the entire screen, preserve the window's old
surface and put it on a layer that's above other windows (while
still below the screen rotation freeze layer). Only remove the
surface when animation starts after the new drawing is received.
bug: 24715185
Change-Id: I1d2b873d339d672cea0f18679b5622cea69bd449
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 9c450411058ab9af71932c756fb0f478b3988f1b |
|
01-Oct-2015 |
Chet Haase <chet@google.com> |
Enable activity rendering during window animations
A change was made back in ICS that prevents the view hierarchy from rendering
during window animations. Specifically, it allows the hierarchy to render once (to draw
the results of its first layout), but further drawing is suppressed at the
ViewRoot/performTraversals level until the window animation is complete.
This change was introduced to avoid jank problems that were resulting from
thrashing the GPU by issuing drawing commands from multiple processes simultaneously,
and limited the number of rendering processes to mainly the system server (and
possibly the System UI), which allowed window animations to be much smoother.
This fix contributed to another source of jank, however, in which applications
which attempt to animate when they first appear will not render any frames of
animations until the window animation is done, resulting is a snapping to the resulting
state once the window animations are complete.
Meanwhile, hardware has gotten faster and GPUs have gotten better, and it is time to
revisit this logic. This change disables the earlier fix and allows view hierarchies
to draw normally, regardless of whether window animations are taking place.
Issue #22232939 Remove flag that prevents drawing during window animations
Change-Id: I4c960180771ff09a7088abd77b437586e835a991
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 0689ae903628f12ff073376b655b9d972533796b |
|
01-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix lack of dim layer behind "Power off" window.
This enables dim behind functionality for both tasks and stacks and
groups it inside a controller that manages the dim layers (including
shared dim layers for full screen tasks/stacks).
Bug: 24331704
Change-Id: I0d1ba996d9e00d05e0203166b82268da00fbb35e
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 12a2ab4cc83df0df5450033e85d24fdc90cc63f3 |
|
01-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Merge "Revert "Refactoring: two more calls for WindowState.setDisplayLayoutNeeded.""
|
| 921171afcc7b3afb587573ba2614ca4e8c394667 |
|
01-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Revert "Refactoring: two more calls for WindowState.setDisplayLayoutNeeded."
This reverts commit b3acc92bff3594b73eb80fad2a5fe79541e4a095.
Change-Id: Ief0f3ca1d45be5838a826494f64c65776868d188
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 30bc0ec2469d87a3c982beb24e12ab8d7a6e18b4 |
|
30-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Merge "Refactoring: two more calls for WindowState.setDisplayLayoutNeeded."
|
| e95b0aef6d259ff9322bd9a34e36e61737844eee |
|
30-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Improve visibility and layering of dock divider.
We adjust the visiblity of the divider now after every layout.
The divider was far too high in the priority list, based on the wrong
assumption that as a part of the system UI it needs to be constantly
visible. It should stay at the same level as applications, because it's
almost as a part of application.
Layering gets improved by having the relaunch animation receive zorder
top, just as if it was entering. The window that is being replaced fakes
this too, since it's not being animated, but should share the behavior.
Bug: 24500829
Change-Id: Iad3369a5ab6721b1bf7a94e8979dcf33e0805c7f
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| b3acc92bff3594b73eb80fad2a5fe79541e4a095 |
|
30-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Refactoring: two more calls for WindowState.setDisplayLayoutNeeded.
Change-Id: I2037bda03644f16ab03145eea257714b974a3059
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e7bf46b7c2222e81b43702450baf5009f7bf46a9 |
|
30-Sep-2015 |
Wale Ogunwale <ogunwale@google.com> |
Don't make surface opaque when resizing window
This helps reduce some of the artifacts shown in areas the app isn't
drawing content when resizing using the docked divider.
Bug: 24507122
Change-Id: I08a2c3ccd5cb5366c8278f62a5808b12ca09154d
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 7cc2ad0a31f49a9e498c77ef7eec6b8333169d48 |
|
27-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Merge "Entry animation for docking windows."
|
| 49b80afaf9e71d6b5d4cab26f1459d84d1070f19 |
|
24-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Entry animation for docking windows.
We achieve the animation in the same way we would do that for maximizing
windows. We preserve the exiting window of relaunched activity until the
activity adds a new one. Then we animation the new window from the
bounds of the old window to the dock bounds.
This mostly reuses existing infrastructure for maximize animations, but
unfortunately needs scaling. The before window might be have one
dimension larger than after window and using cropping is not sufficient.
Change-Id: I9538ba983a0af1e64ea48aad6836173d6fd25f3b
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 2f0fe62c5426533ccdf9ec7ef28027c367286979 |
|
25-Sep-2015 |
Robert Carr <racarr@google.com> |
WindowStateAnimation: Clear transformation clip rect.
Ensure the clip rect taken from transformations is cleared
when there is no transformation. Normally the failure to
clear the clip would not cause a problem, as the final clip
would be equal to the window size. However, in the event that
the window scale goes on to change (WindowState::m(H/V)Scale that is)
the clip will now be specified at the inappropriate scale (notice the
way the clip must be divided by H/VScale as SurfaceFlinger will apply
the surface transform to the clip).
Bug:23974105
Change-Id: I4548e8ecea8d66d4942e99823653a7b05f87cea0
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 3005e75585dcda30b64603e320e0711b583624dd |
|
19-Sep-2015 |
Chong Zhang <chz@google.com> |
Misc fixes for window moving and resizing
- Do not skip resizeTask if we're starting or ending drag. We need
the relayout because surface mode is changing.
- When we're changing the surface mode, need to wait for the first
draw to finish before we can modify shown frame. Otherwise there
could be 1 old frame displayed with new position, which makes the
window position look a bit off.
- Clean up dragResizing/dragResizeChanged flags.
Change-Id: Ia396d6b88fd616ad57aa8cd24ca7e1161add7205
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 87975b77bcebc786706117c7e8de9c29bd89631c |
|
17-Sep-2015 |
Chong Zhang <chz@google.com> |
Merge "Place surface at screen't top-left when doing drag resizing"
|
| 0275e397f482a1f25745a66c5db68c3a6c863951 |
|
17-Sep-2015 |
Chong Zhang <chz@google.com> |
Place surface at screen't top-left when doing drag resizing
Instead of letting the client render to (0,0) and moving the surface
around, put the surface at a fixed location, and let the client render
to the screen position within the surface.
This fixes the window shaking problem when resizing by dragging window's
top-left corner. The frame rect used in last draw is lagging window
manager's latest bounds for the window, moving the surface's position
would make the window's bottom-right corner appears moving (while it's
supposed to be stationary).
bug: 23793966
Change-Id: Ideb152fc48502f8e9672235f10b044889235e7df
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 61b009e0591df4fcaf5c57c6ce598044263d952f |
|
17-Sep-2015 |
Wale Ogunwale <ogunwale@google.com> |
Don't crop home activity windows to stack bounds.
We crop windows to their stack bounds when the docked stack
exists. We don't want to do this for the home activity since
the docked stack isn't visible when the home activity is visible.
Change-Id: Ibb3157dabbb6c979358ddc2098a01c6ddf6540e8
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 0ba68c380f0ac65b82fa0031264d06781af09438 |
|
15-Sep-2015 |
Chong Zhang <chz@google.com> |
Merge "Use fullscreen sized buffer for drag resizing"
|
| 09b21efb97d539543259b33e2da9d4c7a41966c8 |
|
14-Sep-2015 |
Chong Zhang <chz@google.com> |
Use fullscreen sized buffer for drag resizing
- When drag resizing starts, set the surface size to fullscreen
(plus any surface insets requested by win attrs), so that we don't
reallocate buffers and the buffers don't get rejected by surfaceflinger
due to size-mismatch.
- When drag resizing ends, restore the surface size to the original.
- Update shown frame before setSurfaceBoundariesLocked(), as the top-left
of the window could change, we need to update the surface position. This
fixes incorrect window positing during resizing by corners on top/left.
- When doing tap-detection, skip non-freeformed tasks. This fixes the
bug where clicking near border of a window could dismiss it.
Change-Id: I5dc9fc34ff05685320b8fe5d491b9c066c6726e8
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 4b8eea7d106293c9bc96d4875e195a9d413d76cf |
|
15-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Crop application windows to their stack bounds.
We don't want applications to put their content outside of the area
designated by their stacks. However, we don't want to affect their
frames or task bounds. Instead, we crop their surfaces to the bounds
so they don't extend outside of the stack.
Change-Id: I7231c4baa437eefaa6bd7ba89dbc3d5038496c46
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 24966d4789c7a2054650ec1a5ed7450f0d691224 |
|
06-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Refactorings for Window Manager module.
Following improvements were applied:
* extract code from a very large method
WindowSurfacePlacer.performSurfacePlacementInner into
WindowsurfacePlacer.applySurfaceChangesTransaction; smaller methods
are easier to understand;
* WindowStateAnimator.showSurfaceRobustlyLocked can be privatized, it
is only called from one place; also there is unnecessary check for
whether mSurfaceControl is not null;
* prepareAppTransition code can be mostly moved into AppTransition;
it calls mostly methods from this class; as a result some methods
from AppTransition can be privatized;
* requestTraversalLocked can be moved into WindowSurfacePlacer, which
allows mTraversalScheduled to be a private field inside the placer;
this way WindowSurfacePlacer can nicely control and hide the need for
layouts.
Change-Id: I99006c859ef224f5dad933f5c15d2cb2b9738a9e
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 55a309f8e2a972a2f0ef0cd86736d3c2f47a75f6 |
|
05-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Maximize animation when activity is relaunched.
This is the first step towards maximize operation animations. It
builds upon preserving old window and starts clip+translate animation
of the new window from the frame of the old window. It mostly uses the
existing infrastructure, expanding the idea of opening apps list to
include also relaunching apps and treating maximize operation as an app
transition.
Change-Id: I7be402bd329c2fe5bf7d53a2a910532286a8b194
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 76cc44f31c6cc20c4bc2d6ec46c4b37da1a811a3 |
|
04-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Defer removal of relaunching activity window due to config change.
This is the first step towards having a better maximization experience.
When the window gets replaced during relaunch of maximized activity we
keep the old window around until the new one is added.
Change-Id: Ia8ce26aee6577740cd38096ed2633216a07ceb60
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 4501d23cedbaaa33a7a28a76af61e7b097dc2d66 |
|
02-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Refactor layout and surface placement into a separate class.
OMG, WindowManagerService below 10kLOC. Barely.
Change-Id: I7062c10c767c01c08466b3903736ee35b341f2a5
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| ece91acc0313b520531b9e729a53776ff67a4d61 |
|
25-Aug-2015 |
Adrian Roos <roosa@google.com> |
am 523be967: am a6774c5c: am 7edca79e: am 8a8885b9: am def6896d: Fix shifted wallpaper after OTA
* commit '523be967bdf2a61ff1390e158e0f4b834e358cad':
Fix shifted wallpaper after OTA
|
| def6896d10ce4869831bf91eb73709e8a9714b27 |
|
24-Aug-2015 |
Adrian Roos <roosa@google.com> |
Fix shifted wallpaper after OTA
Fixes a bug where WindowManager's and SurfaceFlinger's
view of the wallpaper's position could get out of sync.
Bug: 13020924
Change-Id: Iad17b0f516fffacd2877ceac40fcc8e2647c06b2
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e8069dcfcff15e060fc397b9ed5ea8b915b1cfa7 |
|
18-Aug-2015 |
Wale Ogunwale <ogunwale@google.com> |
Moved window manager wallpaper control into separate class
Change-Id: Ia3c12065678992614667dc210d4611a1250ca22b
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 5731754954c9f0edc677bff85b59a4721e7252c7 |
|
18-Aug-2015 |
Filip Gruszczynski <gruszczy@google.com> |
am e1e9e811: am d29dd0c9: am b59404a1: am eb2f302d: am 610008c0: Merge "Clear old clip rect when creating new surface." into mnc-dev
* commit 'e1e9e811ab06a85a6494bebca0f530c8f0ed7268':
Clear old clip rect when creating new surface.
|
| 3fcb5d66e4cb95a327ffc867847b16bf10fef0db |
|
18-Aug-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Clear old clip rect when creating new surface.
This fixes an issue where a window state animator holds on to old clip
rect from previous transition and applies it to the newly created surface.
Bug: 22851074
Change-Id: Ic416a2a0c5d0f69fc80d5656541256ade41c9c36
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 9ca40b7a0ff79cc29d9875d313d1dc2731ccea5c |
|
13-Aug-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Apply window position translation after app transforms.
If this translation is applied prematurely and the app transform
includes scaling, this translation will be affected and as a result it
will move the window.
Change-Id: Iaf7d104708f0775384495e42dbd82cb9ae03b8f7
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 8a911ea8e838464f6b7d197c414e7f7f9a84ae58 |
|
01-Aug-2015 |
Dianne Hackborn <hackbod@google.com> |
am 2b38a45b: am 44ffe9cb: am cba2c596: am 6aa0843e: am fb68b0ad: Merge "Fix issue #21895842: Add is_assist_blocked to assist.ViewNode.NodeProperties" into mnc-dev
* commit '2b38a45bf37846d0a210369e41efd70738e3d591':
Fix issue #21895842: Add is_assist_blocked to assist.ViewNode.NodeProperties
|
| 27b3ce5452353e9459a57dcfbecd185d64633bdf |
|
01-Aug-2015 |
Wale Ogunwale <ogunwale@google.com> |
am 40ba7b5e: am 1e93d7e8: am 0e0be5c7: am 88cf6d62: am f7e00dbd: Merge "Fixed issue with artifacts during scale-up transition animation" into mnc-dev
* commit '40ba7b5e1eb0a08c6e11fd6b0b16e0edc4f3a818':
Fixed issue with artifacts during scale-up transition animation
|
| fb68b0ad344edbba15b961dc444cb24dcfc29995 |
|
01-Aug-2015 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #21895842: Add is_assist_blocked to assist.ViewNode.NodeProperties" into mnc-dev
|
| afb308d6519c56cf2b8001b33dade35e682ab241 |
|
31-Jul-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #21895842: Add is_assist_blocked to assist.ViewNode.NodeProperties
Change-Id: I928882d42d0546cc6a12e803d96131beaba76d4e
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e4a0c5722b1d8db95dfc842d716452dbbf02c86d |
|
30-Jun-2015 |
Wale Ogunwale <ogunwale@google.com> |
Allow stacks to hold tasks on various sizes.
Tasks are now resizeable just like stacks. Adjusting the size
of a stack will also adjust the size of all it's containing
tasks. This model allows us to be more flexible
in using stacks as workspaces (like you would have in a
desktop environment) and tasks as the resizeable windows
within the workspace.
Also added "adb shell dumpsys window visible-apps" for
getting the list of visible app windows.
Bug: 22068114
Bug: 19182363
Change-Id: I5bf77063252a5abae4e327f6fc42e607091749f9
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| b3eba81442a23655c6176b15e5c4f2f6e453bd51 |
|
31-Jul-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed issue with artifacts during scale-up transition animation
It is possible to get some artifacts during scale-up transition
animation of some fullscreen activities like Chrome. This is
caused by the clip rect specified by the transformation extending
outside the sys decor rect. We now contain the clip rect within
the system decor rect.
Also note that we don't want to do this for none-fullscreen
activities as it might cause some premature clipping.
Bug: 22830775
Bug: 21727851
Bug: 20652683
Bug: 19523205
Bug: 15046646
https://code.google.com/p/android/issues/detail?id=161362
Change-Id: I33827caaa256ad8fdc0eb3650ef34e95c48a6988
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 4eef94f2b82f4b86e6d78f752d0f8895acf78cee |
|
18-Jul-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed issue with background user window consuming touch events
When adding a window for a background user, it is possible for
the window to consume touch events because it is in the
COMMIT_DRAW_PENDING state. We allow the background user window
to transition READY_TO_SHOW state, but hide the window.
Change is based on https://android-review.googlesource.com/#/c/158772
and also reverts commits 6ee618509a392adb183c2e70390cd9e2031ff0d8
and 588932a53e63c0a7ee281dea22559c129b40eb99
Bug: 22531717
Bug: 22207948
Bug: 18510914
https://code.google.com/p/android-developer-preview/issues/detail?id=2667
Change-Id: I68d2e532c2b1def0d7b22c9b60e48110cf3cd686
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 880a54f6d85f5880a79ff94b2116ab2c12ea2fd8 |
|
07-Jul-2015 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Cleaned-up logic for determining clip rect for transitions animations." into mnc-dev
|
| 35a57f81a963eaa3739cfcacd4f9f309d433487f |
|
02-Jul-2015 |
Wale Ogunwale <ogunwale@google.com> |
Cleaned-up logic for determining clip rect for transitions animations.
Previous logic led to several edge cases which fixes sometimes broke
other edge cases. New logic uses the clip rect provided by the
transformation as-is and doesn't try to adjust it based on window
flags. Correct clip rect is set in
WindowManagerService#applyAnimationLock using the content insets
before the animation is loaded.
Bug: 21727851
Bug: 20652683
Bug: 19523205
Bug: 15046646
https://code.google.com/p/android/issues/detail?id=161362
Change-Id: I2d4ed6196edb8ee8c401fe9a242aec70d3494574
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| c5af4f8421926ea17cf51a9a53f91f5fec467588 |
|
02-Jul-2015 |
Jorim Jaggi <jjaggi@google.com> |
Don't prevent windows from drawing when they are just moving
Bug: 21292010
Change-Id: I0cf459d75e9749afa58a4b8649457b3908c8adeb
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| f5ad42f4324bfb7aa28f0967e2fcc89f55d6e91f |
|
12-Jun-2015 |
Wale Ogunwale <ogunwale@google.com> |
Update surfaces secure flag on screen capture setting change
Also, added 'wm screen-capture [userId] [true|false]'
command.
Bug: 20934462
Change-Id: I14711003d7691fc4495428c12c9ff3457cd3773c
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 77963292a19255b883fb5e524b30efd201d804c6 |
|
26-Feb-2015 |
seunghyun85.lee <seunghyun85.lee@lge.com> |
Apply the scale to surfaceinsets when computing crop region
While in computing surface crop region, magnification specs are
not applied to surface insets from LayoutParams.
So, in case magnification specs are set,
surface crop region should be calculated considering scale factor.
(For instance, using TouchZoom in Accessibility
at AppsPermissionActivity in market app)
Bug: 20863078
Change-Id: I9e7e21e502b29208f2856918d6fcda050f515595
Signed-off-by: Seunghyun Lee <seunghyun85.lee@lge.com>
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 7dcf08c6b2778b60992005b16d8fb297e6ec499a |
|
06-Jun-2015 |
Stefan Kuhne <skuhne@google.com> |
Dont create a dummy animation for a transferred animation
When multiple windows get created at once, multiple starting windows
will be created as well. The first window will get an animation and a
dummy animation. If another window will get shown shortly after, it
will receive the animation of the first starting window. However, no
new dummy animation should be created for it since otherwise it might
never get an animation end notification.
This CL also reverts previously added changes to ignore dummy animations.
reverted change: Ie907d31f51e130e245a70249a983d490f3d42b21
Bug: 21643278
Bug: 21403998
Change-Id: I228d77a2d9c3597df0eb9c340a65c0c592c35ce6
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 79f4718d7cb7e4a7b43dff9618bd4edd884ed6de |
|
03-Jun-2015 |
Stefan Kuhne <skuhne@google.com> |
Don't leak windows on removal with dummy animations
Dummy animations might never end. Do not hold a window removal
for it.
Bug: 21403998
Change-Id: Ie907d31f51e130e245a70249a983d490f3d42b21
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 80181b99c7be562b24095ee495712f7197229c74 |
|
19-May-2015 |
John Reck <jreck@google.com> |
Don't recreate the surface unnecessarily
Bug: 19896200
The flicker is caused because ViewRootImpl is
requesting a change from OPAQUE to TRANSLUCENT due
to the presence of a GLSurfaceView. However, WindowManager
will use this as a signal to recreate the SurfaceControl.
This is not actually correct, as the underlying format
of the SurfaceControl was *already* TRANSLUCENT due to being
hardware accelerated. Add a fast-path for this step
where the format didn't actually change such that all that is
necessary is for the OPAQUE flag to be flushed through
to SurfaceFlinger.
This doesn't address the larger, more complex issue of a surface
flickering if the pixel format really did need to change, but
this should address the common case.
Change-Id: Ia5275705733123a3d7929bf5951829415753e2b2
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| b7f3f92ac200fb22cd8d880b63a5c0ef2bad5354 |
|
27-Apr-2015 |
tiger_huang <tiger_huang@htc.com> |
Use the correct parent size to initialize animations
The original logic would use out-of-date parent sizes to initialize
animations. If the screen size is changed after assigning mAnimDw and
mAnimDh in the constructor of WindowStateAnimator, the fromDeltaY
(in the most cases) of TranslateAnimation would be initialized
incorrectly.
In this change, we always use up-to-date parent sizes to initialize
animations to prevent the issue.
https://code.google.com/p/android/issues/detail?id=170348
Change-Id: Ib9c609121228934bdb463263feb1924eb389c1d2
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 827e0facfefd0c0033dcfb1747b4fa6f80f9e0e2 |
|
07-May-2015 |
Jorim Jaggi <jjaggi@google.com> |
Make sure the app can draw a frame before unlocking
- The mechanism to stop windows drawing while window animator was
animating was somehow flaky. It relied on the fact that the client
would call relayout() whenever the animating state changed. This is
mostly the case, but not for lockscreen animations. Instead, we now
use a push model, where window manager tells the app that the state
has changed.
- In addition, it only stopped drawing if that window was animating,
but then only resumed drawing after all windows have finished
animating. Now, we do this per window, so we only stop drawing for
windows that are currently animating.
- We resume the top activity now at the very beginning of the
unlocking sequence. This gives the app a chance to draw a frame
before the user sees anything. If it's to slow, then we just use the
outdated framebuffer.
Bug: 19964562
Change-Id: Ifef8abd189a3146d854b81b9b948861e4d38c155
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 9a5d77894c72972bf90a13002ef7c9967c2b5da5 |
|
16-Jan-2015 |
tingna_sung <tingna_sung@htc.com> |
Don't apply animation clip to dialog activities
If launching a dialog activity from Recents app UI, the top region
of this dialog will be clipped. This is caused by applying clip rect
animation effect for Recents app scale up/down transition.
However, the clip rect animation is not needed for non-inset decor
app window, e.g. dialog activity.
https://code.google.com/p/android/issues/detail?id=161362
Bug: 20652683
Bug: 19523205
Change-Id: Ida8c3b28b3789061d6ebb662bc08738d7daec3a0
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 80b1f64280829e7d483302c23518e9d937e7340a |
|
22-Apr-2015 |
Craig Mautner <cmautner@google.com> |
Fix bad crop on clip reveal animation
For non-fullscreen apps the dimensions of the app window must be used
to set up the animation.
Fixes bug 18392184.
Change-Id: Ia1681e4a2cb74be2f820cb76ddc7c651a5e4aab6
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 20fee4f657ba9ec1766db1d189c9bd10fd5c1b7e |
|
07-Apr-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed glitch in NuPlayer when surface size changes
When VideoView calls setFixedSize(), the SurfaceControl.setSize()
gets called from WindowStateAnimator.setSurfaceBoundariesLocked,
but setSurfaceBoundariesLocked only updates the size, not the
transform matrix/scaling factor.
The after some time, SurfaceControl.setMatrix gets called by
WindowStateAnimator.prepareSurfaceLocked. It updates both size and
matrix (size update is skipped since it's already updated by
setSurfaceBoundariesLocked earlier). This corrects the transform
matrix, and restores video rendering.
We now call setMatrix() in setSurfaceBoundariesLocked() to avoid
the glitch.
Bug: 18773834
Change-Id: I5e8de38495fabe54eefa8bd3003627d11392c0f1
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 4c8b7953f9d2b56477620124b3c0ce9e0d825cf2 |
|
07-Apr-2015 |
Wale Ogunwale <ogunwale@google.com> |
Revert "fix the flash caused by missing setMatrix() when surface size changes"
This reverts commit 7f97af11fba6a18ee6bc022f7197319ce54fa46f.
Change broke screen_on functionality when an alarm goes off.
Bug: 20096335
Bug: 18773834
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 7f97af11fba6a18ee6bc022f7197319ce54fa46f |
|
05-Jan-2015 |
Chong Zhang <chz@google.com> |
fix the flash caused by missing setMatrix() when surface size changes
bug: 18773834
Change-Id: I16e2f896e6fd70e9b130bb55ecefa8c2f08c684a
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 8da976a4302cb947f841f4a995bfa5fb62ca296d |
|
05-Mar-2015 |
Chet Haase <chet@google.com> |
Fix artifacts in clip reveal animations
clip-reveal the entire screen, not just the app window contents.
Also, account for position of window in non-fullscreen apps.
Issue #19638386 fix launch animation artifacts
Change-Id: I08bc09a89974e28af72c08ddd61bd555e5330221
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 378756154fce86b53e91746583bfe15996ef680b |
|
19-Feb-2015 |
Jorim Jaggi <jjaggi@google.com> |
Stop app transition based on mAppWindowAnimating field
Bug: 19440051
Change-Id: Ic385eab15cca8c5b814dc9cdbfd2d2f79fd84b02
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 857bb559c55968b5b28aac88c6a77b9b0370ee08 |
|
12-Feb-2015 |
Craig Mautner <cmautner@google.com> |
Merge "Refactor of wallpaper methods."
|
| c431e89a8bc9fcc6e5beb6efacd1d30500f5e574 |
|
11-Feb-2015 |
Craig Mautner <cmautner@google.com> |
Refactor of wallpaper methods.
Also remove token from mWallpaperTokens in cases where it might
have been missed.
Change-Id: I90befbf368b65e8c3403d5958e14355b884801a5
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| ae0fdaf5e864ab755e54243006e7116fbb375a7b |
|
12-Feb-2015 |
Craig Mautner <cmautner@google.com> |
am 3d576cc6: am 18d836b6: Merge "Don\'t relayout based on a window that isn\'t visible" into lmp-mr1-modular-dev
* commit '3d576cc643497e5a4f0285dea75b7ba5e964009c':
Don't relayout based on a window that isn't visible
|
| 082500c76e82139208b3792cdbc283ef59092e16 |
|
11-Feb-2015 |
Craig Mautner <cmautner@google.com> |
Don't relayout based on a window that isn't visible
The method commitFinishDrawingLocked returned true even if the window
it was called for was hidden. By returning the value that
performShowLocked() returns it only returns true if the window is
shown.
Fixes bug 19100757.
Change-Id: I45df70aedcb3909561fd3a19e861579a11521db9
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 165be0c70d128f0ece876d54e1c7e95ef04c6960 |
|
28-Jan-2015 |
Craig Mautner <cmautner@google.com> |
Remove TYPE_UNIVERSE_BACKGROUND from system
An experiment that is over and has been occupying space.
Fixes bug 18088522 item #7
Change-Id: Ib0fcaa24243ed9b0581143e1d5114c1fd2b0aa6e
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 75b55d0846159543aafc1b7420915497fce9b3f1 |
|
04-Dec-2014 |
Svetoslav <svetoslavganov@google.com> |
Notify accessibility for window changes after an app animation end.
Accessibility layer keeps track of the introspectable windows. These
windows are received from the window manager which computes them after
an interesting window transition. The window manager was not sending
the windows to the accessibiltiy manager after an app animation is
completed and as a result the window location reported to accessibility
service was wrong which also resulted in wrong visible to user state
for the nodes in the window.
bug:18517058
Change-Id: I21d65a4e0c0dff9474f7cc47ea819ace5ac1e465
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| f8d77da969edc2f191d349f7d9a30d02edcbd388 |
|
11-Nov-2014 |
Jorim Jaggi <jjaggi@google.com> |
Improve lockscreen launch animations
- Add a timeout so if WindowManager "forgets" to tell that the
activity has drawn, we still unlock after 3 seconds, so the user
is not completely stuck.
- Use the screen height instead of the window height for the
translation animation.
- Don't run the animation if the attached window is not null. The
animation from the attached window will influence the transformation
as well, so there is no need to run an additional animation in this
case (apps with SurfaceView's had broken unlock transitions because
of this).
- If the starting window needs to go away while the unlock transition
is running, modify the existing animation such that it fades out in
the same transition.
Bug: 15991916
Change-Id: Ia5dfa31e1bc0d5745fe228e1daf08e268733b6f1
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 44f60cca7bb31e2f9b4b7bf25bb2e0cfb0e3e1e1 |
|
07-Nov-2014 |
Jorim Jaggi <jjaggi@google.com> |
Fix lockscreen launch animations once and for all
In SysUI, make sure not to dismiss Keyguard multiple times when just
waiting for a deferred dismissal, so WindowManager doesn't get
multiple calls to keyguardGoingAway.
Change heuristics how notifying Keyguard about activity drawn works.
Always notify Keyguard after executing an app transition, and notify
it also when not doing a transition after a startActivity call.
For that to work, update AppWindowToken.startingDisplayed also when
the window is displayed, but force hidden because of Keyguard.
Further, handle the case correctly when a window gets added during
the Keyguard exit animation by overriding the start time for the
animation of that new window. Also don't apply a transition animation
for a window when executing keyguard exit animation, so by removing
a starting window we don't break this animation.
Last but not least, tell Keyguard to start exiting immediately if
animations for exiting are disabled, like when going to phone/camera
on lockscreen. Before, we always had a delay of 1 second because we
waited for the timeout.
Bug: 1599196
Bug: 18272544
Change-Id: I596b2489f814b934abd256e16079d3d3f326e209
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 42d04db459e5a510c8c815c38e17e419c3e3b404 |
|
06-Nov-2014 |
Craig Mautner <cmautner@google.com> |
More fixes for keyguard animations.
Add a state machine for calling comeOutOfSleepIfNeededLocked() so
that it is only called after the lockscreen has started dismissing
but not before resumeTopActivityLocked(). Also keep
resumeTopActivityLocked() from being called from
comeOutOfSleepIfNeededLocked() recursively.
Have starting windows count towards notifying the keyguard that a
window has been drawn.
Do not update wallpaper animations based on their not being included
in the windows being animated if there are no windows being animated.
And always improve logging.
Fixes bug 15991916.
Change-Id: I0d21c5337f0e89d9eacc8dab2cdaa52fec43ac0b
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 9128396982233d6af49613231100f1bc4b6c477b |
|
05-Nov-2014 |
Winson Chung <winsonc@google.com> |
Merge "Fixing crash in recents window transition. (Bug 18246975, 18159006)" into lmp-mr1-dev
|
| 276a6eb879801e7e7988ecb0e6f29241e9a52724 |
|
05-Nov-2014 |
Craig Mautner <cmautner@google.com> |
When keyguard exits use same anim for all windows
The entering animations were only applied to the incoming windows
one time. If those windows weren't drawn yet then they never had
an animation assigned.
Furthermore if a starting window was drawn in time it would get the
animation but its main window would not get it if it weren't drawn.
Even if an animation were assigned later they wouldn't be synced
with each other.
This change creates a single animation which is shared by all
incoming windows. As windows are drawn they can then animate with
the starting window.
(Also refactorings to eliminate redundant code and unnecessary
variables.)
Fixes bug 15991916.
Change-Id: I844d102439b6eda8c912108431916e04b12f7298
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| ab79fce2e71b6816b2b88b826ca723b3591f1e26 |
|
05-Nov-2014 |
Winson Chung <winsonc@google.com> |
Fixing crash in recents window transition. (Bug 18246975, 18159006)
The recents transition requires synchronizing the thumbnail header (the bar
that animates on top of the window that is being scaled/cropped) and the
application window. This change simplifies the code and removes the notion
of having another animator manage the same surface, and instead ensures that
the thumbnail animation has the same duration and that the thumbnail animation
is deferred and cleaned up one frame after the app transition is complete.
Change-Id: If8f348afccf59327187e8498eb451ba066600a41
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 9c79504225f60c72c947220b6aca928f11279e1c |
|
29-Oct-2014 |
Craig Mautner <cmautner@google.com> |
Add enter-animation-done callback for system windows
Existing hidden methods allow activities to be notified when their
windows have completed animating in. This change adds that capability
to system windows using a ViewTreeObserver callback since system
windows lack an activity token.
The first subsystem to use this is the UserSwitchingDialog which was
previously using a 250 msec timeout to dismiss the dialog. That
deadline was often missed leaving the user with no dialog on the
screen during the transition.
Fixes bug 16661752.
Change-Id: I70789e0d9c07112f275e76fb82850926305f290d
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 49a2edf92ab9b02762a2c183809fdee55b0fcf40 |
|
25-Sep-2014 |
Craig Mautner <cmautner@google.com> |
Call Surface.release() for starting windows
If the window maanger received BinderDied for a starting window
before activity manager then it would null
AppWindowToken.startingWindow and not go through the
PhoneWindowManager.removeStartingWindow call later. That meant that
Surface.release() was never called from
ViewRootImpl.dispatchDetachedFromWindow(). Which in turn meant that
graphics memory was being leaked.
This change notifies the PhoneWindowManager to go through the
removeStartingWindow path when the starting window gets removed for
any reason.
This change also ensures that scheduleRemoveStartingWindow is
always called with the window manager lock held.
Fixes bug 17381033.
Change-Id: Ic6860d0e1410c9bb5053d85ae21a08b11f573b6d
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 0ed82e2c21f861ac4e1e6ae3f3fa821886a55a41 |
|
20-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #17381033: Program icon and shortcut disappear after...
...running monkey test overnight [FACTORY ROM BLOCKER]
Add surface tracing to debug output.
Change-Id: I65f7fc90c51b0805f7e0090141c33d6b60ccb3b4
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| ce4a0cf9cee73a2d6b1444d15d663e564a12593a |
|
15-Sep-2014 |
Adrian Roos <roosa@google.com> |
Properly redispatch systemUiVisibility flags
Fixes two bugs introduced by change
I7bd32531130d199c0734ffcb800194e77b7e16c3:
When the system window insets consumed by DecorView
change as a result of changing flags, the insets must
be redispatched to the hierarchy.
Also fixes a bug where, as a result of removing the wrong
implication of the SYSTEM_UI_FLAG_LAYOUT_STABLE flag by
FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS, the status bar was
being forced to black when returning from recents.
Bug: 17489047
Bug: 15046646
Change-Id: I127b0ff3b17c4873a7c28d67020f84298ed09db2
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 41a7b7911eb7f1253c9037e70a6ffca9c535898d |
|
12-Sep-2014 |
Craig Mautner <cmautner@google.com> |
Add null checks to WindowState.getStack() calls.
Fixes bug 12786011.
Change-Id: I7fed856f8c96eec47df0912cea9bce705ecf690a
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| bb8c4834613207cf880e8491b33eb495cc268548 |
|
09-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Merge "Add new wallpaper features for insets and offsets." into lmp-dev
|
| 067e5f68b9216b233df1c6529db182ff9b2887ab |
|
08-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Add new wallpaper features for insets and offsets.
Issue #17394151: WallpaperService / Engines need to get notified
of WindowInsets
Issue #17394203 Wallpapers need a system API to be shifted in order
to support burn in protection
Adds a new API on WallpaperManager to set additional offsets to
make wallpapers extend beyond the display size.
Insets are now reported to wallpapers, to use as they may. This
includes information about the above offsets, so they can place
their content within the visible area. And to help with this, also
expose the stable offsets APIs in WindowInsets which is also very
useful information for the wallpaper.
Another new API on WallpaperManager to set a raw offset to apply
to the wallpaper window, forcing it to move on the screen regardless
of what the wallpaper is drawing.
Fix wallpapers when used with overscan enabled, so they still extend
out across the entire screen. Conveniently, the above new window
insets information is very useful for this case as well!
And a new wallpaper test app for all this stuff.
Change-Id: I287ee36581283dd34607609fcd3170d99d120d8e
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 6f61204bcaa05ed846f67fd63769f63518e9ae85 |
|
07-Sep-2014 |
Craig Mautner <cmautner@google.com> |
Lock down window manager while changing opacity
Surfaces were being modified after destroy(). The check for mSurface
being null was not done while holding window the window manager lock.
This change adds locking to the surface modification methods.
Fixes bug 17383628.
Change-Id: I12ebbddc0f2cd7b43659370fac2c4fb053999bb5
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 78505d8d096af2981fb39f1a03f9025fd04add77 |
|
02-Sep-2014 |
Craig Mautner <cmautner@google.com> |
Account for scaling effects when cropping
When a scaled window inherits the crop from an attached animating
window the scaling must be accounted for or the crop will obscure
the scaled window.
In the case of the bug that this CL fixes, the SurfaceView containing
a video was scaled down from 1920x1080 by a factor of 0.562 to fit in
1080 width. The crop applied to the window was 1080 but this was passed
to surfaceflinger which ended up cropping the width to 608 due to the
scaling.
Applying the scaling factor to the crop rectangle fixes this bug.
Fixes bug 16334217.
Change-Id: Iafefe43d3696d9fbff01a3666096348468a41e1a
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 868d74536e60914acb4f63d11e2d32417b78382e |
|
28-Aug-2014 |
Chris Craik <ccraik@google.com> |
Force translucency for inset windows
bug:17289912
Change-Id: Ic800f07bce78e0a3538a6afd7ec293d9f8ddad9d
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| a4ccb86ddc8f9f486aee25fb836f4aff97bf7679 |
|
23-Aug-2014 |
Winson Chung <winsonc@google.com> |
Multiple performance changes to speed recents invocation/app launching time. (Bug 16987565)
- Reverting changes to the existing thumbnail transition to prevent breaking applications
that currently depend on that transition. As a result, we need to create a new, hidden,
aspect-scaled thumbnail transition, and instead use that thumbnail to animate the
recents header so that we don't have to wait to do that inside the Recents activity.
In order for this to work, we also have to ensure that the thumbnail surface destruction
is synchronized with the application that is currently closing (when going down to
recents) or opening (when coming back up). The current thumbnail is destroyed when the
animation ends, but that can be at least 1 frame before the surface for the animating
window is destroyed. We change this by deferring destruction of this thumbnail window
to the animation that is being closed.
Especially on the way up, not having to wait for us to hide the header before doing the
transition up can save us the duration of that first animation (> 100ms).
- Other optimizations:
* No longer creating a new stack view on each transition to calculate the target rect
* Removing unnecessary call to get the thumbnail when transitioning up/down (the actual
window does its own animation.
* We reduced numerous system calls per task by adding a flag to ignore home-stack tasks
and caching the activity label and icon (and task description icon). These caches
follow the same eviction schemes as the thumbnail and icon cache.
- Also tweaked the touch slop for the nav bar swiping gesture to prevent conflicting with
tapping on home (Bug 17109581)
Change-Id: Ica697aad788051a9203edd9351c583e1cb038a71
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| d47ad033c35b2b69fc0be2073c682c30c855c124 |
|
15-Aug-2014 |
Adrian Roos <roosa@google.com> |
Fix bars jumping to black on activity launch
During animations, the wallpaper crop is the
union of the start and end crop. This prevents
the system bars from jumping to black when an
activity with opaque bars is launched.
Bug: 16441036
Change-Id: Ic0f3bc2e83b9830514a3456a27ae6f23716f3240
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 76a1623afc170a13923b68f3256057d8adeb7937 |
|
08-Aug-2014 |
Jorim Jaggi <jjaggi@google.com> |
Preparations for lockscreen launch animations
- Update unlock animations to new spec to make the consistent with
lockscreen launch animations.
- Introduce disappearing motion for security views which runs before
we actually dismiss Keyguard.
- If a window is running the un-force-hide animation, treat as it
would have the wallpaper flag set so the wallpaper stays until
the animation is completely done.
- Run an animation on the wallpaper if the wallpaper is going away.
Bug: 15991916
Bug: 16234603
Bug: 15326120
Change-Id: I063aa4f269ddcf75b9a705e90f0c3056b541b642
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| c2f20b66fd28c10e2ec8654bd74cb501eb7f837b |
|
08-Aug-2014 |
Amith Yamasani <yamasani@google.com> |
No need to send PRE_BOOT_COMPLETED for new users
Since the primary purpose is to upgrade databases, no need
to send this broadcast. If system apps care to be informed early
on new user creation, USER_INITIALIZE is an early broadcast.
Also remove some logs that spew when switching users.
Bug: 16846465
Change-Id: Ibd7f8630ce1f41f8cadbda616de05844b127d1a8
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 7699651ec4fb38efb868c075dfbe10ddc19a1d6a |
|
24-Jul-2014 |
Antoine Labour <piman@google.com> |
Merge "WindowManager: fix clipping" into lmp-dev
|
| 7db8687d579c47ca5e45f3c50d39f0b324d11c22 |
|
24-Jul-2014 |
Antoine Labour <piman@google.com> |
WindowManager: fix clipping
The animation code has some logic to avoid committing a new clip rect
when it hasn't changed. However, when we destroy the SurfaceControl and
recreate it later, we failed to reset the cached value, so if the clip
rect hasn't changed, we never set it on the new SurfaceControl.
This patch resets the cached value when creating the SurfaceControl.
Change-Id: I355576709834dd80994c7564330a234b182800e6
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| d2a1eec400128f39e1b223a720a88dbd395f3e6e |
|
09-Jul-2014 |
Sander Alewijnse <salewijnse@google.com> |
Add Device Policy API to disable screen capture.
WindowManager will set secure flag on SurfaceControl for
all windows of a flagged user to prevent screen capture.
API is consistent with the camera disable API.
Change-Id: Ib180f67f1ad827b6f4aca2af615274256cce58f4
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 4a0ffb004a62595b6aac598445908013ab9d9915 |
|
15-Jul-2014 |
Adrian Roos <roosa@google.com> |
Fix windows not showing when SHOW_WHEN_LOCKED changes
Removes WindowStateAnimator's copy of the window flags, which was
not updated when they changed.
Bug: 15574002
Change-Id: I1ca3f8d5b521727fcb8da14ff1f8231e47b1e9b9
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 49a22e82025ea947d81681a0abb7ef00600eac3b |
|
13-Jul-2014 |
Alan Viverette <alanv@google.com> |
Add window elevation for dialogs, clean up surface insets API
BUG: 13211941
Change-Id: I9d605d0b2fb24f9bf8e73fbecd520b6b52ae5751
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| ccb11e183763db5cbaca96abe461adf480ed8e44 |
|
09-Jul-2014 |
Alan Viverette <alanv@google.com> |
Add API for specifying popup window shadows and shadow insets
BUG: 14569120
BUG: 13211941
Change-Id: Ia21596b25a0471344d42d59377074f67fce00042
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| eb94fa7975b1e8742f3b00cec6bd4f9d6b329e3a |
|
04-Jun-2014 |
Dianne Hackborn <hackbod@google.com> |
Improvements to low power mode.
Add new public API for monitoring low power mode.
BatteryService now puts device in to low power mode when
battery level is low.
Window manager now watches low power mode to turn off
animations.
Modifying the animator scale now gets propagated to all
processes.
Change-Id: I8fa566994764ddd4e1977631e28381ab9409f8ee
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| e30e02f5d9a9141c9ee70c712d4f9d52c88ea969 |
|
28-May-2014 |
Dianne Hackborn <hackbod@google.com> |
Add system layer for voice interaction services.
New window layer that voice interaction service windows
go in to. Includes a new voice-specific content rectangle
that voice activities are placed in to.
Add specific animations for this layer, sliding down from
the top (though this can be customized by the voice interaction
service).
Also add the concept of activities running for voice interaction
services for purposes of adjusting the animation used for them,
again sliding from the top, but not (yet?) customizable by the
voice interaction service.
Change-Id: Ic9e0e8c843c2e2972d6abb4087dce0019326155d
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 3eeb4e6e40e2c23a0bcfe24937688bd437c15e2a |
|
19-May-2014 |
Adrian Roos <roosa@google.com> |
Fix cropping for fullscreen windows
Bug: 15046646
Change-Id: I526c0044e3715a4096373b8bbbdbd0c864be2df9
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| a79501cd3843149f0759bd53d310cf97d4ee1c8d |
|
27-Mar-2014 |
Craig Mautner <cmautner@google.com> |
am af89d7e2: am bffd4d43: Merge "Check return values for null." into klp-modular-dev
* commit 'af89d7e21f5d7cbe74ff4ce014d8ab2db1a6fc27':
Check return values for null.
|
| d3849f54158bf1a370b9462b30ee36c15e7b02ea |
|
27-Mar-2014 |
Craig Mautner <cmautner@google.com> |
Check return values for null.
When a Display has been removed there is a delay until all of its
windows have been removed. Therefore there is a possibility that
WindowState.getDisplayContent() returns null. Guard against that
possibility.
Fixes bug 13616765.
Change-Id: Ia2074d293b0e1bd4ca2cd14aeb4a2cc09ed9f41e
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 0bfae1063a9db09338dd87c3656445b439da5898 |
|
21-Mar-2014 |
Winson Chung <winsonc@google.com> |
Merge "Adding workaround for the status bar not reporting the correct system decor rect."
|
| 96d970c93e0ed639f0639a1ea17bb98acc703ff1 |
|
21-Mar-2014 |
Winson Chung <winsonc@google.com> |
Adding workaround for the status bar not reporting the correct system decor rect.
Change-Id: I2ea089e9d41deb2ac2a266694ac65d58830856f5
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 7bcdb33d859ffb70f235cc8e0f22a0598194ddf8 |
|
21-Mar-2014 |
Winson Chung <winsonc@google.com> |
Merge "Adding support for clipping window transition for alternate recents."
|
| 399f62052a88e5e7628b7312637ae54fbbaa4bec |
|
19-Mar-2014 |
Winson Chung <winsonc@google.com> |
Adding support for clipping window transition for alternate recents.
Change-Id: Ic7df4e6c0396afc794ffc21694814c0a93f20f31
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 8e3feb15c5aec2c72b0ef120a1da325e1e8f0dda |
|
24-Feb-2014 |
Svetoslav <svetoslavganov@google.com> |
Added accessibility APIs for introspecting interactive windows.
1. The old introspection model was allowing querying only the active window
which is the one the user is touching or the focused one if no window is
touched. This was limiting as auto completion drop downs were not inspectable,
there was not way to know when the IME toggles, non-focusable windows were
not inspectable if the user taps them as until a screen-reader starts
introspecting the users finger is up, accessibility focus was limited to
only one window and the user couldn't use gestures to visit the whole UI,
and other things I can't remember right now.
The new APIs allow getting all interactive windows, i.e. ones that a
sighted user can interact with. This prevents an accessibility service
from interacting with content a sighter user cannot. The list of windows
can be obtained from an accessibility service or the host window from an
accessibility node info. Introspecting windows obey the same rules for
introspecting node, i.e. the service has to declare this capability
in its manifest.
When some windows change accessibility services receive a new type
of event. Initially the types of windows is very limited. We provide
the bounds in screen, layer, and some other properties which are
enough for a client to determined the spacial and hierarchical
relationship of the windows.
2. Update the documentation in AccessibilityService for newer event types.
3. LongArray was not removing elements properly.
4. Composite accessibility node ids were not properly constructed as they
are composed of two ints, each taking 32 bits. However, the values for
undefined were -1 so composing a 64 long from -1, -1 prevents from getting
back these values when unpacking.
5. Some apps were generating inconsistent AccessibilityNodeInfo tree. Added
a check that enforces such trees to be well formed on dev builds.
6. Removed an necessary code for piping the touch exploration state to
the policy as it should just use the AccessibilityManager from context.
7. When view's visibility changed it was not firing an event to notify
clients it disappeared/appeared. Also ViewGroup was sending accessibility
events for changes if the view is included for accessibility but this is
wrong as there may be a service that want all nodes, hence events from them.
The accessibility manager service takes care of delivering events from
not important for accessibility nodes only to services that want such.
8. Several places were asking for prefetching of sibling but not predecessor
nodes which resulted in prefetching of unconnected subtrees.
9. The local AccessibilityManager implementation was relying on the backing
service being ready when it is created but it can be fetched from a context
before that. If that happens the local manager was in a broken state forever.
Now it is more robust and starts working properly once the backing service
is up. Several places were lacking locking.
bug:13331285
Change-Id: Ie51166d4875d5f3def8d29d77973da4b9251f5c8
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| edb67190d65659ff1da563f1d081d9429bd31a31 |
|
18-Mar-2014 |
Wonsik Kim <wonsik@google.com> |
Merge "Revert "VideoPlaneView initial implementation""
|
| 475e3f0e887cd23d3107acc06d29d440c60fbecf |
|
17-Mar-2014 |
Wonsik Kim <wonsik@google.com> |
Revert "VideoPlaneView initial implementation"
This reverts commit 5f8aa4142919b3001fd2621f7acd5f609a5129a5.
Change-Id: I161748f365512c5e24acba2c3d9ebd9405fa8e3f
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| a9499d704c1a196b1c0bf8317b71e4f7ddd3f75d |
|
27-Feb-2014 |
Wonsik Kim <wonsik@google.com> |
Merge "VideoPlaneView initial implementation"
|
| 5f8aa4142919b3001fd2621f7acd5f609a5129a5 |
|
18-Feb-2014 |
Wonsik Kim <wonsik@google.com> |
VideoPlaneView initial implementation
Note that eventually VideoPlaneView should not inherit from SurfaceView.
Remove a few trailing spaces too.
Change-Id: Ia0a461169d560435a827861be2cc15f1e3ee68fa
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 95da1087ed3c7b9983b571bc5409827ae390f15f |
|
25-Feb-2014 |
Craig Mautner <cmautner@google.com> |
Clean up activities and displays when done
More maintenance fixes.
Fix bug 13157352.
Change-Id: Ic86d39a84452a1cf1dc1762cec517b419ad0a852
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| c2c0a61cf5f779b4726f089f28d966c03ccbba54 |
|
21-Feb-2014 |
Craig Mautner <cmautner@google.com> |
Add copyright notice to files missing them.
Fixes bug 13121968.
Change-Id: Ifd86581178e7e98bd72b832020e7c8379d40b2de
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 71dd1b63436e9cdd5cbd2d42cd5841d497da8238 |
|
19-Feb-2014 |
Craig Mautner <cmautner@google.com> |
Set the new SurfaceControl opaque flag.
Converts surfaces from transparent to opaque and opaque to transparent
without creating a new surface. Uses the new SurfaceControl.setOpaque
method.
Fixes bug 12387406.
Change-Id: I669c064e622e211b00b1585183a488d5b3f4b778
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 9ef471f7f2f59de032d7cb9c3c7241486109979e |
|
07-Feb-2014 |
Craig Mautner <cmautner@google.com> |
Don't remove Activities and Tasks until animation done
Just like stacks and displays, activities and tasks need to stick
around until animations have completed.
Change-Id: I54fe8f6855d60cbc3a25cbc6e762defd5ac50bf5
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 1bf2b873470d2ba8a4ac218da73516cc2b20aa76 |
|
06-Feb-2014 |
Craig Mautner <cmautner@google.com> |
Defer detach until animations are complete.
Allowing the detach of ActivityStack from DisplayContent to happen
immediately was causing all sorts of problems associated with not
having a Display to complete the animations.
Waiting for animations to complete before either the detach or the
display removal fixes those problems.
Change-Id: I8a5663bfac5c3c1084ff4fcc451e0e38e8080265
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| df88d73092c62a1a3cd2b2056ca63ae2e70cc238 |
|
27-Jan-2014 |
Craig Mautner <cmautner@google.com> |
Add IIntentSender to ActivityContainer.startActivity
PendingIntents and IntentSenders can now be launched. Still does not
work once the host activity has been paused and resumed.
Window manager TaskStacks now exist independently of Displays and app
windows persist after Displays are removed below them. Attaching the
stack to a new Display does not yet restore the windows to it.
Fixes bug 12747909.
Change-Id: I509007ee23fda400b353f483cf6ecce08177763b
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|
| 9158825f9c41869689d6b1786d7c7aa8bdd524ce |
|
22-Nov-2013 |
Amith Yamasani <yamasani@google.com> |
Move some system services to separate directories
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
/frameworks/base/services/core/java/com/android/server/wm/WindowStateAnimator.java
|