51c23674ab6340d7a2f2be6b3ff515e7033e118a |
|
03-Apr-2015 |
Wale Ogunwale <ogunwale@google.com> |
[DO NOT MERGE] Fixed NPE when trying to animate a window without display In some cases it is possible for the AppToken.allAppWindows list to get out of sync with the list of windows known to WMS if the client doesn't call Session.remove(Window). This can lead to an NPE when the animation threads runs and the display for the window has been removed. Bug: 19972099 Change-Id: Ifdf9ff2364b96757bba0539394c4a682f64577c9
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
cb17f1895253dfccba85f2e35e6d51ff8050fa86 |
|
11-Dec-2014 |
Craig Mautner <cmautner@google.com> |
Don't apply animations to windows that are showing If a window is showing and not obscured by the keyguard, for example windows on other displays, don't apply the enter animation. This prevents jank on secondary displays when the keyguard is unlocked. Fixes bug 18689396 Change-Id: I2deb3030e6e887f57af9a5f1d42b1c71f06f7eeb
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
235607589c78d952b5210e27738df5bc37a63e38 |
|
13-Nov-2014 |
Jorim Jaggi <jjaggi@google.com> |
Always set correct policy visibility Windows without a surface didn't get the correct policy visibility applied after dismissing lockscreen. Thus, when launching something from lockscreen, home activity was hidden but never set to visible again. Before executing the transition to home, we didn't consider home as a wallpaper target because it was still invisible, and thus we picked the wrong transition. Always applying policy visibility when lockscreen changes fixes this outdated state. Bug: 18369599 Change-Id: I2933eaf0ab55fe31cb382c46c411033e33a756e0
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
1dfab89aff596a57f447fdcf44deadf266d501e9 |
|
12-Nov-2014 |
Wale Ogunwale <ogunwale@google.com> |
Fix build breakage from missing close brace. Change-Id: Ib0e58844b8b208d255ff8d9409d0e7c53f27378f
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
3ae0d3157d5fdeee851f3e72b80f4ed57add0ff8 |
|
07-Nov-2014 |
Wale Ogunwale <ogunwale@google.com> |
Fixed constant window switching on lock screen with Swype KB. We allow TYPE_INPUT_METHOD windows to show on the lock screen. These windows can attached other types of windows (For this case the Swype KB was attaching a PopupWinow which will be of TYPE_APPLICATION). This causes the popup window app token to be added to the list of apps to be hidden on the lock screen, thereby preventing the lock screen from been hidden, which then causes a layout cycle(s). Now, we remove app tokens for non-app windows from the hidden list in case it was added by any attached widow they migth have. Also, when we are updating window animations, set the hideWhenLocked flag for windows that are IME tragets so they don't go through unneeded cycles of having their visibility policy set to hide/show/hide/show/... Bug: 18021493 Change-Id: I3680256d41793f62def42fda00e26db1dcc990cc
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.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/WindowAnimator.java
|
c08eab81f30a3120ec0929d3508b4a78d498e1ff |
|
11-Nov-2014 |
Craig Mautner <cmautner@google.com> |
Show error dialogs over apps that dismiss keyguard Error dialogs absorb all input to ensure that they are not missed. This can cause the screen to lock up if they are not displayed but are still absorbing touches. This was what was happening when there was an error dialog up at the same time as a phone call came in as in b/17648830. This fix recognizes when an app is dismissing the keyguard and forces any error dialogs to be shown over such an app. This also removes the private flags from the input system as they are no longer needed. Fixes bug 17648830. Change-Id: I5c98b8265a1448b445fdb2f745fc78892f8656a4
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.java
|
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/WindowAnimator.java
|
44eb8b772984164666195ea71c685292b234549a |
|
05-Nov-2014 |
Alan Viverette <alanv@google.com> |
Revert "When keyguard exits use same anim for all windows" Broke window animations. This reverts commit b83408018176ec58f50e792590a22fdc9eb87fff. BUG: 18248641 Change-Id: Ic456a5666c3199e8bb8c9c2fb1ecdbb82afaad86
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
b83408018176ec58f50e792590a22fdc9eb87fff |
|
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: I9949ef0a1639c831754316da34de97cb86403f5a
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
c0d2d0ad6ddcd23b7bbe6b1a5668d6d719e4c86c |
|
01-Nov-2014 |
Craig Mautner <cmautner@google.com> |
Animate starting windows when keyguard dismissed. Starting windows are displayed prior to their app windows visibility being set. Consequently the WindowToken.hidden boolean for starting windows is still true even when it is shown. The keyguard logic uses the method WindowState.isVisibleNow to determine whether to animate each window. This method incorrectly determined that starting windows were not visible based on WindowToken.hidden and consequently didn't animate in the starting window. This change fixes isVisibleNow() to correctly determine when starting windows are visible and animates them in as part of the keyguard transition. This change also adds keyguard debug. Partially fixes bug 15991916. Change-Id: Iac3e5f3f33876be5801ec619bbe7a1579e648322
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
8d05172112436a81bed6e4a0810f8914509d8a4d |
|
01-Oct-2014 |
Dianne Hackborn <hackbod@google.com> |
More work on issue #17656716: Unhandled exception in Window Manager Fix Slog.wtf to not acquire the activity manager lock in its code path, so that it can never deadlock. This was the original intention of it, but part was missed. Now we can put back in the code to detect when strict mode data is getting large (a little more targeted now to the actual problem), and use Slog.wtf to report it. And as a bonus, when this happens we will now clear all of the collected violations, to avoid getting in to the bad case where IPCs start failing. So this should be good enough for L to fix the problem, with wtf reports for us to see if the underlying issue is still happening. Finally, switch a butch of stuff in the system process from Log.wtf to Slog.wtf, since many of those are deadlocks waiting to happen. Oh and fix a crash in the settings provider I noticed in APR. Change-Id: I307d51b7a4db238fd1e5fe2f3f9bf1b9c6f1c041
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
20d97e1ce20a4db23fb1b9799f29744878ecee22 |
|
12-Sep-2014 |
Craig Mautner <cmautner@google.com> |
Merge "Add null checks to WindowState.getStack() calls." into lmp-dev
|
cbc771f50e998ec307c7e92009425c730cde49c5 |
|
12-Sep-2014 |
Craig Mautner <cmautner@google.com> |
Merge changes Ia6fe9724,I682b9acb into lmp-dev * changes: Show all windows from activity that hides keyguard Make sure FLAG_DISMISS_KEYGUARD brings up bouncer
|
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/WindowAnimator.java
|
7d7808fcf8e6a1c27d52375210f9da2705d5f590 |
|
12-Sep-2014 |
Craig Mautner <cmautner@google.com> |
Show all windows from activity that hides keyguard Popup windows from the activity hiding the keyguard weren't being shown. This change retrieves that activity from PhoneWindowManager and applies the show or hide call to the windows that match the activity. Fixes bug 16479813. Change-Id: Ia6fe97240aec85c5233eee9038138f7d48095a6e
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
b180d7707ffc2671caf494f2110b8942cedb5521 |
|
11-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Windows for accessibility with wrong coords on rotation. We were handling rotation changes for accessiblity in the window manager too early, before the rotation animation completes. This lead to wrong window positions being reported to the accessibility layer. Now we handle rotation for accessibility when the rotation changes, if we will not animate, or after the rotation animation completes. bug:17457240 Change-Id: Ia772f4886bfdbe0f9bc9003c12f36b2fbd6f45ec
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
99b69286f1e22575aa4807d63f01662477baedd5 |
|
27-Aug-2014 |
Craig Mautner <cmautner@google.com> |
Show IME over keyguard if IME target is showing IME was being hidden by keyguard even if the window it was attached to was showing. This change shows the IME if the window it is attached to is hiding the keyguard. Also fix an NPE that was crashing systemui. Fixes bug 16457525. Change-Id: If587eefa7b1e0ae26713906a76c0766ebaae69a6
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
84a3e7aacf6dbeccf4afb36a29f2f069dca7d486 |
|
13-Aug-2014 |
Jorim Jaggi <jjaggi@google.com> |
Use different unlock animation when going to full shade Also fixes a bug that the notify flag was not reset, and fix the transition for the phone/camera affordance (in these cases, no animation is needed). Bug: 15991916 Change-Id: Idbb4fa40f86bda597cd66cc38da838ef4f75514d
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.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/WindowAnimator.java
|
53c68a44acbd9343dda648c17652e921c28fda1d |
|
18-Jun-2014 |
Jorim Jaggi <jjaggi@google.com> |
Fix bug when Keyguard gets hidden. We make sure in Keyguard that we only hide ourselves in startKeyguardExitAnimation ourselves when we requested a hide. In addition, this change also fixes a bug in WindowAnimator that it should only call startKeyguardExitAnimation when Keyguard actually requested a hide. Bug: 15676717 Change-Id: I2279cccb9916985b7e9a2f41137878be5782cb9c
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
c9457faeb6bf22ce8fc72bc61af5109a2b567c51 |
|
06-Jun-2014 |
Craig Mautner <cmautner@google.com> |
Do not display unsecure windows behind dialogs If a dialog activity has FLAG_SHOW_WHEN_LOCKED set it will dismiss the keyguard. Previously this would expose any full screen unsecure windows behind the dialog. With this fix the dialog is displayed over the wallpaper. Fixes bug 15006623. Change-Id: I85a6713c7647db52211bd0f7280010e859723710
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
e29b2dbc762bfa66093d76f5a65f55328d8753c9 |
|
30-May-2014 |
Jorim Jaggi <jjaggi@google.com> |
Fade scrim in unlock animation. This also introduces a startTime which gets sent from window manager to SystemUI, which tells when the animation should start, to allow for a more synchronized animation with fading out the scrim and fading in the activity behind. Bug: 15163546 Change-Id: I16212b1ef9eb76f1f98734da1d14fc5b7e626937
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
0d674623facfbd3e9c520d2be4ed98977b92a1a2 |
|
21-May-2014 |
Jorim Jaggi <jjaggi@google.com> |
Add methods to coordinate unlock animation. Introduce IWindowManager.keyguardGoingAway to notify that Keyguard wants to dismiss it self. This method starts the state machine in WindowAnimator which animates in the activity behind the keyguard. Animating out the keyguard is done by the StatusBar/Keyguard software when it receives the startKeyguardExitAnimation() callback. Bug: 14118756 Change-Id: Id3b8f41189410bad808b4892fbec74245e59efce
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.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/WindowAnimator.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/WindowAnimator.java
|
dc548483ae90ba26ad9e2e2cb79f4673140edb49 |
|
05-Feb-2014 |
Craig Mautner <cmautner@google.com> |
Move activities from DisplayContent to TaskStack Now that activities and tasks can be detached from a display do not keep their state within the DisplayContent class. All such state is now moved to the TaskStack class with this change. Change-Id: Ie6b1811e9ec3f545782bad8c3461bd4f2d336b93
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.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/WindowAnimator.java
|