| 031384556ede1678e9c7f5bff21a6b9eefb3502f |
|
18-May-2016 |
Robert Carr <racarr@google.com> |
Never set resized while not drag resizing for pinned stack.
It's not necessary in the pinned stack and interferes with the
animation. It's not enough to just check getBoundsAnimating, as
we turn that off prior to the final resize so that we unmute
notifications to the client.
Bug: 28559097
Change-Id: Iae180c8a8ca0585184efcf24e7677557a33678eb
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.java
|
| 26c8c42bbb2b998e609983886fad5968f033268d |
|
10-May-2016 |
Jorim Jaggi <jjaggi@google.com> |
Also freeze configuration when freezing bounds
We also need to freeze the override configuration so we don't report
the new configuration too early, which leads to bugs.
Bug: 27915587
Change-Id: Idffadbb02ab0311796caa760ae1f467fd2d17768
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 29bfbb878d54db14204e9b02dc17bfc6e127b6b2 |
|
13-May-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed some issues with fullscreen dimming
- Always dim home stack and task fullscreen. The home stack could be
in split-screen mode, but we still want to dim dialogs that are
associated with the stack or task in fullscreen. The dialogs are not
really activities, but they are associated with the home stack for
things like dimming. Don't ask me why...
- Update the fullscreen dim layer bounds anytime the dim layer is
adjusted so we always have up-to-date bounds after rotation.
Bug: 28575624
Change-Id: I805c771153a2d25fb199bd9987bbf78a5967f6b9
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 5117e273eca0b15ef057d0c2440546799c17edf4 |
|
03-May-2016 |
Chong Zhang <chz@google.com> |
Apply IME adjust to newly added window
bug: 28390108
Change-Id: I72132d68cb41056fb69f2fe38fa13f2b3c9ce3d6
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| e42d0e102dbdf5287703389183a69019b64fc35e |
|
03-May-2016 |
Wale Ogunwale <ogunwale@google.com> |
Don't remove all app token windows when window client dies
AppWindowToken can contain windows from multiple clients (Processes)
If one of the client dies we shouldn't remove all windows in the app
token. We should only remove dea windows.
Bug: 28467642
Change-Id: I8be6a98e0acc79719158567114f4902066069c1b
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| af558e1419aba5b89b9ee8c2fdafa508e6de8d84 |
|
28-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix issues with docked stack not un-minimizing
- Add minimize state to dump
- If the docked app goes through a configuration change while the
docked stack is minimizing, the window list becomes temporarily empty,
and thus Task.isVisibleForCurrentUserLocked == false. Since we already
check at the beginning of the animation, we need to finish the minimize
animation on the docked stack no matter what happens.
- Adjust the condition when to notify divider controller about app
visibility. It turns out that under some conditions an animation is set,
but the app is not an element of mClosingApps nor mOpeningApps, so we
missed the visibility change of the home task
- Use getTopAppToken instead of getTopVisibleAppToken. When the token is
about to hide, it's already hiddenRequested, so we skipped changing the
minimize adjustment.
Change-Id: Ib9e2e3f6a5da7b7854b49857299a236e47baa6fc
Fixes: 28184044
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 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/Task.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/Task.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/Task.java
|
| 2c17cd254ba334462265c7b55938a7531545b2d3 |
|
09-Apr-2016 |
Robert Carr <racarr@google.com> |
Only set mResizedWhileNotDragResizing for base windows.
Dialogs, etc, may appear to not be drag resizing as they are not base
windows. Still though, when they resize we don't want them to enter
in to this mResizedWhileNotDragResizing mode or we will freeze
surface boundary updates and lose the ability to crop them to the stack.
Bug: 26668339
Change-Id: Id603816cf5f33b281f46c7812779ba29a024f34f
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| a86a6bf73e8f6e58590c1b53972cd2d1cc7c137f |
|
09-Apr-2016 |
Robert Carr <racarr@google.com> |
Fix Task dim with docked resize.
When are are docked resizing, just fake
the task bounds as the stack bounds for the purposes
of DimLayers, even if we don't want to relayout the
application interactively we want the DimLayer to keep
up with the divider.
Bug: 28154322
Change-Id: I86e41324cf384f2dceea15cd5e8ddd753dc5bfbd
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.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/Task.java
|
| f4fa8cb79bc9102d4bb6d18698fd01dc038d9b81 |
|
02-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix flicker when unlocking
When the device was locked the fullscreen stack was laid out
fulllscreen, even though the configuration was half-screen, which
lead to a race between the app drawing and the unlock animation
so sometimes you could see the fullscreen frame when the unlock
animation started.
Instead, only layout in fullscreen if the docked stack is fully
"hidden".
Bug: 27154882
Change-Id: I4ba0c396eb0312c2bf2d911903b68c88d28aae8c
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 22a869f51b93242d001ffb4c5d4ab3c8ed0b5a16 |
|
26-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Intersect task with stack bounds for dimming
Bug: 27240436
Change-Id: I9aba4a476d81b219e4d361d606a4339b0ebc5395
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.java
|
| 192086eb8aff3fb873a7e03ade0b81652aacf25f |
|
11-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Implement transition for docking task in recents #1
- When the docking transition is happening, defer updating
the bounds of the home stack until the transition is done.
This is to preserve the scrim which is drawn in the recents
activity.
- Use the PROLONG_AT_START infrastructure to hide the task
in recents when starting the app transition.
- When recents finally get resized at the end of the transition,
reset it's draw state so we don't move the old surface around,
and the new surface gets drawn at the new position, to avoid
flickering.
- Remove hack around not layouting docked divider if it's not
visible, it's not needed anymore and resulted in a wrong
initial position.
- Fix animation selection for docked stack divider.
- Make sure win.moved() always gets called.
Bug: 27607141
Change-Id: I76c35f09461f044a90e2c88335008284b5839cc0
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 2adba07d75419462873dfeef40d4c983d832ed99 |
|
03-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Show a scrim activity if task is not resizable
Add a callback to TaskStackChangeListener which gets fired when the system
might need to inform the user that a specific app might not work in
multi-window.
Use that callback in SysUI to show a translucent activity which scrims the
activity behind to inform that it might not be resizable.
Debounce the information to once per multi-window session, to not make it
annoying.
Introduce launchTaskId to start an activity in an existing task, and protect
that with START_TASKS_FROM_RECENTS permission.
Bug: 27327287
Bug: 27431869
Change-Id: I89e8d653872ab01ba3c1e252b426e5481da0e6ca
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| e627558feffa4ffe6435d7d13eda3d89f7c08095 |
|
01-Mar-2016 |
Robert Carr <racarr@google.com> |
Fix pinned stack frame computation.
We want to compute the frames for pinned like we do for freeform
as we are not constraining layout to the suggested display area by the
PhoneWindowManager. Also update applyGravityAndUpdateFrame
to not clip frames to the display for child windows. In the case
of computeFrameLw this would not be a problem as we would then
go on to overwrite mFrame anyway, but in the case of repositionChild
it could create issues (where we have applyGravityAndUpdateframe without
compute frame).
Bug: 26454664
Change-Id: I6fd4c9f37060d51003d041566368edd2b9eb7afd
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 51605275957dd936f9ad379d6d525d5e995ebe08 |
|
25-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Show toast if app was forced to be resizable
Bug: 27327287
Change-Id: Iaf33f0ba27a6bfb240068b9cf21732b0870f4429
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.java
|
| 8fa4522b24065d15535e17eed7cd5370b878a4c5 |
|
20-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Recents transition fixes
- Make sure to destroy the saved surfaces while we resize a task. The
usual destroying mechanism doesn't work here because we don't add the
windows to WMS.mResizingWindows.
- Make sure not to save the surface when a resize happened after the
window has been marked as gone (exiting). In this case, we resize the
task, so we add the window to mResizingWindows, but then when we don't
layout the window because win.isGoneForLayout() == true, so it would
save a surface that has the wrong size.
- Ensure the configuration of the top task when dismissing the docked
stack. First, this speeds up when the user navigates to it in the
fullscreen stack. Second, it fixes some other weirdness with saving
surfaces.
- Only exclude windows from layout when hidden is requested, so when
transitioning from hidden -> shown, the app immediately gets the
updated size when the task was resized when the window was hidden.
Bug: 27276087
Change-Id: I6faf016724136d984b259d184af58d41684f3425
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.java
|
| c662d8e94620c84b2fa57bfd6e45690f0c349d89 |
|
06-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Make sure we call reportResized exactly once when drag starting
If there was another layout happening before the app called
relayoutWindow(), we were issuing multiple reportResized calls,
leading to multiple relayoutWindow() calls, slowing everything
down.
Change-Id: I1f3da04bb7581c655567e1d1a6fe0f8c83c0ffda
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| ce14452a27acf0492d799ec88c619add3a630a88 |
|
06-Feb-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed issue with drag resize state when animating pinned stack.
When animating the pinned stack, we set drag resizing on the top
most task in the stack. This has a couple of issues.
- Only the top most task is put in drag sizing mode and all other
task in the stack will not be in resizing mode.
- The top most task of the stack can change during the animation,
so we fail to clear the drag resize flag on the previous top task.
We now track drag sizing at the stack level and have the stack
drag resizing state affect its tasks drag resizing states.
Also added concept of continuing a bounds animation if the same
target called BoundsAnimationController.animateBounds before the
current animation is done. We don't send onAnimationEnd() for the
current animation that is been cancelled and don't send
onAnimationStarted() for the animation that will be replacing it.
Bug: 25672053
Change-Id: I64e89ed09d81e4802dacebc5818dfa1deb0d588f
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 69abc194f32b5c955ac7beaf6db37269d596172d |
|
05-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Multi-window optimizations #1
- When the window doesn't have a surface, do not add it to
mResizingWindows, so we don't report unnecessary resizes
- computeDragResizing => false when window is not visible, so we
never enter resizing mode even if the window decides to relayout
in the background
Change-Id: I8e6cdef86f1579d128973d4f2f12e87bf9b65524
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 067e817585524aeb0fb2c5ff4444c21fadc3f0d3 |
|
04-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Only treat "null" bounds as fullscreen
When long pressing on the recents button, we made it one pixel smaller
than fullscreen so we don't dismiss the stack immediately again.
However, this is a huge hack, and lead to problems with navigation bar
background because there we actually rely on the fact whether
the window is fullscreen or not to determine whether to draw the
navigation bar background, which lead to flickering.
Bug: 26777526
Change-Id: Ifdfcf3ad4138bc88c5164177cd20f1ff1635085f
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| c6c89a82144f59475242c75d67529fed943ae30b |
|
29-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix transition to recents in docked mode
Transition for non-compatible apps will be handled in a separate CL.
Change-Id: I9c474f7aa394e4f3eacd1845c78bee5874bd8a59
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| b9b16a74e5543b7b707e55a7382bbe82d300e2e5 |
|
27-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Display warning toast when we try to launch unresizeable app in split-screen
Bug: 26774816
Change-Id: Ia85d9d89758041661391018f04feb6f8db4e56d9
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.java
|
| ccb6ce2dcd8b833692f6c8a4a568fb938acfe058 |
|
15-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fix split-screen visible apps issue when screen is rotated on lockscreen
When the keyguard is showing we say the docked stack is invisible so that
any activity that displays on top of the keyguard isn't cropped by the
docked stack. However this causes issues when the docked stack is resized
due to orientation change while the keyguard is showing.
We now ignore the visibility state of the docked stack when trying to get
bounds information for resizing while the keyguard is showing.
Bug: 25970565
Change-Id: I7479a1d0afed3b2edfb17848c56c5c3902b3709e
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| e1fe4d1e12b2524807ed29990b11268a03de54d7 |
|
14-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed bug with wrong task bounds when device is rotated 180°
When the device rotation changes we were rotating the task bounds
for tasks whose bounds shouldn't change independently from its
stack. This can cause the task and it windows to not show on screen
since they can end up outside the stack crop.
We now let the stack take care of the rotation for tasks that shouldn't
be resized independently of their stack.
Bug: 25970565
Change-Id: I82b78fbe233b57a4fd5df967f109eb532e0579d5
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.java
|
| 2a88fc31cf16b419fdd23c9841ffdbfe7af9d966 |
|
12-Jan-2016 |
Chong Zhang <chz@google.com> |
Apply scroll to windows added to a non-resizeble task that's docked
bug: 26447921
Change-Id: I933e277137fb127a9e961035cf48cba2bef52042
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 5e7409cf6a99da3e6ad792adf949b8963018647f |
|
11-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed NPE in Task#isResizeableByDockedStack
It is possible for the DisplayContent to be null.
Change-Id: I0a85038ae71a24fb5613237d771bc9222dd61cde
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 495f1381817ab53040916f4630e5afe981987675 |
|
08-Jan-2016 |
Chong Zhang <chz@google.com> |
Merge "Remove dead window if its activity record is cleared from history"
|
| 7e8eeb79abe1a4b39b2f086aacefa48928307cb2 |
|
07-Jan-2016 |
Chong Zhang <chz@google.com> |
Remove dead window if its activity record is cleared from history
We keep the dead window if its activity record is kept. However, if
the activity doesn't have any saved state, the record will be removed
too, in that case we have to remove that window.
And add a "apps" option in window dump to retrieve all app windows
regardless of the visible states. We need this to get the windows
that's waiting for replacements.
bug: 26324082
Change-Id: I7179354fe85553a5436b26371d3ad7295a452ce3
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| b429e6826d394a63f81d1702efd714d640ddfb49 |
|
06-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Improved output for 'dumpsys window displays'
New format makes it easier to parse during CTS testing.
Bug: 19225708
Change-Id: Ia9a75ca92b6c10eefcb07cabea9852e514807b08
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 0429f3522bca5bb86378dd3f013f995484ddbed6 |
|
22-Dec-2015 |
Jorim Jaggi <jjaggi@google.com> |
Freeze task bounds when relaunching
To make sure that task is only laid out with the size
that matches the current configuration, we have to "freeze"
the task bounds when we send a configuration change. Without this
change, it could happen that the app already laid out with the new
task bounds, but still had the old configuration, leading to
wrong layouts.
Bug: 26311778
Bug: 25015474
Change-Id: I8d3a3fdf3735f446a4affbbdb4986dafc97623a5
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.java
|
| bd0d937303ae54d8a5bb5f08080c4164302daefc |
|
29-Dec-2015 |
Chong Zhang <chz@google.com> |
Notify client when the window is moved because of a resize
We need to notify the client that the window has moved if a resize
results in a move without size change. This makes sure that relevent
info on client side (such as mAttachInfo.mWindowLeft/Top) gets updated
to the new frame. Things like View.getLocationOnScreen() may depend
on these to function.
Bug: 25565385
Change-Id: I5b9ded0b16243c14494f9a69257d56570ee8996d
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.java
|
| 48a87a542684bcfd4d5356c7489f9f5f37510c71 |
|
04-Dec-2015 |
Chong Zhang <chz@google.com> |
Fix window disappearing when docking a second app
When moving app1 to docked stack, the app2 is resized while in background
(fullscreen stack). Because of the config change, mWillReplaceWindow is
marked true. But since the app2 is in GONE state, all updates of mFrame
are skipped. When it's made visible again, because mWillReplaceWindow is
set, update of mFrame in computeFrameLw() is still skipped, resulting in
wrong mFrame being used.
The fix here is to not set mWillReplaceWindow if the app is not visible,
as we don't need to preserve old window.
Also fix position change check.
bug: 25937471
Change-Id: Iea506296ebd5c2a108368fb2d1d77cdc31a36cdc
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 6449a9567ac204e0c9be71a7f983a753d8061220 |
|
02-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Add bounds information to stack/task WM dump"
|
| 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/Task.java
|
| 56b88afcbdd190e8448fd17db91f2bf94e00c1fa |
|
01-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
Add bounds information to stack/task WM dump
Change-Id: I01b0bf1feb2412f9ce73b2317ba6a56b48bc1a97
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| ba5488123152d215caa19b2b0e6d8dcaa8b5eae3 |
|
25-Nov-2015 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Allow stacks to be placed outside of display"
|
| b15758ab7a6481717d0d29612e870d7241061c31 |
|
17-Nov-2015 |
Chong Zhang <chz@google.com> |
Support scrolling for non-resizeable tasks in side-by-side mode
Display toast when a non-resizeable task is put into side-by-side mode.
Scroll the task upon a two-finger scroll gesture.
bug: 25433902
Change-Id: I69967056a564cfe7773afb80aa7e7ea7167a791a
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 2fbe033f9d634505ff9e90f232c0339f616d7b86 |
|
25-Nov-2015 |
Jorim Jaggi <jjaggi@google.com> |
Allow stacks to be placed outside of display
When dismissing the docked stack, we animate the divider to position
-12dp, so the full-screen stack is exactly full-screen when the dismiss
animation is done. Previously, this was prevented by window manager.
Allow it to fix the animation.
Change-Id: Iee4505023dc3f6907d56851965b156235f9f97f2
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| d8ceb85512f8dc2dac6ef07fc72f89a75095e3d7 |
|
11-Nov-2015 |
Chong Zhang <chz@google.com> |
Fixes for touch exclusion region
- Evaluate touch exclusion region on per-task basis, instead of per
window. Smallest unit for exclusion is Task, if task has more than
one app window, we still need to use the visible area of the task
to do focus transfer properly.
- Only add back the touch region for focused task after all tasks
are processed for eclusion, otherwise the focused area could be
removed from exclusion incorrectly.
- Skip app windows that's exiting or hidden.
bug: 25494928
Change-Id: I972ba2149431557e7420b1095d9496a6cd821bdb
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 14c040bdd9595871546af8a59f96c65445e438b2 |
|
11-Nov-2015 |
Chong Zhang <chz@google.com> |
Merge "Fixes for dim bounds and touch bounds"
|
| 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/Task.java
|
| 935e50292e1404dc5f1705b2a1719cdaee3072b0 |
|
10-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Set right bounds/configuration for task when positioned in stack.
When AMS.positionTaskInStack API is called we need to make sure
the task has the right bounds and configuration if it is moving
to a different stack.
Bug: 25501082
Change-Id: I2a80aa08a4ee52d860502ab16b6cdb432c954084
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 13d30660ef6da2d924e4fc943ccd187767ee0cd2 |
|
07-Nov-2015 |
Winson <winsonc@google.com> |
Fixing issue with canceling the thumbnail in addition to the app window.
Bug: 25392381
Change-Id: Ib507f53bcd2aad4771c2546f5e8bfe771769e9a2
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.java
|
| 02a5a6bb9ba05bdf7517de90ede49fb535ea06ca |
|
02-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Added StackId object for checking what features a stack supports"
|
| 3797c22ea16e932329ebffdc7e7ce09f9ecd9545 |
|
27-Oct-2015 |
Wale Ogunwale <ogunwale@google.com> |
Added StackId object for checking what features a stack supports
Helps make the code easier to follow since we are no longer checking
multiple stack ids at various decision points.
Bug: 25282299
Change-Id: Ifa6864a1ef56ce2eca4c94f87a4e0b993de987cd
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| c28098f69b8ba5d3039ecd0fa154e880f4613843 |
|
30-Oct-2015 |
Winson <winsonc@google.com> |
Add ability to cancel task window transitions.
Bug: 25392381
Change-Id: I45f48edc21c058df0e4c22ceaf7e9aef5899a29c
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.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/Task.java
|
| 99db1863a84364339fc5dc9142f15910cdd96ed8 |
|
24-Oct-2015 |
Wale Ogunwale <ogunwale@google.com> |
Added support for pinned stack.
Used to support picture-in-picture use case for multi-window
Bug: 25006507
Change-Id: I3bef3f75e0c003f5974274294f1250171d424625
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.java
|
| 44bc4daff31d2d6f632695008a0e5f5272ff4f56 |
|
03-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Only request resize for tasks on the freeform stack.
This fixes a crash during orientation changes, where window manager
requests a resize for a docked task, but activity manager throws an
exception since dock tasks can only be resized when their stack is
being resized.
Bug: 24575031
Change-Id: I954c4e6ae60931b30200b10c8a4834b0a5757606
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.java
|
| b186388b673035f3a19bcc5d6f9dd8545549a224 |
|
30-Sep-2015 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Report re-sized stacks/task as fullscreen when docked stack isn't visible"
|
| f175e8a6d0d3f3ce6be94bde451e6e03f67d0705 |
|
29-Sep-2015 |
Wale Ogunwale <ogunwale@google.com> |
Report re-sized stacks/task as fullscreen when docked stack isn't visible
When a docked stack exist we resize all other stacks and crop their
window content to the stack size. This was also been done when the
docked stack exist, but not visible. E.g the primary user has a docked
stack, but the secondary user doesn't, so the windows of the secondary
user get cropped.
We now report stacks/task sizes as fullscreen whenever the docked stack
isn't visible.
Bug: 24366804
Change-Id: Ia3f24e6f7d33fc175348e27db24a15ce3027e6f7
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 1ed0d89e7e9a28a5dd52fdc40425466efd8d08ef |
|
28-Sep-2015 |
Wale Ogunwale <ogunwale@google.com> |
Inform activity manager of stack/task rotation bounds changes in WM
Change-Id: I342093d8af1d397ab4894146f9b288bdfdc464f0
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 9184ec686072e9343c9dd73cf45324e5e89e042f |
|
24-Sep-2015 |
Chong Zhang <chz@google.com> |
Use visible frame instead of task bounds for detecting resize start
Initial task bounds might be adjusted (for status bar, etc.). Touch
should be set up using visible frames instead of task bounds.
bug: 24336351
Change-Id: I944e3185a06c39b451432bdda5ad87880a0482f3
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 466f3216505bd039a285881e06ead631331fe368 |
|
22-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Showing docked stack divider window.
When there is docked stack, we want to show a "handle" through which the
user will resize the docked stack. We add it from the system process,
because we want to avoid IPC calls.
Change-Id: If15fd2a0fcb7077446d1ba6c533acb3028a42039
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 9474421a56c8bf66086a9d253013687eb5207331 |
|
22-Sep-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed issue with stack size when rotating screen.
Stack bounds needs to be adjusted when the screen is rotated
so it occupies the same bounds on screen.
Change-Id: Id00031f2e1275f2d095f6e6b2e76b5b5d5c13864
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 87b21722c2336490ecf8b66f6acfc46ce8cc6f46 |
|
22-Sep-2015 |
Chong Zhang <chz@google.com> |
Change resizeTask's parameter resizedByUser to constants
to indicate who initiated the resize, or if the resize should be forced.
Change-Id: Ic7021f76bec677027cbf27deeb63f92ea911a75c
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.java
|
| 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/Task.java
|
| 2cc92f55c0257cdc837585b36987c610fb0a8251 |
|
09-Sep-2015 |
Wale Ogunwale <ogunwale@google.com> |
Don't relayout app contents when just changing app position
In WMS.resizeTasks we call task.resizeWindows() whenever the
task bounds changes which causes the app to do layout passes.
This isn't needed if we are just changing the position of the
task and not the size. This is currently causing unneeded churn
in the system and which leads to lag with the dragging operation.
Bug: 23901900
Change-Id: I339e31af3b657db6146dc1220bf5eb13e18b7876
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| ebcc875f10f05db7365cd8afbf4e9425221ab14d |
|
26-Aug-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Move Configuration creation from Window Manager to Activity Manager.
Currently the construction of configuration is split between thease
two entities. This poses two problems: it's harder to follow the
construction logic and more importantly we can't determine if
configuration changes significantly before delegating work to the
Window Manager. This CL moves the configuration override logic to
the Activity Manager, since it both detects configuration changes and
informs clients about them. Window Manager becomes purely a recipient
of the information.
Change-Id: I075570ee055cce9c5665772fa8d4fe8ccb5c6313
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| b34a7ad1af54132b6b046ab8f768e0ffb81cf581 |
|
14-Aug-2015 |
Wale Ogunwale <ogunwale@google.com> |
Added support for docked stack
Docked stacks occupy a dedicated region on a display.
When a docked stack is present all other static stacks bounds
are restricted to the region of the screen not occupied by
the docked stack.
Change-Id: I6aec3aa19c41a7e756375002f3a925977b5533b5
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 234dbf875f795fdb72f82dc6ea805201ee31fb0e |
|
13-Aug-2015 |
Stefan Kuhne <skuhne@google.com> |
Don't clip task windows in some workspaces
Bug: 23176762
Change-Id: I5bf40fbb8794ccb26650a376ded6d75ac425ac29
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 706ed793409f800a2b8dfbe66ac6992d057549de |
|
02-Aug-2015 |
Wale Ogunwale <ogunwale@google.com> |
Support creating/launching a task with non-fullscreen bounds
Change-Id: Icc6d6b25b5f6f236030e654a3eb3ec7f00287d2f
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| ddc1cb2c15549ed23dce9d416680a009fa6ae23c |
|
26-Jul-2015 |
Wale Ogunwale <ogunwale@google.com> |
Added support for static vs. dynamic stacks
Now that stacks represent workspaces we can define static
stacks which help shape the characteristics of the tasks
they contain. For example, fullscreen tasks/activities will
normally be launched in the stack with id
FULLSCREEN_WORKSPACE_STACK_ID, while freeform tasks/activities
will normally be launched in the stack with id
FREEFORM_WORKSPACE_STACK_ID.
Also, added ability to position a task at any index in a stack.
Bug: 22068114
Change-Id: Ib6c62a84b5f204fbf072755264c5c5eda6184f97
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.java
|
| 6dfdfd6741c5a3dd8d8a49ddbd6ee5dfe2fd292d |
|
15-Apr-2015 |
Wale Ogunwale <ogunwale@google.com> |
Added attribute showForAllUsers that deprecates showOnLockScreen
The new name is more meaningful to what the attribute actually does.
Also, force the FLAG_SHOWN_WHEN_LOCKED flag for windows that belong
to acitivties with the showForAllUsers attribute set.
Bug: 20227306
Change-Id: Ifd49166c3ec0e67ae43addc0fb30038523332ea5
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 3fcb4a89750d6df42f850021cd754500fc084086 |
|
06-Apr-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed bug with ActivityInfo.FLAG_SHOW_ON_LOCK_SCREEN not working
There were a few places in ActivityManager and WindowManager that we
were not taking the value of the flag into account when deciding
which task to be up top in multi-user mode.
Bug: 10533764
Change-Id: If2032ccd5f1a67b3ad4af376b4db7043e9070796
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 000957cef387dc7d08fc6563e2221e9023194984 |
|
03-Apr-2015 |
Wale Ogunwale <ogunwale@google.com> |
Don't remove task from recents when moving task to another stack.
Also, made event log reason for remove task when moving different
from when removing.
Bug: 19946163
Change-Id: Iea2b7a84040759e9ad0a7dc8c6f4aee67b15467b
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 53a29a90f35f72462c0d6ad650921d5566c1f8f0 |
|
24-Feb-2015 |
Wale Ogunwale <ogunwale@google.com> |
Added ActivityManager API and AM command to resize a task.
Also fixed issue with ActivityStackSupervisor.moveTaskToStackLocked()
functionality not working correctly.
Change-Id: Ia13f1e92a7c59ce6543c226533ac8ea623488290
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 83162a90278d9d52d8fca7ee20ba314b452261de |
|
26-Jan-2015 |
Craig Mautner <cmautner@google.com> |
Eliminate groupId and add task to AppWindowToken
Simplifies access by eliminating indirect referencing.
Fixes bug 18088522 item #15.
Change-Id: I9049192a7f3e1028d60c4f2d4d4a0d4aad590aa4
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| e3119b7d353e71d1f94ddff932b722b4d285931e |
|
21-Jan-2015 |
Craig Mautner <cmautner@google.com> |
Refactor removeApp and removeTask for last removals.
Move app token removal to the AppWindowToken class so cleanup can
be done locally. Move task removal to the Task class so cleanup can
be done locally. Call task removal when the last app is removed.
Merge actions done prior to method calls into methods.
Fixes bug 18088522 item #12.
Change-Id: I5ce85d2bb309ceb82bd7404e27a56a7c31cd7359
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 3d7ca31c9e4a076cef5339ae58d5cafb2efbbc8f |
|
08-Jan-2015 |
Craig Mautner <cmautner@google.com> |
Remove AppWindowTokens from exiting apps with task
When the task is removed from a task stack in window manager any
exiting activities left in the stack were orphaned. This led to a
memory leak. Removing all task activities from those that are exiting
fixes this problem.
Fixes bug 18943737.
Change-Id: I0a5ea8d2d3be89af7ccaf01385a226a2eafdf507
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| cbd84af39a329890013b0c3b6763280ba2ad78c9 |
|
22-Oct-2014 |
Craig Mautner <cmautner@google.com> |
Cherry pick task movement changes from aosp
The following cherry picks from aosp contain code that keep windows
tracking the task movement.
https://android-review.googlesource.com/#/c/111380/
https://android-review.googlesource.com/#/c/109930
Maybe fixes bug 15729183.
Change-Id: Ida69fe365b06025d119e32b22a8d04958cdbabf3
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 01f79cf91610ec9f85345ea6eeae50ea2f28578f |
|
27-Aug-2014 |
Craig Mautner <cmautner@google.com> |
When adding an apptoken skip over removed ones.
App tokens are passed from the activity manager to the window
manager along with a list insertion position. That insertion
position presumes that all removed tokens are no longer in window
manager's list. However, when removal of a token is delayed due
to ongoing animation the insertion position was pointing to the
wrong location. This fix skips over tokens that have been marked
for removal when inserting new app tokens.
Fixes bug 15751591.
Change-Id: Ib484c591e2bba9f46ad8e47d60ef05c7bfda0a12
/frameworks/base/services/core/java/com/android/server/wm/Task.java
|
| 42bf39edbdad19f51497938d0a3469dd772f19e8 |
|
22-Feb-2014 |
Craig Mautner <cmautner@google.com> |
Reset deferred task removal when app token added.
A task is scheduled for deletion after the final activity has
been removed and has animated away. But if another activity is then
added to the task the deletion flag must be reset.
Also added improved debugging.
Fixes bug 12987986.
Change-Id: I207ea6e9592a9e036d67aa5d1465b4acc5bdd120
/frameworks/base/services/core/java/com/android/server/wm/Task.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/Task.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/Task.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/Task.java
|