| 8e4bda9e0f7411a3bfad0c625177f67248ff8a12 |
|
05-May-2016 |
Chong Zhang <chz@google.com> |
Fix a flicker when window is removed during entering animation
When animation is started with saved surfaces, app may decide to
remove one of the child windows during early animation and replace
it with a new window. This causes the app below (usually Recents)
to show through for one or more frames.
If we started animation early with a window, delay removal of
that window until the app is allDrawn in the "traditional sense"
(i.e. allDrawn without using any saved surfaces).
bug: 28742353
Change-Id: I4ef663a947b737aae96c3ccfe13a9f4c1d0567f0
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| 3b6e05a2a8365c7e9c21e151ff05ca046b5bb9d9 |
|
21-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Revert "Death to synchronous transactions (2/2)"
This reverts commit dd05f0365aa0df9ba9a7631c8e02ed67f472132d.
There seems to be some logic that gets triggered inside surface flinger
regarding commit time of the transaction, and without it seems that
animations got jankier. No time to investigate...
Bug: 28305789
Change-Id: I7261cf8719d3528f8f5bee19e507b8ba88b8b729
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| dd05f0365aa0df9ba9a7631c8e02ed67f472132d |
|
08-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Death to synchronous transactions (2/2)
Bug: 28068298
Change-Id: I7d2d7aba8c16aa5e0b9c288bc747ed62f9292381
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.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/WindowAnimator.java
|
| 3dac63a18d9115405404561d327010604420b07b |
|
01-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Don't destroy thumbnails immediately
The hiding of the thumbnails needs to be synchronized with the hiding
of the app window. Because destroying them immediately destroys them
without being part of the transaction, that can happen earlier than
hiding the surface.
Instead, hide the thumbnail in the transaction first and then put it
into a list to be cleared after the transaction is closed.
Bug: 27275815
Change-Id: I1530262c26c0751e53d218b686c46129f7c7df1d
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| 02b74b9420f0b4adbec6997b950e244ad0dff56c |
|
20-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix leaking animation
Clear animation when destroying window surface.
Because we are not stepping in animations for windows if they don't
have a surface, we can't use it as a detached wallpaper target
animation.
When the surface was destroyed while animating,
winAnimator.mAnimating was still true, and never got false, because
we didn't call stepAnimation on the WindowAnimator anymore.
Thus, we were constantly animating, using a lot of battery (surface
flinger was constantly pushing frames) and impacting overall system
performance.
Bug: 27276043
Change-Id: I8b0943da0908c85740dc1113aedb573fb440f162
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| 42625d1bc7ef99c4d4435e8cdebfe3eee57b8d97 |
|
12-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
New behavior for docked stack when going home
- We keep the docked stack visible when home task is visible even
though it's not resizable.
- We introduce the a new concept called "minimizing" the docked stack,
which happens when going home. In this state, the docked stack is
clipped of almost completely.
- To achieve that, we introduce TaskStackBoundsAdjustController,
which adjusts the bounds of the docked stack when minimized. Also,
migrate the IME handling to this new class.
- We also need to inform SysUI that it is now minimized so it can
remove the drag affordance on the divider, and also make it a bit
smaller.
- When we detect an app transition, we check whether the home stack
gets visible/invisible. We then start an animation which runs in
sync with the normal app transition. For that we introduce
DockedStackDividerController.animate(), which performs the animation.
Bug: 27137961
Change-Id: I8623bc73cc6872bf28c5b1b8d5795974576811b2
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| 7998e48ce3240d09f28cd365fb6ba58f8987470f |
|
13-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix unlock transition when docked stack is visible
- Keep surface of docked divider when lockscreen is showing, like
all other apps, so we don't run into synchronization issues when
unlocking. We do this by setting policy visibily to false, but
keep clientVisibility=true
- Update docked stack visibility when starting unlock sequence to
visible.
Bug: 27154882
Change-Id: I6def5c18831e23579fcfc904133749f149eaf376
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.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/WindowAnimator.java
|
| e6fd77baf47f874ad7120746775a15a54bff05b0 |
|
17-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Use correct SparseArray access method when iterating over it.
The current code works with a single display, because that display will
have id 0, so the old code will work (get(0) will return that display).
Bug: 26089885
Change-Id: If685c0ff006f353e6d56fd144acbce4d7f1e835b
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| 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/WindowAnimator.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/WindowAnimator.java
|
| 95094d17cbd8d4e808c3f63341f3c8c92ee8e75f |
|
24-Nov-2015 |
Chong Zhang <chz@google.com> |
Show all windows with FLAG_SHOW_WHEN_LOCKED over lock screen if
we're already showing some app over the lock screen.
bug: 25685940
Change-Id: Ib7869f58e2903199470a95dfb796d063bc8d0c51
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| 8b6f38c7c7dee7d0a543bfdb4cfd936b3fd42c07 |
|
20-Nov-2015 |
Vladislav Kaznacheev <kaznacheev@google.com> |
'Drag and drop failed' animation
If the drop has not been consumed (DragState.mDragResult is false)
the drag shadow surface is not immediately destroyed, but animated
back into the position where the drag started.
The current animation is an OK placeholder, still waiting for the
final word from UX.
Bug: 24415573
Change-Id: Ia30135ce1e85655c8ba16e28dc69f0ebf9b36239
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.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/WindowAnimator.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/WindowAnimator.java
|
| d9cabc50d1863973a169d02880b22c0c4eef9ba7 |
|
27-Oct-2015 |
Jorim Jaggi <jjaggi@google.com> |
Add traces when windows are animating
Change-Id: If52f72c27c88060f7a0e2ff53adb1579bf181f59
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.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/WindowAnimator.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/WindowAnimator.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/WindowAnimator.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/WindowAnimator.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/WindowAnimator.java
|
| 61b47bb267dec696e1bb11f7c5eb6b9d2f4bd096 |
|
28-Jul-2015 |
Stefan Kuhne <skuhne@google.com> |
Adding the 'non client decor view' to free floating windows
This patch adds a new free floating window non client decor view which
has:
- Two buttons (maximize and close) as it meets our current UX design
- A Shadow which changes size with focus
- It's own view as preparation for the thread distributed drawing and
user interaction handling (resize handles, etc)
Missing is at this point:
- The button functionality itself.
- Changing/removing decors based on window type (once the needed
patches land.
bug: 21738666
bug: 21739152
Change-Id: I6e41f2a7470256cee7bae35029d7e8c43fb235dd
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.java
|
| 4cd7216967a3e6211785c8acdeca449d61d796a0 |
|
20-Jul-2015 |
Jorim Jaggi <jjaggi@google.com> |
Fix window animation flickering
Bug: 22502673
Change-Id: I939e5840e10f3c0582148a5a01908076f994ae69
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| 4474f54f4eedbdf5d0b225647d50c0b05466a448 |
|
10-Jul-2015 |
Jorim Jaggi <jjaggi@google.com> |
Fix empty keyguard for once and all
When a Keyguard exit animation was played while the screen was
turning off, the window animation was cancelled. However, since
we didn't reset mPostKeyguardExitAnimation, we thought we need to
apply it again, with a start time of Long.MIN_VALUE. For some reason,
this animation never ended, and it was stuck at the beginning. Thus,
the alpha was 0 and the user just saw a blank wallpaper.
In addition, we also forbid starting the Keyguard exit animation when
the screen is about to turn off.
Bug: 21124013
Change-Id: Ief022c5bd758a9fedcaab3fe9fc385fa4234b37f
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| 38586bfff9b8194c86f1363d63e971bbbc6ee843 |
|
08-Jul-2015 |
Adrian Roos <roosa@google.com> |
Merge "Fix bug that prevented waking from dream" into mnc-dev
|
| bee63000ede8ddd9ebd2fcd098569aca87a3596c |
|
07-Jul-2015 |
Adrian Roos <roosa@google.com> |
Fix bug that prevented waking from dream
If a device was securely locked, FLAG_TURN_SCREEN_ON failed to
wake the device from dreaming even if FLAG_SHOW_WHEN_LOCKED
was set. The fix allows SHOW_WHEN_LOCKED activities that are about
to turn the screen on to show even if they're not currently the top
most window with SHOW_WHEN_LOCKED set (which in this case would always
be the dream)
Bug: 21719374
Change-Id: I8d7bce05d95ed9de50b5a52b0973562b070aca5a
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.java
|
| cb26db087839289394897180916b86717ab42813 |
|
26-Jun-2015 |
Jorim Jaggi <jjaggi@google.com> |
Don't apply existing keyguard animation to IME window
Low risk fix, but it remains unclear what the underlying cause is.
This also applies keyguard exit animation to windows on the default
display.
Bug: 21788383
Bug: 22096813
Change-Id: I37dd4b18483c1103f5f2817f4879f080a38bceca
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| 8972c2a0c7ec0f8a25005c2eaab31345a2abc323 |
|
06-Jun-2015 |
Jorim Jaggi <jjaggi@google.com> |
Fix lockscreen launch animations
- Fix the case in WindowAnimator where the real window was ready
to draw while the starting window was playing the unlock animation.
- Always delay Keyguard done when clicking on a notification. Some
notifications started services/broadcasts instead and thus we didn't
wait, making it a jarring transition. In case the notification click
doesn't result in an activity start at all, we still have the timeout
that saves us from freezing (3s), but most notifications should start
an activity.
Bug: 19412725
Change-Id: I78f6839f59986f8f7ecdff70227d5690a504f475
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| 7a542b66e0b27e3202d37989983bb9c71a07455e |
|
08-Jun-2015 |
keunyoung <keunyoung@google.com> |
apply force hiding of window only when it is main display
- force hiding window for non-main display leads into stopping
rendering of windows in non-main display.
- change the logic to skip force hiding if it is not main display.
bug: 21665476
Change-Id: I2e23f3a2d6e3cbf6819ade1798360efe2986e80e
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| 461829d607b32ee492b6123043ae4232ed82ae93 |
|
03-Jun-2015 |
Adrian Roos <roosa@google.com> |
Prevent windows below the keyguard from showing
Fixes a bug where windows below the lock screen
could become visible if a SHOW_WHEN_LOCKED activity
hides the status bar.
Bug: 21450145
Change-Id: Ie660394cb96d7e6839bd4fb7c2729133bac2dfc5
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.java
|
| 602c68e4ffa1d17b2032c0e05c5d4d4dc8795adf |
|
25-Apr-2015 |
Adrian Roos <roosa@google.com> |
Smooth transitions between SHOW_WHEN_LOCKED activities
Bug: 12536117
Change-Id: Ia5f96e49587661440ae31fba17c42b2e3a9557fb
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| f16a281066ed7b524676698f95642c0a550b0b62 |
|
01-Apr-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed NPE when trying to animate a windows whose display is gone.
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.
Also corrected some method names/scopes I ran across while debugging.
Bug: 19972099
Change-Id: Ib0ae7ede6c506f833bbdd66723b88e7504a61907
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.java
|
| 08c7116ab9cd04ad6dd3c04aa1017237e7f409ac |
|
28-Feb-2015 |
John Spurlock <jspurlock@google.com> |
Remove unused imports in frameworks/base.
Change-Id: I031443de83f93eb57a98863001826671b18f3b17
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.java
|
| 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/WindowAnimator.java
|
| e7cfceb58df4046162004bae2152de1f216329da |
|
05-Feb-2015 |
Craig Mautner <cmautner@google.com> |
Code cleanup.
Change-Id: Ie12fea5db28633a95fec440eb7a8c5a5a8c45a1b
/frameworks/base/services/core/java/com/android/server/wm/WindowAnimator.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/WindowAnimator.java
|
| 10c9c6681554ab7ae0a322c95ba99574d6917962 |
|
12-Dec-2014 |
Craig Mautner <cmautner@google.com> |
am 2d6627a9: am 72b047c6: Merge "Don\'t apply animations to windows that are showing" into lmp-mr1-dev automerge: 922f8e2
* commit '2d6627a9f28c5c31fec5da3dcf48d96ff7a0d893':
Don't apply animations to windows that are showing
|
| 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
|
| 6d354163cae182edea80b9d28471749b5e882180 |
|
20-Nov-2014 |
Riley Andrews <riandrews@google.com> |
[wip] Make the window animator rely on frameTime.
The window animator is looking at cpu time difference
whilst updating animations. Using the choreographer display frame
time will be a much more consistent way of estimating
the time between frames for animation.
Change-Id: If5c4034c6e1b017749d6f4ca727d564805672c39
/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
|