| d18712695c6b8861e6b22f9ef64709022ae94ee1 |
|
12-Jun-2017 |
Bryce Lee <brycelee@google.com> |
Address issues surrounding freezing by display.
The first issue is the animating a display as a consequence of the
freezing due to configuration change during construction. This
additional animation is not expected and interferes with tests
expecting for the original display contents to be shown intact. This
CL addresses the issue by not freezing while the display is not ready
(before construction is finished).
The second problem addressed is book-keeping for
DisplayContentsAnimators in WindowAnimator. Currently, a getter
method is used internally to reference these animators, which
generates them if not present and adds them to the animation
iteration. In the case we set an animation on a display that no
longer exists (which can be the case after unfreezing), we end up
recreating this object. This can lead to us trying to animate a
non-existent DisplayContent. This CL prevents creating an animator
for a non-existent display and adjusts the methods using this getter
to handle this case.
Fixes: 62460846
Fixes: 62461229
Bug: 35486733
Bug: 62541591
Test: go/wm-smoke
Test: open and close projected android auto mode repeatedly and
ensure display correctness
Test: cts-tradefed run singleCommand cts-dev --module CtsMediaTestCases --test android.media.cts.EncodeVirtualDisplayTest#testEncodeVirtualDisplay
Change-Id: I60ade6f97440c8fa01b10e36c019865cf1fd0730
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| f867733d4ff2dbb84ec15371630f7293e6321786 |
|
08-Jun-2017 |
Bryce Lee <brycelee@google.com> |
Merge "Revert "Coordinate configuration changes and window frame size."" into oc-dev
|
| 46b01655b3448706797dfadc3d9a7c6495bb6e5c |
|
08-Jun-2017 |
Bryce Lee <brycelee@google.com> |
Revert "Coordinate configuration changes and window frame size."
This reverts commit afb45bba8379df530182dae882ec70329423dcfe.
Bug: 32839232
Fixes: 62424393
Change-Id: Ifaa0176e18100ec85b8c81268a26fb16ffe9b5f3
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 8f85358fe4bab8ac3ca0b77905d51725a531a436 |
|
06-Jun-2017 |
Bryce Lee <brycelee@google.com> |
Associate freezing display with a target display id.
Currently, start/stop freezing is always associated with the default
display. As a result, any animations that result from freezing will
occur on the default display. One situation this happens is during a
configuration change, where a screen rotation can be triggered. In
the case of adding a secondary display, a configuration change is
always triggered to apply the override configuration at the display
level. As a result, the default display exhibits a rotation animation
upon unfreezing during surface placement.
This changelist passes down the display id associated with the action
so that the animations may be applied to the right display. In the
scenario described perviously, the secondary display id is passed down
and therefore is the target of the rotation animation during
unfreezing.
Fixes: 35486733
Test: go/wm-smoke
Test: cts-tradefed run singleCommand cts-dev --module CtsViewTestCases --test android.view.cts.SurfaceViewSyncTest#testSmallRect
Change-Id: I87e56f5901934327fc50b3c7e543b5e36b8ff34f
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| afb45bba8379df530182dae882ec70329423dcfe |
|
27-Apr-2017 |
Bryce Lee <brycelee@google.com> |
Coordinate configuration changes and window frame size.
Previously, it was possible for the view hierarchy to be measured,
laid out, and drawn around a window frame size that did not match
the current configuration. This stems from new configurations not
always propagating back from WindowSession#relayout, which is
called from ViewRootImpl.
This changelist makes WindowManagerService#relayoutWindow always
return the latest configuration. It also adds rotation to the
configuration.
Fixes: 32839232
Test: go/wm-smoke
Test: Open Camera while rotating phone to landscape. Added
temporary logs to detect inconsistencies between measurements
and reported rotation on draw.
Change-Id: I39daca338b4f87eff1a509eb99493f01e710ced1
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| bfa81adfbe1819d55737dbbb2fb9157e50dbe022 |
|
25-May-2017 |
Wale Ogunwale <ogunwale@google.com> |
Fix unnecessary relaunches when unlocking with fingerprint sensor.
When the device is unlocked using the fingerprint sensor in an
orientation opposite to the lockscreen orientation, the app that
will be visible is first relaunched in the current lockscreen
orientation and then later relaunched in the correct orientation.
If the keygaurd is going away then:
- Don't let keyguard affect device orientation. We want to use the
orientation of the app that will be visible.
- Allow the rotation sensor to be enabled even though draw isn't
complete so window manager can get the updated or last rotation
reading.
- Don't clear the previous proposed sensor reading to allow
window manager to use the information to update the orientation as
needed vs. falling back to the previous orientation.
Change-Id: I8369723d6a77f2c602f1ef080371fa7cd9ee094e
Fixes: 38494778
Test: Launch an app that doesn't fix orientation like clock, hold
the device in landscape, press the power button, unlock the device
using the fingerprint sensor, and verify the the app isn't
relaunched.
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 64900ad13ccaa78b163d73783d484ccc4a7c607d |
|
19-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Take snapshot when screen is turning off" into oc-dev
|
| 51304d7380b6122ac55645fd9085ba071b04afa9 |
|
17-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Take snapshot when screen is turning off
Since we can't take a snapshot when screen is turned off, we need
to snapshot before we are turning the screen off. For this, we
- Add a callback from DisplayPowerController to give policy a
chance to do something before display will be turned off.
- Implement this callback by taking snapshots of all visible
tasks.
Test: Inspect logs/traces about screen off blocking to make sure
callback is working correctly.
Test: Insert artificial 500ms delay in onScreenTurningOff and make
sure we are unblocking screen off when turning on screen in the
meantime.
Test: Open Maps, go to recents, open maps again, scroll to another
location, toggle power button, make sure the old location isn't
shown during unlock.
Change-Id: I489f31358f838d418f894f996495946084f136a4
Fixes: 37107783
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 5a270bcd6665c705b9b761f8e956356fb492218e |
|
18-May-2017 |
Andrii Kulian <akulian@google.com> |
Merge "Don't report displays that are going to be removed" into oc-dev
|
| 0214ed9b119cdbc87cfc12908635deaf16603fe5 |
|
16-May-2017 |
Andrii Kulian <akulian@google.com> |
Don't report displays that are going to be removed
When display is removed from system, it is immediately removed from
AM, but removal can be deferred in WM if there is an active animation
on that display. If AM then requests display ids in focus order from
WM, it might get a display that was already deleted in AM.
This CL skips displays marked for deferred removal.
Bug: 38166277
Test: DisplayContentTests#testDontReportDeferredRemoval
Change-Id: I49544963f476fc58a609094781ed46541af8a238
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| dc9385aad49bf2ba24c1221a5d4558a1ac69f97a |
|
13-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Immediately report drawing
No need to wait on the next relayout - this can only delay the
transition. Makes hot launches a lot more consistent.
However, this made it too fast! We then hit a race condition when
the app transition was already starting but no other layout was
done yet. When another layout was executed we noticed that we need
to report resized for the starting window, clearing it's drawn
state, which set startingDisplayed=false, which jumped the app
window animation to the end.
To fix this, make sure not to report another resized immediately
after the initial layout, as the client already knows the latest
(because it calls relayout at some point before it starts drawing).
Also fix "animating" async systrace for better analysis.
Test: Open/close size-mismatching task snapshot 100 times, ensure
no animation skipped.
Test: Look at app transition logs, ensure more consistent.
Test: Overall system sanity testing (open a couple of apps/dialogs
etc).
Bug: 32668632
Change-Id: Id795cd6a84f22e6a619089cb9554fc5033477ad2
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| c6ae42a58841402e5b2a9e8dfe114b35fdfe25ee |
|
08-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix IME Keyguard exit animation
Keyguard exit animation was always applied no matter whether the
current window is shown or not. Because Keyguard exit starts with
alpha=0, this lead to a flicker with the IME window as a frame
later IME was applied its dismissal animation, which reverts it to
alpha=1 at the beginning.
Fix this by only applying exit animation if window is currently
hidden only by policy. Requires readding the old visibility method
*cough cough cough*
Ideally we would apply non-app window policy visibility/animation
at the same place...but today is not the day! (to minimize risk)
Test: Set password, unlock phone
Test: Don't set password, unlock to activity with IME up
Change-Id: I46110c80da4438223282903fd4defeba2c3f0550
Fixes: 36200726
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| d193972a7fa6fe692f2a1c58c50dbc6ed22603c7 |
|
09-May-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fixed issue with associating WindowToken with null binder." into oc-dev
|
| 399c869d25395cb5fb81fb2190c2d894bff3c50f |
|
08-May-2017 |
Wale Ogunwale <ogunwale@google.com> |
Revert "Only allow AM to update display orientation based on app containers"
This reverts commit 5f1ae6aaca78a14d25e28042df32df642ab3d29e.
This caused b/38021942.
Change-Id: Idb23e5ede7aaa4a927e148c0daab3f56ac449d66
Fixes: 38021942
Bug: 37550022
Test: manual
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 2f569ed618f0eb834efb7a27c57d8ca43bcf4f1b |
|
08-May-2017 |
Wale Ogunwale <ogunwale@google.com> |
Fixed issue with associating WindowToken with null binder.
App don't have to specify a LayoutParams.token when adding a window to
the system, however when they don't WM maps all the windows to a single
WindowToken mapped to a null IBinder. This isn't correct since the
windows can be coming from different apps and also null binder shouldn't
be used to map tokens.
We now:
1. Associate the WindowToken with the IWindow client for bookkeeping in
WM if the app didn't specify LayoutParams.token for the window it is
adding.
2. Throw an illegal argumenet exception we we try to associate a null
binder with a window token or null window token with a binder on a
display.
Fixes: 38021710
Test: Start an alert window, lock and unlock the phone, long press to
bring up power dialog, and tap outside it to make sure it goes away.
Change-Id: I6816b7fb9b9a0a8f5387062bada862eb75004e4f
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 70f59488d73665730f06860d40dd380602399a8f |
|
04-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix bounds calculation
Don't include the wallpaper window when calculating the frame
in multi-window.
Test: Go multi-window, go recents.
Change-Id: I8b4fb48767d6bdbda055d9c631811ad5a1dcaee6
Fixes: 36240988
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| eb59d6e9d6f652a9e77d4190b52ef4c4f1b9f438 |
|
04-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Don't include IME in app screenshot
Test: Compose message in messenger, go to recents, make sure
IME is not visible in snapshot
Fixes: 37084760
Change-Id: Ic311eb452590fa26adb1ecedb7ae5eba3275d88c
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 5f1ae6aaca78a14d25e28042df32df642ab3d29e |
|
02-May-2017 |
Wale Ogunwale <ogunwale@google.com> |
Only allow AM to update display orientation based on app containers
Activity manager choregraphs several app states when starting an
activity including when the display orientation should be updated based
on the app that is now in the foreground. It is possible for a call to
originate within WM after AM adds the starting app token, but before AM
makes the app visible and resumed. E.g. A relayout call due to a
starting window. When this happens WM can prematurely update the display
orientation with incomplete information causing the starting app to be
in an incorrect orientation initially.
To fix this problem we now only factor in app containers (stacks, task,
..) when updating the display orientation if the call to update is
coming from AM. Otherwise we only use the non-app/system containers to
determine the orientation or return the last orientation.
Change-Id: I431ce9260ee31257732311a548c62cbcdb27eae7
Fixes: 37550022
Test: Launch 2 apps that don't fix orientation and use the recent button
to switch between them while holding the device in landscape.
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 40d0f8678347a40e750a8349e923a1dd2545c4e4 |
|
03-May-2017 |
Andrii Kulian <akulian@google.com> |
Merge "Update ime touch exclude region for hosting display" into oc-dev
|
| 7a31b773a88ba8be0ce960b097cf3904feefb7c9 |
|
02-May-2017 |
Andrii Kulian <akulian@google.com> |
Update ime touch exclude region for hosting display
If IME for an application is situated on a different display,
then we need to update corresponding display content's touch
exclude region.
Bug: 36515606
Test: Manual, b/37911363
Change-Id: I43785de6f26adf88e9a76b9144b39f66f232a646
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| f7e6f581c0b30550c53e4d0aedefcabd64c80293 |
|
29-Apr-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Window can only be fully drawn if app window is not relaunching" into oc-dev
|
| 498c71dd9dbcf2b13e0beb923a027a302e2cf685 |
|
18-Apr-2017 |
Matthew Ng <ngmatthew@google.com> |
Window can only be fully drawn if app window is not relaunching
This fixes the glitch of having transitions be calculated incorrectly
when starting new activity when other windows still exist. For example
launcher3 has minus one window exist even if the main activity is
destroyed causing incorrect transition going home. This change only
allows the calculation to occur when the app window is not relaunching.
Test: manual - launch app, rotate screen, go home
Change-Id: I7e323486ee6e05ba4c8704832ca0f9d6e648ac90
Fixes: 36113180
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| fef058d7d04be1a14007e9d8568c093769c45a97 |
|
25-Apr-2017 |
Winson Chung <winsonc@google.com> |
Prevent IME adjustment for stacks not affected by docked stack resizing
Bug: 37358175
Test: Resize docked stack while PIP is up
Change-Id: I4f057f6671e8c164624359bf3532f9a22fdf768e
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 2117aaf5aef7889908d1560f26a61fea22b616ce |
|
25-Apr-2017 |
Robert Carr <racarr@google.com> |
More targeted version of "Correct animation glitch for pinned stack."
See the referenced CL "Correct animation glitch" for an explanation of
why an exception in this area is required. That CL based the exception
off the dummy animation state, however it seems we also enter this
state in various docked transitions but in that case the dummy animation
will have the incorrect transforms referenced by the original comment.
Now we target the fix on the bounds animating state instead.
Bug: 37448295
Bug: 36777039
Bug: 37511473
Test: Dock app from recents, no stretching. Auto-pip app, doesn't get stuck in top-left. Yay!
Change-Id: I5c9a7384622de9cedcc4be4dec7caacf58c683eb
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 8997322ed3c8014e1833323b71e5a8d34e6a9e14 |
|
24-Apr-2017 |
Wale Ogunwale <ogunwale@google.com> |
Fixed transition animation from pipable activities
- Defer telling the client it is hidden if it can enter Pip and isn't
current stopped or stopping. This gives it a chance to enter Pip in
onPause().
- Once pause is complete set the visiblity to false to stop deferring
hiding client.
- Don't allow FLAG_RESUME_WHILE_PAUSING activity to resume until the
currently resumed activity is puased if the currently resumed activity
can enter Pip.
- Detach child surfaces added by the client process in
WindowState.sendAppVisibilityToClients() right before we notify the
client.
Test: manual
Change-Id: I3848f2b93f4f1d3ceec5a1ccd2e127c614f70fe4
Fixes: 37370508
Fixes: 37622341
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 22d4ef008dd1956424f1026f151930ccd47d7db6 |
|
17-Apr-2017 |
Bryce Lee <brycelee@google.com> |
Merge "Don't allow stacks above pinned stack." into oc-dev
|
| 32c566fe6e4fca9f41a027352f2ef431342ac3fc |
|
12-Apr-2017 |
Winson Chung <winsonc@google.com> |
Fixing missing movement bounds notification to SystemUI.
- When WM updates from a configuration change, ensure that we update the
pinned stack controller even if there is currently no pinned stack.
- Also finish the menu activity once an activity is unpinned.
Bug: 36879891
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: I789945c1783693cf4b4e3d6663548c8669784001
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 971fe468a493e8f1164ec4ae147e404505b551a0 |
|
11-Apr-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Revert "Revert "Handle case when snapshot dimensions don't match""" into oc-dev
|
| 48f4b57591d08e0c0b1de0fbc7d79ebd915d0cf9 |
|
10-Apr-2017 |
Bryce Lee <brycelee@google.com> |
Don't allow stacks above pinned stack.
Previously, stacks would be allowed above the pinned stack if the
pinned stack was not visible. We however do not correct the stack
position when the pinned stack later becomes visible. This can lead
to a scenario where the pinned stack has become visible yet is below
other stacks. When a stack is positioned in this state, an
IllegalStateException is thrown to indicate the invalid pinned stack
position.
Since the pinned stack should only be present and populated when
there is a pip activity, we can instead use its presence as an
indicator other stacks should be underneath it. This avoids placing a
stack above the pinned stack during transitional states where the
stack children might not be visible, therefore preventing the above
exception from occurring.
Fixes: 36669386
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests#testPinnedStackLocation
Change-Id: I67a58806e83b11f0b135c12441bb0a9bec58eee7
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 30d64f3a93f5fc5aaf75eeb38d658ef04a884b41 |
|
07-Apr-2017 |
Jorim Jaggi <jjaggi@google.com> |
Revert "Revert "Handle case when snapshot dimensions don't match""
This reverts commit ba53d8ae410976709e1413b74173a791e8dead15.
Also fixes that we always had a size mismatch.
Test: TaskSnapshotSurfaceTest
Test: Open app in different orientation than snapshot, make sure
looks ok.
Bug: 36991071
Change-Id: If572b68fd72cec7679984fdff0be5905caba69f4
Fixes: 36703868
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 51c1b670224fa1598644426b472d51346dd22f30 |
|
08-Apr-2017 |
Andrii Kulian <akulian@google.com> |
Fix activity move between displays
1. ActivityConfigCallback might not have been registered
because DecorView was not yet attached to window and ViewRootImpl
was not available. In this CL the callback is set as soon as a
DecorView is attached to window.
2. When private display was removed from system, its stacks were
moved to bottom in AM but moved to top in WM.
3. When reparenting stack visibility of activities should be updated
before reparenting in WM, because otherwise WM will be resizing
windows that should no longer visible and reporting it to clients.
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Test: #testContentDestroyOnDisplayRemoved
Change-Id: I6ccc27d873d0d60d7650659fb25cbfcaaeb0fd07
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| e7ac324c71fb52d4104c8d92c9cea55d334bb4f1 |
|
06-Apr-2017 |
Jason Monk <jmonk@google.com> |
Merge "Revert "Handle case when snapshot dimensions don't match"" into oc-dev
|
| ba53d8ae410976709e1413b74173a791e8dead15 |
|
06-Apr-2017 |
Jason Monk <jmonk@google.com> |
Revert "Handle case when snapshot dimensions don't match"
This reverts commit aea6b74e17a0f7b105999adad50dd20eac17df35.
Bug: 36991071
Bug: 36703868
Change-Id: Ie71992144e78a6580bfce17dfdf20396af80eacd
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 0c901695e6770bab6a7d247e1d8ce431fc3ca955 |
|
06-Apr-2017 |
Robert Carr <racarr@google.com> |
Correct animation glitch for pinned stack.
During an auto-PiP operation it can be
such that the pipped activity "isWaitingForOpening".
This is due to the visibility toggling to hiddenRequested,
and then back to visible, which causes it to enter mOpeningApps.
Logic in display content, prevents updating the surface boundaries
while we are in this waiting for opening state. This causes the animation
to jank as the top left corner will not move. The claim made
by the comment is that certain animations may have not "processed
their initial transformation". So we ignore this "waiting for opening"
state if the app transition is a dummy animation, in which case we have
no transformation anyway.
Bug: 36821017
Bug: 35396882
Test: Enter PiP from YouTube, make sure top left corner moves smoothly.
Change-Id: Ia8519fe3c955f2ac80151b851c219d6ddbd26fed
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 1edadac465f70629c66b0c9b053b8ac154133ec9 |
|
04-Apr-2017 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Handle case when snapshot dimensions don't match" into oc-dev
|
| cd097993399f94aa663c5fad50e444b75e6ee5dd |
|
24-Mar-2017 |
Andrii Kulian <akulian@google.com> |
Update display contents when metrics change
There are two separate overrides for display metrics in DisplayManager
and WindowManager:
- In DM - LogicalDisplay#mOverrideDisplayInfo, in most cases not null.
- In WM - DisplayContent#mBaseDisplayWidth/Height/Density, different
from #mInitialDisplayWidth/Height/Density values when some metrics are
forced.
When display was resized its windows weren't updated because of
two problems: old LogicaDisplay#mOverrideDisplayInfo was preventing
WM from detecting the change and override (base) display metrics were
never updated by resize.
When display size changes:
- Before this CL:
DM receives DISPLAY_CHANGED event, it updates internal values and
WM is notified about them with a message. In most cases there is an
override obtained from WM and WM doesn't get new values from
LogicalDisplay#getDisplayInfoLocked().
- With this CL:
WM will requests real updated values from DM without any overrides
and will decide whether to apply them or not: if there is no override
in WM - it will apply values from WM, otherwise it will keep the
override. Also it will always update initial display metrics if there
is a real change detected.
Bug: 35258051
Bug: 34164473
Bug: 36518752
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testDisplayResize
Test: #testForceDisplayMetrics
Change-Id: I2495c27797f11f9aaee4ea06648a8ccd29ac5b62
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| aea6b74e17a0f7b105999adad50dd20eac17df35 |
|
21-Mar-2017 |
Jorim Jaggi <jjaggi@google.com> |
Handle case when snapshot dimensions don't match
If the snapshot starting window has different dimensions than the
snapshots we have taken, we do the following:
- Create a child Surface that has exactly the dimensions of the
snapshot.
- We fill the parent surface with the app background color, as well
as all screen background decorations (status bar background,
navigation bar background).
- We also clip of the status bar/navigation bar background in some
cases, as it looks ugly if it's not behind the system bars.
- Furthermore, we inherit all layout flags on the window and all
layout relevant SystemUI flags on the window such that it's very
likely that the size will match, and the system bars are drawn
correctly.
- In order to make the transition from the snapshot to the real
window a bit more predictable/less messy, we enforce a minimum
duration the snapshot is visible, which is slightly more than our
app transitions.
Test: TaskSnapshotSurfaceTest
Test: Open app, go home, go landscape, open app again
Test: Go to multi-window, open app from recents with a snapshot
taken in fullscreen.
Fixes: 36703868
Change-Id: Ia2d4add6971a18ab7aa2942d2b644d6e87a402af
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 7566d76c618a48b8dcc981dac3cab1e42f864063 |
|
30-Mar-2017 |
Bryce Lee <brycelee@google.com> |
Add app bounds to configuration.
The system previously overrode the display size for a specific scope
(task/activity/etc.) by setting the associated Configuration's
screenWidthDp/screenHeightDp. This leads to two issues. First, the
conversion of screen size from pixels to display independent pixels
and then upconverting later on leads to rounding errors. Secondly,
the screenWidthDp and screenHeightDp values account for insets, such
as the status bar. These however are not reflected in the display
size when returned from Display#getMetrics/getSize.
This changelist addresses the issue by adding a Rect value to
Configuration which stores the app display bounds. This is always set
at the display level and overridden as appropriate. As the proper
app insets are accounted for at the root configuration, all overrides
(outside of specific exceptions) are the result of the intersection
between the requested bound and the parent bound.
Change-Id: I2c4fcd0bee92af12aabbca258de05b4ec061d0e1
Fixes: 34338931
Bug: 36812336
Bug: 36676979
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsAppTestCases android.app.cts.AspectRatioTests
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsServicesHostTestCases android.server.cts.ActivityManagerDisplayTests
Test: bit FrameworksServicesTests:com.android.server.wm.AppBoundsTests
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 2b33162e82ba0c0d4af45c1c73157745a0adc061 |
|
30-Mar-2017 |
Rob Carr <racarr@google.com> |
Merge "Remove code for seamlessly rotating SurfaceView's." into oc-dev
|
| 897215d76ae2e7cbca63a505113f5d90ef892d81 |
|
29-Mar-2017 |
Robert Carr <racarr@google.com> |
Remove code for seamlessly rotating SurfaceView's.
No longer required :D
Bug: 36230754
Bug: 36727915
Test: Rotate camera in different modes.
Change-Id: I7708d61646a36bc0c35cfa91d441296eb49eff9a
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 27cec32496090efd153327f4fc5a5cecc6f59d9b |
|
21-Mar-2017 |
Bryce Lee <brycelee@google.com> |
Add configuration for maximum UI width.
This changelist adds config_maxUiWidth, a new system resource
configuration which specifies the maximum width the user interface
can operate in. If the physical or specified width is greater than
this value, dimensions and density are scaled down accordingly. The
native mode resolution can be still discovered through
Display.Mode#getPhysicalWidth/getPhysicalHeight.
Test: Defined override for development device and verified values.
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests#testMaxUiWidth
Change-Id: I12e7ad52f2aa8014e143bc7e80b020c9b24ed9c8
Fixes: 25820708
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 55ddf8f9e5d8241130aeac6be7b4978860f41bf8 |
|
20-Mar-2017 |
Wale Ogunwale <ogunwale@google.com> |
Added support for maxAspectRatio manifest attribute.
- Allows an app to specify the maximum aspect ratio it supports.
- Support for overriding configuration and bounds at the activity
record and app window token level.
Test: cts/.../run-test CtsAppTestCases android.app.cts.AspectRatioTests
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerTests
Test: bit FrameworksServicesTests:com.android.server.wm.WindowFrameTests
Bug: 36505427
Bug: 33205955
Bug: 35810513
Change-Id: Ib2d46ed0c546dd903d09d6bb7162a98bd390ba81
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| b6c5c0d902f8afd6108d49f43be4b8abfef3a8b0 |
|
22-Mar-2017 |
Andrii Kulian <akulian@google.com> |
Revert "Update display contents when metrics change"
This reverts commit eddb7c0985e1fac8bdbeaaed40c678c0dc9da321.
Reason for revert: b/36518752
Bug: 36518752
Change-Id: I39773db7b8d02aec360ca80d02b3c161ccf02786
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| eddb7c0985e1fac8bdbeaaed40c678c0dc9da321 |
|
21-Mar-2017 |
Andrii Kulian <akulian@google.com> |
Update display contents when metrics change
There are two separate overrides for display metrics in DisplayManager
and WindowManager:
- In DM - LogicalDisplay#mOverrideDisplayInfo, in most cases not null.
- In WM - DisplayContent#mBaseDisplayWidth/Height/Density, different
from #mInitialDisplayWidth/Height/Density values when some metrics are
forced.
When display was resized its windows weren't updated because of
two problems: old LogicaDisplay#mOverrideDisplayInfo was preventing
WM from detecting the change and override (base) display metrics were
never updated by resize.
When display size changes:
- Before this CL:
DM receives DISPLAY_CHANGED event, it updates internal values.
In most cases there is an override obtained from WM and WM doesn't
get new values from LogicalDisplay#getDisplayInfoLocked().
- With this CL:
DM receives DISPLAY_CHANGED event, it updates internal values and
resets the override received from WM. WM will receive updated values
and will decide whether to apply them or not: if there is no override
in WM - it will apply values from WM, otherwise it will keep the
override. In both cases WM will eventually update its own override
and will update the override in DM.
Bug: 35258051
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testDisplayResize
Test: #testForceDisplayMetrics
Change-Id: I80795434a6a35adb0577fbce334d76fabd2fa03d
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 06d07d6c73f5cf2d7f4975cda4d29870b4f34c3b |
|
14-Mar-2017 |
Andrii Kulian <akulian@google.com> |
Move rotation methods to DisplayContent
This moves some of the rotation logic applied to displays
from WindowManagerService to DisplayContent. No changes in
logic.
Bug: 34242678
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testRotationNotAffectingSecondaryScreen
Test: android.server.cts.ActivityManagerAppConfigurationTests
Change-Id: Ica8b5d700dea82edfc6b51b10be3362fc89854b0
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 8ee7285128c3843401d4c4d0412cd66e86ba49e3 |
|
10-Mar-2017 |
Andrii Kulian <akulian@google.com> |
Move rotation tracking to DisplayContent
This CL moves rotation tracking from WindowManagerService to
DisplayContent. This way displays can be rotated independently and
rotation of the main display won't affect rotation of secondary
ones.
Bug: 34242678
Test: android.server.cts.ActivityManagerDisplayTests
Test: testRotationNotAffectingSecondaryScreen
Change-Id: Ic46aaa523482b31ff5ec77f0c2908ceda1156fc0
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 8e44f6c46822028a853c41610d2289e299987af0 |
|
10-Mar-2017 |
Wale Ogunwale <ogunwale@google.com> |
Revert "Have WM use token info. from IMMS to determine IME target window"
This reverts commit daab865344fcfa45fe2789e43462f730a44fba64.
IMMS is currently sending wrong target candidates, so we need to revert
this until we figure-out what is going on there :(
Bug: 31559891
Bug: 35903813
Test: DisplayContentTests
Change-Id: I5c5beff4bac1b0781fa6663b13ff0dfe83a7806b
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| dee1b3f80c363fa6d3c9e87acd729161bce56c23 |
|
27-Feb-2017 |
Robert Carr <racarr@google.com> |
Only adjust window layers from WindowLayerController
Various animation adjustment logic will directly set mAnimLayer
outside of WindowLayerController. If we end up setting this layer
very high, we can end up moving it above the special windows
collected in WindowLayersController.
Bug: 33702491
Bug: 35396882
Test: bit FrameworksServicesTests:com.android.server.wm.WindowTokenTests
Change-Id: I9850529ecd6f0067bc24421515b39b645885a3ec
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| daab865344fcfa45fe2789e43462f730a44fba64 |
|
24-Feb-2017 |
Wale Ogunwale <ogunwale@google.com> |
Have WM use token info. from IMMS to determine IME target window
Window Manager currently places the IME above the highest window
that can possibly be using the IME. While this method works for
most cases, it does cause some animation jank if the window making
the IME visible is below an other window that could possibly make
the IME visible, but isn't. When this happens the IME is displayed
on-top of which we don't want since the top app isn't making the
IME visible.
We now rely on a strong signal from the input method manager service
WMS.updateInputMethodWindowStatus() to depend which window is actually
using the IME so the window manager can z-order things correctly.
Fixes: 31559891
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
Change-Id: I524aa9dbeb764aac15034a13adf9381304c38fa6
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 2ce1160ed664515db6003ff4622a57c60c4ab22b |
|
22-Feb-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Revert "Update display contents when metrics change""
|
| 6addf5d7094e780498a10a5c761e9089d71dd9c8 |
|
21-Feb-2017 |
Bryce Lee <brycelee@google.com> |
Revert "Update display contents when metrics change"
This reverts commit d7f8f942e56ce96042879c582db1541283c78a3d.
Reason for revert: causing b/35349518
Fixes:35349518
Bug:35258051
Change-Id: I5233bee6696f76313868bb36fd0da4225e5ac038
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 722ba4c7519210a53cebd761a6a565415f4e6307 |
|
14-Feb-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Update display contents when metrics change"
|
| d7f8f942e56ce96042879c582db1541283c78a3d |
|
14-Feb-2017 |
Andrii Kulian <akulian@google.com> |
Update display contents when metrics change
When display was resized its windows weren't updated because of
two problems: old LogicaDisplay#mOverrideDisplayInfo was preventing
WM from detecting the change and base display metrics were never
updated by resize.
Bug: 35258051
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testDisplayResize
Change-Id: I30155e4d83e61ffe969c81dfcf932f3f3882cc59
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| ee9e277033d959211ba733a480355d41a2f32705 |
|
10-Feb-2017 |
David Stevens <stevensd@google.com> |
Handle focused tasks on multiple displays
When the focused task changes displays, make sure to mark the whole
previous display as not part of a focused task.
This change also adds an adb am command to change the task focus.
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testStackFocusSwitchOnTouchEvent
Bug: 35214007
Change-Id: I9cb7372c21a0b592abb6f6d910077ff5097dd6cf
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 5cd907d3d6ceebf8731ef1f69347cce6f76109e9 |
|
26-Jan-2017 |
Wale Ogunwale <ogunwale@google.com> |
Alert Windows behavioral changes
- Introduced TYPE_APPLICATION_OVERLAY window type. Can be used by apps
to display windows on top of other app windows, but below critical
system windows.
- Deprecate alert window types TYPE_PHONE, TYPE_SYSTEM_ALERT,
TYPE_SYSTEM_OVERLAY, TYPE_PRIORITY_PHONE, and TYPE_SYSTEM_ERROR.
Apps should now use TYPE_APP_OVERLAY for this.
- Apps targetting O or greater are not allowed to add the old alert
window types.
Apps targetting less than O can still add the old types.
Apps with permission INTERNAL_SYSTEM_WINDOW (system signature apps) can
still add the old types.
- Z-order old alert windows types below TYPE_APPLICATION_OVERLAY if
they are added by an app without the INTERNAL_SYSTEM_WINDOW permission.
Test: android.server.cts.AlertWindowsTests
Bug: 33256752
Change-Id: I12170955a7a333151d3387c169b51c53c32164fc
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 367ff7fd5251790ad8dc086bd386be8cba1dda5c |
|
26-Jan-2017 |
Andrii Kulian <akulian@google.com> |
Fix shared dim layer not cleared when all users removed
For secondary display, shared fullscreen dim layer user is
the only stack that is present on the display. When this stack
is removed the shared dim layer was not cleared. Because of
that it was crashing when trying to obtain DisplayContent from it.
Now when we're removing a dim layer user we check if we've removed
the last one and clear shared fullscreen dim layer if needed.
Bug: 34367817
Test: bit FrameworksServicesTests:com.android.server.wm.DimLayerControllerTests
Change-Id: I415196a345c491eddd26a55370bb819ce6485151
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 1666e317dc1a17e9435246ec6c8209dbb6ee3696 |
|
16-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added StackWindowContainerController
For linking ActivityStack in AMS to TaskStack window container in WMS.
Change-Id: I8b9eaef49e62854d59b22d27f80f5935a5a4d7fc
Bug: 30060889
Test: bit FrameworksServicesTests:com.android.server.wm.StackWindowContainerControllerTests
Test: bit FrameworksServicesTests:com.android.server.wm.TaskWindowContainerControllerTests
Test: Existing test pass and manual testing.
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 52e85da8fa250502866195c69dd06954daf7aa0c |
|
24-Jan-2017 |
Jorim Jaggi <jjaggi@google.com> |
If the surface of a window is displayed, screenshot
We really really don't care about whether it's actually visible,
onScreen, displayed, winVisible, visibleNow, readyForDisplay or
whatever. The only thing that matters when screenshotting is the
fact whether the surface is shown or not. If it's shown, it must
be good enough for screenshotting. Period.
Test: Go to settings, go to recents, make sure screenshot is taken
all the time.
Bug: 31339431
Change-Id: I5df77ae537b5e70f6cb17e5e18405926135d4312
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 8b702edea1bb211316e1deb3cbe291f2d48d7f77 |
|
20-Jan-2017 |
Jorim Jaggi <jjaggi@google.com> |
Add starting windows while unlocking
- Modify screen capturing logic a bit such that it can also take a
screenshot when the display is off.
- Also take snapshot when app visibility is changing without
proper app transition.
- When unlocking, add strating windows for all visible apps.
Test: Unlock phone.
Test: Have an app that sleeps in onStart, make sure unlocking is
instant.
Bug: 31339431
Change-Id: I953ab6cb30d0d264554fd49a46bdc56e23356d13
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 2899a69295a92d1222a5c75e0f656ea898b03b95 |
|
23-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge changes I72139780,I8e563654
* changes:
Fix screenshotting with includeDecor=true in multi-window
Implement restoring & correct caching of snapshots
|
| bfbd9dc9635fb7518fd34590621f253c2da0eb3a |
|
20-Jan-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix screenshotting with includeDecor=true in multi-window
The old code wasn't really tested and stackBounds variable was
null in any case.
Test: Go to multi-window, go to recents, make sure screenshot is
correct.
Bug: 31339431
Change-Id: I721397800ba7519dba7f569461c5f339eba0591b
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| daca8ee6a5b1c47bea2b61b952d2107bf560e229 |
|
22-Jan-2017 |
Svet Ganov <svetoslavganov@google.com> |
Upstream allowing multiple toasts for focused app
Test:The topic contains CTS tests that pass
Change-Id: I60515845f7c9be23887764bb1c59bf2b3301adc8
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 7cd7c2d333c1b4f77a5b1a9f08cbaaebb242700c |
|
18-Jan-2017 |
Andrii Kulian <akulian@google.com> |
Notify task about display change when moved to new stack
Bug: 34176283
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testMoveTaskBetweenDisplays
Test: bit FrameworksServicesTests:com.android.server.wm.TaskWindowContainerControllerTests
Test: bit FrameworksServicesTests:com.android.server.wm.TaskStackContainersTests
Change-Id: If085246926790089e014a94093d788805e812489
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 9f9d61fd6c16a9750bda19a0d0ebac1209d25ffd |
|
17-Jan-2017 |
Jorim Jaggi <jjaggi@google.com> |
Readd missing null check
Test: adb shell am instrument -w -r
android.test.appsmoke/android.support.test.runner.AndroidJUnitRunner
Change-Id: I8f7c325cf73805ed7137792479f5f348c74f85e4
Fixes: 34333370
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 6a7a85991d38e1e0fc6d33edede5be64e67560c7 |
|
12-Jan-2017 |
Jorim Jaggi <jjaggi@google.com> |
Use screenshotToBuffer
To avoid copying buffers. Yay!
Test: Open app, go to recents, make sure screenshot is showing.
Bug: 31339431
Change-Id: I62736b8ba9ca45155d602286de8280304160bbd6
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 02886a82d876aa5e31a92444fec70208599c509c |
|
06-Dec-2016 |
Jorim Jaggi <jjaggi@google.com> |
Initial implementation of snapshots
All this functionality is hidden behind a flag. If this flag is
active, we disable the regular screenshots.
Instead, we take a screenshot when an app transition for which a
task is disappearing is starting. The screenshot gets stored
into a gralloc buffer. SystemUI uses a new method to retrieve
a snapshot gralloc buffer and then draws it using GraphicBuffer.
createHardwareBitmap().
When starting an existing activity in an existing tasks, or when
bringing an existing tasks to front from recents, we add a new
snapshot starting window. For that, we reuse the existing
starting window, but when creating the window, we use a fake
window that draws the contents of the starting window.
Test: runtest frameworks-services -c
com.android.server.wm.TaskSnapshotControllerTest
Bug: 31339431
Change-Id: If72df07b3e56f30413db5029d0887b8c9665aaf4
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| cd5dcb8b3d7d8b6759232a02c0a5c8ae21e22e33 |
|
04-Jan-2017 |
Andrii Kulian <akulian@google.com> |
Always place stacks below pinned stack
When positioning or adding stacks we must make sure
that no stack is above pinned stack.
Bug: 34049027
Test: runtest frameworks-services -c com.android.server.wm.TaskStackContainersTests
Change-Id: Ic92a4e07e9cde42deed53912ac1419fde4ab2f08
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 6cc1a1d65cd2b9eaeeb82ac3fe62e8dfc6a9eb01 |
|
28-Dec-2016 |
Andrii Kulian <akulian@google.com> |
Fix crash when removing a display with activities
When secondary display is removed current behavior is to
move its stacks to the primary display. This requires app
windows to be reparented, and there was a check missing
for app windows in DisplayContent.reParentWindowToken.
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
Test: #testMoveStackBetweenDisplays
Bug: 33677605
Change-Id: I2ac2cdba273134438c63385887a09c37d42017bb
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| d276563b38907647ce70940e1e90603826df6ab4 |
|
13-Dec-2016 |
Andrii Kulian <akulian@google.com> |
Add positionChildAt method to WindowContainer
Added method to change the position of a child among siblings.
It accepts int value, which can either specify a target position
or POSITION_TOP/POSITION_BOTTOM.
When child is moved to top or bottom, there is an option to also
perform same action on parents. This will effectively move the
entire branch of the hierarchy tree to top/bottom.
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerTests
Test: #testPositionChildAt
Test: #testPositionChildAtIncludeParents
Test: #testPositionChildAtInvalid
Test: bit FrameworksServicesTests:com.android.server.wm.TaskStackContainersTests
Test: bit FrameworksServicesTests:com.android.server.wm.TaskStackTests
Change-Id: I6ade787487055f1c9a305afea64270c243196614
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 6ce0fb8ddbdc726d55c81a4bf797f028e441e448 |
|
13-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed issue with ordering of non-app token windows
We tried to fix this issue in I83357975c87c704af9d0702c939ca99984462365
but the fix introduced other problems. So, we are going to have sys-ui
create a separate binder for object for each type of window it adds.
Long term we want to allow one binder object to map to multiple window
tokens on the same display in window manager.
Change-Id: Iee53b8bf95b87f79ab7a1b574a54111c678f7413
Fixes: 33567674
Fixes: 33538278
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 5d7e7f136e349e6cde86943dd03e7edd9ec92e6e |
|
12-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed window ordering issue with TYPE_VOICE_INTERACTION.
WC.forAllWindows returns windows based on their token order in the
hierarchy and the non-app windows are ordered in the hierarchy based
on their types. For most window tokens their types is specified when
the token is added, but for some others we use the type of the first
window added to the token. This becomes a problem if various window
types are added to the same token (sys-ui I am looking at you...) and
someone adds another token with a window type that should be z-ordered
in-between the windows of the first token.
For now we work around the problem by collecting all the non-app windows
and making sure they are in order before return any window to the caller.
Long term we want to change sys-ui and other callers to use different
window tokens based on the window types they are adding.
Fixes: 33538278
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
Change-Id: I83357975c87c704af9d0702c939ca99984462365
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 1e129a4212ec3b388c65db8f6ce18896362ac35c |
|
21-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Reduce object allocations in WM in some frequently called methods
With the use of lambdas to get all windows in the window container
hierarchy, we need to be careful in frequently called code paths to
make sure the number of objects we allocate isn't crazy. This CL
converts some commonly called code paths that use lambda to use a
method reference for the lambda so we only need to allocate once vs.
each time the code path is executed.
Test: Perform some common operations on the phone and make sure
the object allocations that show-up in Allocator Tracker for
window manager seems reasonable
Change-Id: Ie0f245980de96ec68a4e62e76130db7d98c3f7d9
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 6213caa42d89cc446de4f8f9ba00630f166f23cc |
|
02-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Revert "Revert "WindowList be gone!""
This reverts commit ffa5a9de0c127cb77ddec625fea101ddddb7ad32.
Bug: 33098800
Bug: 33098294
Test: Existing tests pass.
Change-Id: I5803a010c5a224dd1cf452a4a7beb3a4c0a043f4
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 3d0bfd9530bc51c52aec027eaf6d0dba918efc99 |
|
05-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Prevent orphaning of windows when token is removed
When the owner of a window token requests window manager to remove the
token, we were removing it from it's parent which orphaned the token
and all it's windows and prevented them from being accessed from calls
like forAllWindows(). This problem wasn't visible before as the token
windows would still be in the window list, so they can still be accessed
for the exit animation transition which eventually removes them.
We no longer remove tokens from their parent we when are asked to remove
them from the system. We just set WindowToken.setExiting() so the token
can be removed once all its windows are removed at the end of the exit
animation.
Also,
- In AppWindowToken.removeIfPossible() and Task.removeIfPossible(), call
removeImmediately() instead of parent.removeChild() to make sure the
token and its windows are properly clean-up and avoid orphaning if they
aren't.
- Added DisplayContent.reParentWindowToken() for changing the display a
window token is on which is different from DisplayContent.removeWindowToken
which prepares the token and it's windows to be removed from the system.
- Renamed WindowToken.explicit to WindowToken.mPersistOnEmpty which is
what it does.
Fixes: 33098800
Test: bit FrameworksServicesTests:com.android.server.wm.WindowTokenTests
Test: Make sure toast windows don't persist on screen.
Change-Id: I40e0e8832141514b614e79d8e95cd27f24e52366
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 3c1170d849dc0af79623dc0f67eda0fbc66a724f |
|
02-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Have forAllWindows return IME windows in order with IME target
If there is an IME target make sure to return the IME windows next
to the IME target when processing WindowContainer.forAllWindows().
Several users of forAllWindows are expecting this to be the cases so
it is close to the visual order.
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
Test: bit FrameworksServicesTests:com.android.server.wm.WindowLayersControllerTests
Change-Id: I737f88ca607ab2694391419d0d38060c03b53840
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| ca9e061256861a86d7d1c2770c666451d3fb53de |
|
02-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Allow some app windows to display above the IME.
- Display child windows of the current IME target above the IME.
- Display app windows above the current IME target above the IME.
Regression in the functionality was introduce in
I6f8bf15ba246fac69c4a496ebb1d9e0b9b6a95a2 when we switch away from using
the window list for z-ordering and using the hierarchy which has the IME
above all app windows.
Change-Id: I399aab7fd5ad7327ef6bc29d48f6d9bf48a6ac6c
Fixes: 33128382
Test: bit FrameworksServicesTests:com.android.server.wm.WindowLayersControllerTests
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| ffa5a9de0c127cb77ddec625fea101ddddb7ad32 |
|
23-Nov-2016 |
Jorim Jaggi <jjaggi@google.com> |
Revert "WindowList be gone!"
This reverts commit 4551c8bbee4114fa884938dbe90ac0d06ca78fc5.
Reason for revert: Broke a lot of things!
Bug: 33098800
Bug: 33098294
Change-Id: I307b1c7ee39445d6155a4bbce2bf5f289de55285
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 4551c8bbee4114fa884938dbe90ac0d06ca78fc5 |
|
10-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
WindowList be gone!
The use of DisplayContent.mWindow list to track all windows is
no longer needed as we can now get windows through the window
container hierarchy with methods like forAllWindows. The window
list was also a very complicated logic to understand and maintain,
so it won't be missed :)
Bug: 30060889
Test: Existing tests pass
Change-Id: I590cb33aa0f42bcd4a26ddce102f05e657f54144
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 03c403d273e1c265b141504a44da22bae48a4493 |
|
11-Nov-2016 |
Andrii Kulian <akulian@google.com> |
Fix minor issues discovered with Multi-Display tests
- NPE when launching activity on secondary display
and there is a docked stack on primary.
- Activities not finished correctly on secondary display
when it is removed.
Change-Id: If527211e8192088790d32b9673b960535e27033f
Test: See ActivityManagerDisplayTests.
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| f4ebe2e2ccfcbce9de7ad0c3b5399971201f66fd |
|
09-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Removed WallpaperController dependency on WindowList.
WallpaperController now accesses the container hierarchy directly
to determine the state of the wallpaper windows and targets.
Bug: 30060889
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test \
android.server.cts.ActivityManagerTransitionSelectionTests
Change-Id: Ib70beaf340f257ad4e1093cc127f81e7adf41636
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| d1880960581d526cbaed0566d522987d9301b293 |
|
08-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Removed used of DisplayContent.getReadOnlyWindowList()
Changed the call points to use DisplayContent.forAllWindows() to
get windows on the display.
Test: Existing tests pass.
Change-Id: I6f8bf15ba246fac69c4a496ebb1d9e0b9b6a95a2
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| aad0c779f52e14f38ceaa246f4a890a64793c266 |
|
10-Nov-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Catch a missed case when adding a toast"
|
| 200adfbea8103c3c7f5157f6a849b6262b3af88c |
|
18-Oct-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Catch a missed case when adding a toast
We allow a single toast window per UID. It is possible that
the UID had another toast window that is going away and this
CL adds a catch all check as there was a case missing.
Change-Id: I4c68e7212a05ce349e6e5b1cffe6e36d429aaca0
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| b783fd8a0866ad0c18dff333af73e2d49ff2b680 |
|
04-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Traverse window hierarchy without window list
Added support for to get all windows in the hierarchy without needing
to use WindowList concept which is a very complicated implementation
in the code base.
This implementation walks the hierarchy node by node returns windows
in order to the caller using a callback.
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
Change-Id: I2719f7c96f26dad23f91c1c589be88712bd224b8
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| cb291f38f8aa1517ca66c7331765becb47442edd |
|
04-Nov-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Add shell command to move activity stacks between displays"
|
| 839def9b549b6279aabd4150b304999e58d15762 |
|
02-Nov-2016 |
Andrii Kulian <akulian@google.com> |
Add shell command to move activity stacks between displays
Also rename "stack movetask" command to be consistent with other
shell commands.
Test: New CTS tests coming soon.
Change-Id: I3d7e04e0ae8ea76c27c3e4c1e286d5cd4539870c
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 3a9316945432d79eebd08b7122b2222a1983d8a9 |
|
03-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Order non-app window containers.
- Add non-app window tokens to the display child container based on
their base layer so the highest based layer is z-ordered on-top.
- Separated DisplayContent.mNonAppWindowContainers into
mAboveAppWindowContainer and mBelowAppWindowContainer where the former
contains non-app windows that should be z-ordered on-top of all app
windows and the later contains non-app windows that should be
z-ordered below app windows.
- Change wallpaper base layer to 1 so that it is always below all other
window types.
- Add Ime related windows/tokens to DisplayContent.mImeWindowContainers
so that we can track them together
- Use alternative binder token when adding window TYPE_INPUT_METHOD_DIALOG
so that it can properly be associated as an IME token in WM vs. with
system_server or sys-ui token.
Test: Existing tests pass.
Bug: 30060889
Change-Id: Ib53e09af12545868c3741d83aaccb7311c872b41
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| ad5d2846432b38a89df8d3fa7062f761a7c9abd8 |
|
02-Nov-2016 |
Jorim Jaggi <jjaggi@google.com> |
Cleanup dumpstate for CTS tests
Change-Id: Iefd7f2863b1a2d8974d0cd1c27b1d3b2d3ffbe8e
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| ac2561e8206ac42921bb6ddbb0a5972fb360e394 |
|
01-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Make window token add/remove APIs require displayId
Window tokens can now only be on one display, so we now require clients
that want to add/remove window tokens to specify the display they would
like the token to be created on. This simplifies the token handling code
in WM and will be useful moving forward for clients that want to add
windows to external displays.
Test: Existing tests pass
Change-Id: I6b2d8d58a913b3624f1a9a7bebbb99315613f103
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| fe762344f4475a3a336bb46aef2d59c1fabf32ab |
|
13-Oct-2016 |
Jorim Jaggi <jjaggi@google.com> |
The big keyguard transition refactor (1/n)
The heart of this change are two things:
1) Instead of using the force hide mechanism to hide windows behind
Keyguard, we actually make the activities invisible in activity manager.
2) When Keyguard is going away, we change the visibilities in activity
manager and run an app transition.
At the very core we move the responsibility of hiding activities to
ActivityStack, which checks whether Keyguard is showing, and then
hides all non-show-when-locked activities. For that, we need to check
whether any window of an activity has SHOW_WHEN_LOCKED set. We
introduce a callback from WM -> AM in case these Keyguard flags have
changed.
Furthermore, we decide whether to occlude Keyguard in KeyguardController,
which just checks whether the top activity has SHOW_WHEN_LOCKED set. When
this state changes, we prepare an occlude/unocclude app transition, and
in PWM we just inform the Keyguard about the animation so SysUI can play
along this animations in a mostly synchronized manner.
Since we now use an app transition when unlocking the phone, we get
lockscreen launch animations for free - window manager automatically
waits until the activity is drawn, or directly executes the transition
if there is nothing to animate. Thus, we can remove all the infrastructure
around "waitingForActivityDrawn".
The logic to show/hide non-app windows is moved to policy, and we add the
ability to run animations on non-app windows when executing an app
transition.
Test:
1) runtest frameworks-services -c com.android.server.wm.AppTransitionTests
2) Manually test unlocking Keyguard:
2a) Without security
2b) With security
2c) With security but trusted
2d) Portrait while activity behind is in landscape
3) Test launching things from Keyguard
3a) Without security
3b) With security
3c) Launch camera without security
3d) Launch camera with security
3e) Launch camera with securtiy and trusted
3f) Launch voice affordance
4) Set no notifications on lockscreen, drag down, make sure you get
the correct animation
5) Test clicking "emergency" on bouncer
5b) Test "Emergency info" on emergency dialer
5c) Test clicking edit button on emergency info, should show pattern on
Keyguard
Bug: 32057734
Change-Id: Icada03cca74d6a612c1f988845f4d4f601087558
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| b17e86940ef86000f07b58b878f82533cfafd015 |
|
01-Nov-2016 |
Andrii Kulian <akulian@google.com> |
Update SEND_CONFIGURATION message to use displayId param
Probably this piece was lost somewhere in merges.
The param was added in ag/1551198
Test: Existing and manual tests still pass.
Change-Id: I2dbc533361b9a821a952511e469a99df230d45cf
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 423af758c91a25ce99cd3387009d53e19b4423a3 |
|
31-Oct-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Introduced ReadOnlyWindowList"
|
| 655332c641ccb12ee1ae3ce89135ca847fba1abf |
|
31-Oct-2016 |
Winson Chung <winsonc@google.com> |
Creating PinnedStackController.
- Creating a PinnedStackController to keep track of the state of the PIP
to prevent changes in the system (ie. IME showing) and user interaction
from clobbering each other.
- Refactoring calls in AM into WM/controller
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: Ie59dfd45d5c54764ba69a589b3b8148845e92cc3
Signed-off-by: Winson Chung <winsonc@google.com>
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| f7cab10b796d0f66eb690867ba327b4bb00165e3 |
|
26-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Introduced ReadOnlyWindowList
7th and Final step in making the modification of a display's
WindowList private to DisplayContent.
ReadOnlyWindowList provides an interface for external classes to
DisplayContent to access the window list without being able to
modify it. This will be important in upcoming CLs where it is
important for us to keep track of when the window list changes.
Bug: 30060889
Test: Manual testing and existing tests pass.
Change-Id: I4de0b258a40fd4b21ef9cc9e3401488f76d25f83
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 07bcab787ea7ce65081dffe7da196f872a1be37a |
|
15-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Add windows to window tokens in expected z-order
Decouple the logic for adding window to a position in the parent
window token from the position we are adding the window to in the
window list. The window token now adds the windows in order based
on the rules the rest of the system is using which makes the code
a little more straightforward to follow.
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowTokenTests
Change-Id: Ic9b724fba02279a0c4e92508d39e5e35171b6d8d
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 7156b650f0d57522ebde67cebd201b339e08cf8e |
|
25-Oct-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix background animator not resetting
Test: Set wallpaper, make sure screen is not black.
Change-Id: I4031375e0892906a4e4085ce05664191a55bfb4e
Fixes: 32375010
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 494009b8e3d6c2751d0c6983f24b56971f6bdf9d |
|
21-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Removed WMS.getDefaultWindowListLocked()
6th step in trying to make the WindowList private to DisplayContent.
The method was another an indirect way to the the window list
from the display content.
Test: Manual testing and existing tests pass.
Change-Id: I26de316b8c20dd891a214fb40ef3991a0e895442
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| e6f806e4fa5c73d6cd6334f6aafa4c7688fd3aca |
|
21-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Moved display related getting of orientation into DisplayContent
5th step in trying to make WindowList private to DisplayContent.
Exact code to get orientation in WMS that is display specific
because it iterates over the window list into the DisplayContent
object.
Test: Manual testing and exiting test pass.
Change-Id: Iced72322cdebdde83882802af4a9decf323f20e1
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 0303c5723edfdb4f2db37543544d7cbe9b14df97 |
|
20-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Have DisplayContent be the call point for adjusting wallpaper windows
4th step in trying to make the WindowList private to DisplayContent
Have the rest of the system call DisplayContent when they need to
adjust the position of the wallpaper windows in the window list
instead of calling WallpaperController directly. That way the display
content can control the window list that the wallpaper controller sees.
Test: Existing tests pass and manual testing.
Change-Id: Iaa7f421d7cd24d36e5a83e091f77b4a08d0ae123
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 824ab5c4be2a3c3f7240178438126567d00bddec |
|
20-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Removed WindowManagerService.getWindowListLocked()
3rd step in trying to make the WindowList private to DisplayContent.
The method was another an indirect way to the the window list
from the display content.
Test: Manual testing and existing tests pass.
Change-Id: Ifb0548a91b5bc64461e14f63256b61b8fa5e2e0c
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| ae9adbfb758712caaf11b4ba5c5fd15848dcc3c5 |
|
19-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Removed WindowState.getWindowList()
2nd step in trying to make the WindowList private to DisplayContent.
WindowState.getWindowList() was an indirect way to the the window list
from the display content.
Test: Manual testing and existing tests pass.
Change-Id: I634ed446661371e70b99c701c23e1bdd59ada0bc
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| c69694abbdbfa3f0bedb034e7cc86823a72ff781 |
|
18-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Have DisplayContent be the call point for assigning window layers
First step in trying to make the WindowList private to DisplayContent
Have the rest of the system call DisplayContent when they need to
assign layers to windows instead of calling WindowLayersController
directly. That way all the various call points don't need to get
the WindowList from DisplayContent to pass on to WindowLayersController.
Test: Existing tests pass.
Change-Id: If869abf7ba1c33b575908006ae5ad1557abc361c
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 860297b91a1f2bb7acd36c943cbdb93d4547fc65 |
|
18-Oct-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Clean up use of DisplayContent from WindowState."
|
| b0f3b836b9fe98d395fdbadf2cdd3603f4e0145a |
|
17-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Clean up use of DisplayContent from WindowState.
Follow up to ag/1483993 where WindowTokens can now only be on one display.
Clean-up some existing code that dealt with having WindowTokens on
multiple displays.
Test: Existing tests pass.
Change-Id: Ie908eda37bc44097dea773b0fc163d35cc9baf35
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 601a3f085eebc55968805b585906a3e8bad4c3ef |
|
17-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Allow DisplayContent children to be removed on display removal
DisplayContent has direct children that we treat as permanent and as
such we don't allow them to be removed. However, this causes an issue
when removing the display as all children of the display are expected
to be removed at that point.
We now allow the removal of the chilren when the display is being removed
and still disallow it in all other cases.
Bug: 32193212
Test: cts-tradefed run commandAndExit cts-dev -m CtsDisplayTestCases
Change-Id: I9a2eeb2418311a9c5931797ab7a831deead3781e
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| b9a07c3e59ea47377110ce00a0fd43047d411969 |
|
12-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed issue with IME window not been added to its window token
This looks like a coding error that has always existed. The window
was added to the display window list, but not to its window token.
The issue was exposed by the switch to using the window container
hierarchy since the window was not a child of the token it wasn't
showing up in the hierarchy.
Test: Run 'adb shell dumpsys window containers' and make use the
InputMethod window shows up in the print-out.
Change-Id: I43cb5d6b3f266c1be54dd27def4c13e1ef98a4fa
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 19e452eabd66c4a72e31dbc085927776fcf8bf3a |
|
12-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added non-app window tokens to window container hierarchy
WindowContainer only allows its sub-classes to have homogenerous
children, however DisplayContent needs to have app window containers
that are managed by TaskStack and non-app window containers that are
managed by WindowToken. To do this we create a pass through class
DisplayChildWindowContainer that any container that wants to be a child
of DisplayContent needs to inherit from. Then, we can have DisplayContent
contain DisplayChildWindowContainer types and have sub-class children
like TaskStackContainers and NonAppWindowContainers
Bug: 30060889
Test: Existing tests pass.
Change-Id: I3848958eddcd51030cfe20bb1337476d203bbed3
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| d2753b5478690db844d33f774bbbf290731aaa4a |
|
13-Oct-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix bounds rotation logic"
|
| 4dfb9c4bbb014ac4625dcae419b212d00f541ef0 |
|
12-Oct-2016 |
Andrii Kulian <akulian@google.com> |
Fix bounds rotation logic
Reuse code that computes window bounds for seamless rotation in
DisplayContent#rotateBounds. Also make sure that we operate with
display rect adjusted for the requested orientation.
Bug: 31005451
Bug: 29586417
Test: Tests in ActivityManagerAppConfigurationTests pass.
Change-Id: I921ec184c9eaad6dbd15ac3e0def1f5e623a363e
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 360a8bce7386dc9b231c698af1730e04362b6c2e |
|
10-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Switch WindowState to get display content from its window token
WindowState no longer needs to track what display it is on now
that the window token can only be on one display.
Test: Existing tests pass.
Change-Id: Ia0530d73da0b1ecc17f596ec62c933637bd1c2c3
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 02319a61927041cc4d3632e94c501b7277f0bda5 |
|
27-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Associate WindowToken object with only one display at a time
WindowTokens were global objects that contained windows that could
be on multiple displays. This model does not work with the
WindowContainer hierarachy as children (window tokens) can not have
mulitple parents (displays).
We now:
- Track the mapping of binder tokens to window tokens per display
instead of globally . So, you can have a binder token map to
individual WindowToken objects per display.
- WMS.addWindowToken is used to create a WindowToken that clients
can then later add windows to. However, when addWindowToken is called
we don't know the display the client(s) would like to add window to.
So, we track binder tokens that we are allowed to add window for in
the RootWindowContainer and create a window token for the binder on
a specific display when we try to add a window.
Bug: 30060889
Test: Manual testing and existing tests pass.
Change-Id: I81a52a32b01c33ed32169d2da0506b688ea9bc8a
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| d4a00a027265e5abfae335e38bd17fd744e3a2c3 |
|
10-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Cleaned-up some code in WindowManager
This CL has no functional changes and I am just breaking this change
out of another large CL I am working on.
Test: existing tests pass.
Change-Id: I4c93e2b1820dc31ba28f81692f2f8f6081e1f315
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 9d9d8f1c0f66172d89e50e8fd12a8c2a3de221ac |
|
29-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Cleaned-up RootWindowContainer.applySurfaceChangesTransaction
- Move functionality for determining interesting and all drawn states
of an app token based on the current window we are processing into
AppWindowToken.updateDrawnWindowStates() since it is mostly touching
AppWindowToken variables. Some of the fields can now be made private.
- Removed WindowContainer.updateAllDrawn() and related overrides. We
now have RootWindowContainer collect the app tokens that need to be
processed and call them directly.
- Move code to report window move to client into
WindowState.reportWindowMovedIfNeeded().
- Move WMS.updateResizingWindows() functionality to
WindowState.updateResizingWindow() as it mostly updates window state
internals.
Bug: 31794753
Test: Manual testing and existing unit tests pass.
Change-Id: I7588217d05d3e8971ce61795cb8568d835779c5e
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 834bbbd753b73e7a84403910cab9e27f688b74a8 |
|
30-Sep-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Add override and merged config to WindowContainer"
|
| 441e4494682144aec2ec7f19060464af3d29c319 |
|
30-Sep-2016 |
Andrii Kulian <akulian@google.com> |
Add override and merged config to WindowContainer
This consolidates usages of override and full (merged)
configs in WM objects and also adds support of per-display
configurations. Having full configs allows us to get
current applied config at any level.
Test: Manual tests pass. Added some new to WindowContainerTests.
Change-Id: I996770433c80da41265f3e14048bd23cead097f9
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 2ffb542254ae13fc0edd617f93c73f87c2160860 |
|
29-Sep-2016 |
Svet Ganov <svetoslavganov@google.com> |
Add a missing case when detecting if a toast can be added am: 62a40f87b3 am: 49dcc90734
am: 3f16f11e81
Change-Id: I66c2208be0b5fa9ea0fe14dc368d25a964b16601
|
| 2b06bfc6e90aa293c7058fc6b1d1cf22fbb2ada2 |
|
28-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made DisplayContent.mLayoutNeeded private scoped.
And, added accessor methods for it to make it easier to
debug who is setting it.
Bug: 31794753
Test: Existing tests pass.
Change-Id: I517c3e5cc7535cb90c47c112d42fa1dbf0b81583
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 62a40f87b3f45cbd20fea101d977153e9a933891 |
|
29-Sep-2016 |
Svet Ganov <svetoslavganov@google.com> |
Add a missing case when detecting if a toast can be added
We allow only one toast window per UID to be added at a
time. We ignore windows that run exit animation but we
should also ignore windows that should be removed after
the exit animation.
bug:31340854
Change-Id: I51c21f2c0e04341697f61e4cc107f9116254b206
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| a77e146aef0fd3956d6860bba74c55b4d53402f7 |
|
28-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Use last orientation if contents of a display wants behind orientation
Default to using the last orientation set if the contents of a display
specifies to use the orientation behind.
Bug: 31791145
Test: Manual testing
- Launch caluculator and put phone in landscape mode
- Press the Recents button
- Make sure Recents activity is in landscape orientation
Change-Id: I008335bf4a458761fc6a42008ec93e632a3fba60
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| ba51ca2c8c100ccd5f1bb7a5f34f674b12184399 |
|
23-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed some test failure and log warnings.
- Make DisplayContent.attachStack and moveStack use the same code
path for adding child stack so they both account for the presence
of pinnded stack.
- Don't call DC.attachStack on a stack that is already on the
display. Use DC.removeStack instead to just make sure it is at the
right z-order on the display.
- Use WindowContainer.getName() when for exception messages to have
a more concise print-out for the error.
- Only try to remove a task from a stack when positioning if the task
is contained in the stack.
- Throw an exception if we try to remove a task that isn't contained
in a stack.
- Skip checking of exiting or waiting for replacement when rebuilding
window list for app tokens that are exiting.
- Properly display and intent output from WC.dumpChildrenNames().
- Have DisplayContent WindowContainer type always return true for
fillsParent() and isVisible() as displays always fill their parent
and always visible for now.
Bug: 31624623
Test: Failing test passes.
Change-Id: I8a84770feb1fd278716755cdec2900fddb9940de
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| eaabfabd84bda2975ef5bb9a9bff6d10c328913c |
|
17-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Switched RootWindowContainer to use WindowContainer.
This completes the first pass of defining a hierarchy in
window manager :)
WindowManagerService is now less than 10,000 line \o/
Bug: 30060889
Test: Manual testing and existing tests still pass.
Change-Id: Ib349220e9355d1894bd62294e7696827f033887f
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| e05f5014905569d69d33ff323a3c62c046552789 |
|
17-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added RootWindowContainer
RootWindowContainer will be the root/head of the window hierarchy.
Also, moved all access of DisplayContent into RootWindowContainer.
Bug: 30060889
Test: Manual testing and existing tests still pass.
Change-Id: Icdf80a4c053578fb91221e6f2b672e197054a6bf
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 1012458343643e899ed8ca2684380b92d73fb47b |
|
16-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Switched DisplayContent to use WindowContainer
Bug: 30060889
Test: Manual testing and existing tests still pass.
Change-Id: I99f2e38da417f62e8aa65bb6582aba53fd528c1b
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 3a507b5da984efc6fa895e30b770a44f65a07d34 |
|
20-Sep-2016 |
Andrii Kulian <akulian@google.com> |
Extract global configuration update
- Separated config update in AM into several methods.
- Updated global config update in WM to reconfigure and
notify all displays.
- Removed redundant list of displays that are waiting for
configuration update.
Test: Manual testing and existing tests still pass.
Change-Id: I60d3013301267bd668348565dcd0a68e09023a0e
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| c463e06ede4671043bf8fe800566adbcf43aa6c1 |
|
19-Sep-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge changes Idcc4cdd4,I75add6a9,I2aeda867,I1ff912c4
* changes:
WindowManager: Include sigil in RemoteSurfaceTrace format.
Pass SurfaceTrace through WM command in binary format.
Log transaction state to RemoteSurfaceTrace.
WindowManager RemoteSurfaceTrace infrastructure
|
| 14a3fb98e5ec5f366e810ad4d1f2a73ef8407ac6 |
|
12-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Switched TaskStack to use WindowContainer
Bug: 30060889
Test: Manual testing and existing tests still pass.
Change-Id: Id29c4aaf6580623a748bd69316fc6a4663ff1d37
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 3b716249cc2f94aa9842576b618998c28593be90 |
|
17-Aug-2016 |
Robert Carr <racarr@google.com> |
WindowManager RemoteSurfaceTrace infrastructure
Add "wm surface-trace" command which enables tracing of surface
commands to be switched on at runtime. Primarily intended for use
by WM CTS tests. First target in CTS will be to use show/hide
events to eliminate polling in WM tests and increase speed. Next up
looking at things like verifying various transitions and relaunch
scenarios are flicker free. Later we may want to look at a smarter
or more structured format...but it's really not much hassle to parse
the commands off a pipe so I wanted to get us started.
Test: cts-tradefed run singleCommand cts -o --module CtsWindowManagerHostTestCases --test android.server.cts.SurfaceViewMovementTests#testSurfaceMovesWithParent
Change-Id: I1ff912c405a6cb9996ee9b6e2c465d57706191ba
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| f6192868fa4fcf85130ef40a90d0c96fbbca761d |
|
10-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Switched Task to use WindowContainer
Bug: 30060889
Test: Manual testing and existing tests still pass.
Change-Id: Ia56767e47ad3df400e3aa2650f6386cca14659a7
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 828882a2da9c56c8a983b00da5d9902722aab7ea |
|
17-Sep-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Configuration renaming and minor cleanup in AM and WM"
|
| 8072d11f6a41a68600a15623ca5316ca0def1856 |
|
16-Sep-2016 |
Andrii Kulian <akulian@google.com> |
Configuration renaming and minor cleanup in AM and WM
- Configuration members in AM and WM are renamed to
mGlobalConfiguration.
- Renamed parameters names in some methods to better represent
their meaning.
- Added and fixed some docs.
Change-Id: Ie51f687fe4c10dbce776435f29d6b853fda50eec
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 3f4433dadb7627153939ebb7d88d080c132b7f7f |
|
19-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made Task.mAppTokens private scoped
Also, remove TaskStack.getTask() method.
Bug: 30060889
Change-Id: I1ed9710ff630b390d28e6f2146db4202e2bc860b
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 9adfe5776d42c9ddfd4394958993304c9d355229 |
|
09-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Moved rebuilding of display WindowList to DisplayContent
Some of this is also in WindowContainer and its children.
However, I hope we can remove the concept of window list in
the future.
Bug: 30060889
Change-Id: I9e531327643c28a0ba35baa812b9c2942993d7b7
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| ec73115b0902f5ffe3a0d9dcdd51badc4a99bc0a |
|
09-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Moved adding to display WindowList to DisplayContent
In prep. for using WindowContainer.
Bug: 30060889
Change-Id: Ife8e03b53ce89f5b932f765850d072194d49fcb3
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 63d4ecc7a5c23f1ebbd3d71e5054041d90df9762 |
|
09-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Moved window focus calculation to DisplayContent
In prep. for using WindowContainer.
Bug: 30060889
Change-Id: Ide3022b3129b3d190f631a07d7589a27c434e0c3
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 5136249a7147fb205e1b861c1d42a7d1f13b73cc |
|
09-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Support for specifying orientation in WindowContainer
Also,
- Fixed failing tests when they are ran as a package vs.
individual classes due to multiple window manager instance.
- Correct some isVisible logic to so a window container that
is invisible is not said to be visible, because one of its
children is visible.
Bug: 30060889
Change-Id: I1bb8730361be2a9f5ce88cd59b7d57d5a459bde6
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 15ead903c69b043eeb44fc627929d4919e985df3 |
|
02-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Some code clean-up in WindowManager.
- Renamed DisplayContent.findTaskForControlPoint to
DisplayContent.findTaskForResizePoint as it is trying to find a task
from the resize point.
- Renamed DisplayContent.checkForDeferredActions to
DisplayContent.onCompleteDeferredRemoval as the method removes containers
whose removal were deferred.
- Added methods TaskStack.hasMultipleTaskWithHomeTaskNotTop() and
topTaskIsOnTopLauncher()
- And some other minor clean-up relating to me trying to break-up a big CL.
Change-Id: I64d03cbd9ee69bf8fa0013a49283cd434b7c8fbe
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 94cee2b6125db6cc47e210c9dd45906d6a7c4382 |
|
06-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Added WindowContainer.removeImmediately to support immediate removal"
|
| 71c510236c92c14efae6ff00e68cf9ad38f51c32 |
|
03-Sep-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
resolve merge conflicts of bde1d34 to master
Change-Id: Id3cef32bb97cfe8483001e71207b65bc0bc6e304
|
| aa07653d2eea38a7a5bda5944c8a353586916ae9 |
|
02-Aug-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Prevent apps to overlay other apps via toast windows
It was possible for apps to put toast type windows
that overlay other apps which toast winodws aren't
removed after a timeout.
Now for apps targeting SDK greater than N MR1 to add a
toast window one needs to have a special token. The token
is added by the notificatoion manager service only for
the lifetime of the shown toast and is then removed
including all windows associated with this token. This
prevents apps to add arbitrary toast windows.
Since legacy apps may rely on the ability to directly
add toasts we mitigate by allowing these apps to still
add such windows for unlimited duration if this app is
the currently focused one, i.e. the user interacts with
it then it can overlay itself, otherwise we make sure
these toast windows are removed after a timeout like
a toast would be.
We don't allow more that one toast window per UID being
added at a time which prevents 1) legacy apps to put the
same toast after a timeout to go around our new policy
of hiding toasts after a while; 2) modern apps to reuse
the passed token to add more than one window; Note that
the notification manager shows toasts one at a time.
bug:30150688
Change-Id: Ia1dae626bd9e22541be46edb072aa288eb1ae414
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 571771c3fc912e63f83b75693c0f3c85ec9622da |
|
26-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added WindowContainer.removeImmediately to support immediate removal
There are 2 types of window conatiner removals. The ones that happen
immediately and the ones that are deferred until the system is in
a good state to handle them. WindowContainer and its child classes
now support both through WC.removeImmediately() and WC.removeIfPossible()
methods.
The method names create a consistency in the codebase and also makes is
obvious what the methods will do.
Bug: 30060889
Change-Id: I459c2eef17e20cefc42e9cc542c9a3c69fc9b898
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| d1c3791659572529dbc749b70d1c33bda1bdbc32 |
|
16-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Switched WindowToken/AppWindowToken to use WindowContainer
Bug: 30060889
Change-Id: Ia82aedfd9ea86410acdcd3a55a7a7fc456be2fc3
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 32cbdcc8c098b4a42212b3da345b929abad8ad6e |
|
31-Aug-2016 |
Jorim Jaggi <jjaggi@google.com> |
resolve merge conflicts of c5bafe2 to master
Change-Id: I19dd5c88c664313c2f8b47d8f8fd556f630c8bf1
|
| 83ff4b54b2ece5d85a443ea8c7ed885e65d2009a |
|
31-Aug-2016 |
Jorim Jaggi <jjaggi@google.com> |
resolve merge conflicts of d33f893 to master
Change-Id: I5851917387af16425f6c4c633931ba75937ffb26
|
| 6626f54e658e3da44fab8a5cd6d9d3d4852e2cd1 |
|
22-Aug-2016 |
Jorim Jaggi <jjaggi@google.com> |
Add animation when unoccluding windows (1/2)
Before there was a jump-cut when a window that was occluding Keyguard
was going away, leading to an ugly flicker. To fix this, we do the
following.
- Always show windows with FLAG_SHOW_WHEN_LOCKED above lockscreen, even
if they don't "match" the currently occluding app (which is null in the
animation case)
- Move wallpaper behind last window that is not hidden by policy, so the
window doesn't get occluded by the wallpaper.
- Add a flag in the setOccluded call whether to animate or not. SystemUI
then plays a nice animation when it's set.
- Override the animation to always be the animation that happens when we
exit a window which is revealing the wallpaper behind, to make it
consistent with the home screen case.
Fixes: 30829255
Change-Id: Ib3fe20fc9003a0f9f291c974740f044ed8707e75
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 160a3c578c5cbbe31f3dbb51fc0a78ee6d80c5cd |
|
26-Aug-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix invalid divider state while rotating
- Sometimes there is no window attached to the app token during a
rotation. In this case, we also want to return a valid dock side, so
we check for hiddenRequested instead of traversing the windows
of an app window token.
- The logic to notify SystemUI about rotation changes never really
worked. Remove the dock side check as the dock side is guaranteed
to change if we change the screen rotation
- Also clean up visibility methods a bit.
Test: Manually tested the interaction when in docked state landscape,
and going home with locked home rotation like 20 times. Also tested
multi-user interaction with docking.
Change-Id: Ibcd181cadc9bc5a97dbd20e67d15bb1c88de5b97
Fixes: 29569499
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 4825b680f6ca934dc178613c9361a68aa29950e2 |
|
05-Aug-2016 |
Chong Zhang <chz@google.com> |
Fix WM missing stack/task when activity is force stopped and restarted am: d9d35bdfcf am: c35df3de2f
am: a7250e4291
Change-Id: I64e75a8d48088e7a2e8fe90992e2feb80eb478a4
|
| d9d35bdfcf0e18ae16c0f59290b860700fb6e62f |
|
05-Aug-2016 |
Chong Zhang <chz@google.com> |
Fix WM missing stack/task when activity is force stopped and restarted
When activity process is force-stopped (like in the case we need to stop
it to allow debugger), activity record is removed and a new instance is
added. Depending on timing, adding of new record could happen before
or after old record is removed. If it added after old record is removed,
then the removal could cause AM to also remove the task AND the stack
(if the activity is the last one).
On WM side however, the task/stack removal could be delayed due to
animation. So when AM attaches a new stack, we end up with two stacks
with the same stack id in the DisplayContent. Also, AM reuses the last
used taskId after it's deleted. So WM is confused and didn't add a new
task record. Then when the delayed stack removal fires everything is gone.
We need to use a different task id when creating a new task record, even
if the last created task is already deleted. Also when attaching a new
stack to WM, first check if we already have such a stack in DisplayContent,
if so, reattach it and don't create a duplicate.
bug: 30465601
Change-Id: Ic399a32c54f6acdcbb9a0c6155599331d55df232
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 4ce896ca7afb2d32e58f340856d077491be23016 |
|
19-Jul-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Added foundation for supporting unit tests in WindowManager"
|
| b699ce0d06eb6be91c0be0a791d8d8d7c68b4f41 |
|
18-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added foundation for supporting unit tests in WindowManager
- Check for null where appropriate when using WM from a test
- Inject WindowManagerPolicy for test can have its own policy
- Added skeleton for WindowStateTests that will contain tests
for WindowState class.
Bug: 30060889
Change-Id: I0cd7d50c98de16c7412759401075c4bb48d13dfe
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 2e2c81a8d67f6ceccf178c5c7264d27e8c72e9ff |
|
15-Jul-2016 |
Chong Zhang <chz@google.com> |
Remove two-finger scroll specific code
Revert changes in ag/845161, ag/843943 and ag/817515 that's added
specifically for two-finger scroll mode.
Change-Id: I8679a3bd5b3907180d33d99e3a071e7edfb2ed96
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| e4dd96453179d9f5449fe33c6aa4b909ba440f5b |
|
10-May-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed logic error when calculating window touch exclude region.
Problem was introduced in ag/960365. We need to properly set the
temp variable to the current task bounds before trying to use it.
Bug: 26962445
Change-Id: I3cded03582e1379e16fa48f69da6ceadb92d8d4b
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 31f71705df97767b4b4ac7026228664995478fe0 |
|
05-May-2016 |
Jorim Jaggi <jjaggi@google.com> |
Add dump information for divider
Bug: 28575870
Bug: 28445644
Change-Id: Ib2137c49f1672ed2a9e7e31a5b68c22e0bb166b1
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 9e76d3292b34c8683b549cc1f56bfff288defb92 |
|
22-Apr-2016 |
Robert Carr <racarr@google.com> |
Touch region fixes for dialogs and overlapping tasks.
There were two errors. First the function assumes that there are only
overlapping tasks in the case of freeform, and so otherwise it is not
necessary to union the focused task back at the end (and we can just
subtract all the non focused tasks). This won't work though, as there
can be for example dialogs over the launcher from another task. We
need to always add back the focused task. Secondly, we were requiring a
task to have a top visible "main app window" e.g. TYPE_APPLICATION or
TYPE_APPLICATION_STARTING. For tasks whose only presence on screen
is a dialog this will skip them and we will ignore them one way
or another.
Bug: 26962445
Change-Id: Idd5c54082409e7c34d9fc7480908c88fb12b378b
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| b72c9ad721e5ff5b9d5a45ca4ba2608940815388 |
|
12-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
No input for windows in minimized docked stack
Also make them unfocusable, and don't focus the docked
stack when tapping into it in that state.
Bug: 27972642
Change-Id: Ic24ff9a5f39f596fe4a2f50567566d4400f9c125
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 7f19cb870cb98da3366d21c609f2f53755860351 |
|
26-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix touch exclude region for divider handle
Bug: 27854148
Change-Id: I93421d07b2be29846be4748a3be3b89b9b465613
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| d47e7e1176dcf6961c7c9fce215f48f03a5098d1 |
|
01-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Add ability to swap docked/fullscreen stack
Adds tap affordance that moves all tasks of the docked
stack into the fullscreen stack as well as moves the top task
of the fullscreen stack into the docked stack.
Also make sure not to trigger focus switch when tapping the divider
handle. For that, add a method so SysUI can specify the touchable
region which then gets excludes for the focus switch touch region.
Bug: 27358134
Change-Id: I34f39c53cacc0b9c00f87a792b88c3f64a5f61e1
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.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/DisplayContent.java
|
| 5d6bdebfeed73ab5efff03c451b3ff7460935d00 |
|
13-Feb-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Move more drag-related code to DragState
Pure refactoring: moving the code manipulating
DragState member variable into DragState.
Change-Id: I1f9feff32c8b18ae0ff451030d026d4276fecd5b
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.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/DisplayContent.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/DisplayContent.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/DisplayContent.java
|
| ecf672288b7e2eac58e390e24c1454b56f9e2b8c |
|
12-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Exclude status and nav bar from focus monitor.
Bug: 26037712
Change-Id: Ie1cd442339f6d7e95ac949eb59b5da9a7a13559b
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.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/DisplayContent.java
|
| 114d5ca711775a632b1d2d4ec6c00eddff1bc776 |
|
04-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Put PIP windows above transition animations.
PIP activities are already on top of everything else, but during
animation we increase the layer of the animated window for the duration
of the animation and it may cover the PIP. By forcing the same
adjustment on PIP windows we will keep them above animating windows.
Bug: 26015827
Change-Id: I8f7a87f41fed24b3e520fb599a94cf24cc2eeb50
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 912d919772b284af0d17160b104902c45bfafa63 |
|
02-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Add input method to the tap detection exclude area.
Without this touch events on the input method will trigger focus change
if there is a window underneath the input. When focus changes, the input
method will go away too.
Bug: 25930832
Change-Id: I532cb9e78f6fe37b1ddfada75594fc695898a090
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 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/DisplayContent.java
|
| f52dd205b9d31e0edcfdfff4ed98259c07ca38b7 |
|
16-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Don't animate move triggered by resizing using dock divider.
Also includes some small, nice refactoring:
* move code that sets the move animation into WindowStateAnimator;
* a few fields can be made private in WindowStateAnimator this way;
* one boolean flag in WindowStateAnimator popped out as unused after
being privatized, so could be deleted.
Bug: 25690109
Change-Id: I8144114244892c4f27aff21455e8e76eddbd039f
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 608797e210dae48d4b9ece8aeaaa3293ecf066dd |
|
13-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Remove unnecessary DisplayContent.mDisplaySizeLock synchronization.
All operations are performed with WindowManagerService.mWindowMap lock
held, therefore the second lock is not necessary.
Change-Id: I762fb322ddeb8b45191a3d297de0d33a10674f8a
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.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/DisplayContent.java
|
| 4c9ba52acad52f1c1087415e04b2a17614707e40 |
|
11-Nov-2015 |
Chong Zhang <chz@google.com> |
Fixes for dim bounds and touch bounds
- Change dimming and touch related usage to use task's "max visible
bounds", which is the app within a task that's covering the maximum
visible area looking down from top. This solves the problem where
an app pops up a dialog window. We should dimming (and allow touch)
the entire task area, not just the dialog's visible area.
- Fix initial bounds used in drag moving/resizing, this should be
visible bounds of the app main window, not the original task bounds.
- Fix touch region set up for freeform apps, even when task is not
full screen, we should get the max visible bounds first (as freeform
app could have dialogs too).
bug: 25494928
bug: 25487005
bug: 25613403
Change-Id: Ib1c6a1665fb83ded2fcb0a7ea92cf1def5372edd
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 61f39a7b988f6a22681a3f9e0bf8121f72ff88c4 |
|
29-Oct-2015 |
Jorim Jaggi <jjaggi@google.com> |
Migrate docked divider drawing to SysUI
Move docked divider drawing to SysUI. This let's us have real
time shadows in the future. Keep DockedStackDividerController
for placing/visibility in window manager.
Change-Id: I82c10add626d30f2ba180ee2a21cdbe6ddfe0371
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 73c3fcf576e3df3fc503788fc118d82d39e89f02 |
|
05-Nov-2015 |
Chong Zhang <chz@google.com> |
Exclude system decor area from tap detection.
If we have system decor (status bar/ navigation bar), we want to
exclude that from the tap detection. Otherwise, if the app is partially
placed under some system button (eg. Recents, Home), pressing that
button would cause a full series of unwanted transfer focus/resume/pause,
before we could go home.
Change-Id: Idd408bd69f5064f906bb9f8e2b2385c26a6a6929
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.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/DisplayContent.java
|
| 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/DisplayContent.java
|
| 1e60e0c61a3ec4b53aeae7fbe9c6da4d047a5d02 |
|
28-Oct-2015 |
Wale Ogunwale <ogunwale@google.com> |
Support for pinned stack to always be on-top of visible stacks
Bug: 25006507
Change-Id: I577e11224eead72dbb50def6be30b640707d2187
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 58fa9de4f8ba8ce3a403db0f32a7236a9f963a5e |
|
09-Oct-2015 |
Wale Ogunwale <ogunwale@google.com> |
Update dock divider display info. whenever it changes.
The docked divider display info. was set on object creation and never
changed. This can hang the dock divider if the device rotation is
changed and the user moves the divider rapidly in and out of the
screen edge closer to the right. We now update the display info.
whenever it changes.
Change-Id: Ie5f0c7ebdafedb156d04eceee00fc7e4176d9bf8
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 12cbd92c1dec4b93d2d292c3082f52d25cd6703b |
|
06-Oct-2015 |
Wale Ogunwale <ogunwale@google.com> |
Use visible window bounds to determine if a point is within a task
We need to use the visible frame on the window for any touch-related
tests. Can't use the task's bounds because the original task bounds
might be adjusted to fit the content frame. For example, the presence
of the IME adjusting the windows frames when the app window is the
IME target.
Bug: 24680002
Change-Id: Id73453788d56de879410027531ddefa46d929c67
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.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/DisplayContent.java
|
| e45899ae4a1414560b979168412fb3d3b575d486 |
|
01-Oct-2015 |
Wale Ogunwale <ogunwale@google.com> |
Create non-docked stack with right bounds if docked stack exist
We previously created a new stack with a bounds of half the screen
instead of using whatever space is left by the docked stack.
Change also takes care of issue where the adjustment bounds was
slightly off for non-docked stack.
Bug: 24460346
Bug: 24501077
Change-Id: Ib7f6c62bdf9309ca8916527dbb206e3719a36d9e
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| fd04d8c8840c2a762e4f19c31310561263898621 |
|
30-Sep-2015 |
Wale Ogunwale <ogunwale@google.com> |
Initialize DisplayContent base info when object is constructed
It is possible for an external process (e.g. sys-ui) to call into
WM to get the bounds of a stack in between the construction of the
DisplayContent object and SystemServer telling WM that the display
is ready. Incorrect bounds would be returned to the caller in this
case since the baseDisplayWidth/Height is only set when the displayReady
call is made.
We now initialize the base display information when the DisplayContent
object is created so any call to get the logical display rect of the
display will always return the right bounds. This should be okay as the
display manager is initialized way before window manager.
Bug: 24505761
Change-Id: Iebd688ad8f4c08556846fcebb543e58bd2c01414
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 54eb12caa0f049013bc5131e38675c1df2803d00 |
|
29-Sep-2015 |
Wale Ogunwale <ogunwale@google.com> |
Allow non-freeform tasks to gain focus when docked stack is up
We were previously limiting the focus task detection to freeform tasks.
Bug: 24365439
Change-Id: I4e9f8560f7e297bf7abe598565892d59db8c2e23
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 3ddc5d60967a5daa2ebf0ede98b71093bb8cc4ae |
|
24-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Resizing docked stack by dragging dock divider.
Change-Id: Icc9df00446780f8cd81df4654ace07f33346e901
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.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/DisplayContent.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/DisplayContent.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/DisplayContent.java
|
| 5a2f2cb3de21beaa0b760bb0be1928909012f81e |
|
17-Sep-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed issue with relaying-out sysui when resizing a freeform task.
WindowState.getTask() was returning the focusedApp task for windows
without an AppToken (e.g. status bar, nava bar, wallpaper). We then
check to see if the config associated with the task has changed and
tell the client window to resize if it as. The config would have
changed in this case since we are using the focus app task
(task we are currently resizing) to determine config changes for all
windows without appTokens. Changed the logic so this is no longer the
case.
Also, cleaned-up the use of getTask().
Bug: 23939846
Change-Id: I473671021282695d282a8a2b82d679722273ca09
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 231b06e7d302762a2680fd5f15b41ec7848a439f |
|
16-Sep-2015 |
Wale Ogunwale <ogunwale@google.com> |
Increased window resize handle to 30dp.
It was very hard to hit the drag target with 10dp.
Also, centralized dip to pixel conversion with window manager.
Change-Id: Idc8a90dd55113aa731eaaa8b04af6b74a1176546
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.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/DisplayContent.java
|
| 8e89b31a62fb9ec5ad33908c5e8e9c7ab2fd949f |
|
10-Sep-2015 |
Chong Zhang <chz@google.com> |
Move window moving and resizing handling to WindowManager
- add a startMoving API to initiate a window move from app, once
the move starts WindowManager will take over the event handling.
- detect touch events along window's outside border and start
a resize if necessary
Change-Id: Ic7e8baba34e0aa27a43173e044ffb46e93e219e0
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.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/DisplayContent.java
|
| f0d15a752c9954906b18048aba59b99014e7f55e |
|
12-Aug-2015 |
Filip Gruszczynski <gruszczy@google.com> |
am d994c254: am d200aa4c: am a546e5be: am ba1e3915: am 59123b9b: Merge "When closing task stack remove reference to display content." into mnc-dev
* commit 'd994c254dafc224ca78c00f4df11cfa5e7f5c03b':
When closing task stack remove reference to display content.
|
| 26ed265ceea18a42fddb95777c51a60063b0ef13 |
|
10-Aug-2015 |
Filip Gruszczynski <gruszczy@google.com> |
When closing task stack remove reference to display content.
This tightens the guarantee that detached stack won't be used. We also
add logging to detecting a situation where a stack not belonging to a
display is being moved on that display.
Bug: 22191609
Change-Id: Ia674bb5960018104a56c5138775ab5216906675b
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.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/DisplayContent.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/DisplayContent.java
|
| 06d582d4e42893e7e061477004d991d35b5f0d78 |
|
01-Jun-2015 |
Doris Liu <tianliu@google.com> |
Fix calls to Rect.intersect(Rect) in package com.android.server.wm
This CL checks for the return value for Rect.intersect(Rect) for whether
there is actually an intersection before taking the calling rect as the
intersection. In addtion, this CL handles the cases where there is no
intersection (Rect.intersect(Rect) returns false).
bug: 7368679
Change-Id: I7d5ef7059ac432170470a108c0d6dece230ec0b3
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| d46747a1c64b6ca3282e8841833980ab91829436 |
|
16-Apr-2015 |
Jeff Brown <jeffbrown@google.com> |
Add support for disabling display scaling for development.
Added two new options to the wm command.
1. Set the screen size based on dips rather than pixels using the
current screen density.
eg. adb shell wm size 320dpx320dp
2. Disable automatic scaling of the contents of the display.
When combined with the previous command, this is useful for seeing
how the UI would behave if the screen remained at its current density
but changed physical size.
eg. adb shell wm scaling off
Bug: 19899223
Change-Id: I545f893ba4861494e995cf0457ebeba1050d28dc
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 1bef389f70de89d82189b94967eccee9b3b58d68 |
|
18-Feb-2015 |
Craig Mautner <cmautner@google.com> |
Fix NPE in DisplayContent.setTouchExcludeRegion.
DisplayContent.mTapDetector is null for any non-default display. When
testing ActivityView DisplayContent.setTouchExcludeRegion() throws an
NPE when dereferencing mTapDetector.
This change adds a null test to avoid the NPE.
Fixes bug 19413700.
Change-Id: I48a66c0ed071c87b38b354eead58a4de97fb47b9
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| b1193ade255385d899d81e8d62ceaa97c7d6aeb6 |
|
17-Feb-2015 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Apply stack dim layer to entire screen for system windows."
|
| 498e8c92d71ff4ccfd2a77bdc53160e8dc93c7fe |
|
13-Feb-2015 |
Wale Ogunwale <ogunwale@google.com> |
Apply stack dim layer to entire screen for system windows.
System windows like alert dialogs are attached to the currently
focused stack even when the stack isn't full screen. This causes
the dim not to apply to other visible stacks when a system
window is up. Change applies the dim to the entire screen for
system windows since they extend outside a resized stack.
Bug: 19332229
Change-Id: I94affa6a652326bf2cf14b1b8bf54862c111c540
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 4a02d8133bb8bda109404c78002f80cda1f1179e |
|
13-Feb-2015 |
Wale Ogunwale <ogunwale@google.com> |
Don't move multi-window stacks on orientation change.
Change allows resized stacks to remain in the same location
while their content change orientation.
Bug: 19358195
Change-Id: I5a9898c1cf85cb5c4c2eab0f4969b339defb199a
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.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/DisplayContent.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/DisplayContent.java
|
| 799bc1d383ea40637e88c4a9dba8671585202d99 |
|
14-Jan-2015 |
Craig Mautner <cmautner@google.com> |
Refactor moveStackWindowsLocked()
The method had multiple inner loops and was a less efficient form of
rebuildAppWindowsLocked(). Rewritten to use rebuildAppWindowsLocked()
and small other refactors.
Item #1 of bug 18088522.
Change-Id: If93fa961922c77c9f0af719e535ae5ca5d30fe59
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 9d82182f0c97271323d039b51e9179d2f4f2fa74 |
|
13-Jan-2015 |
Craig Mautner <cmautner@google.com> |
am 31ae1730: Merge "Add debug for ANR" into lmp-mr1-dev
automerge: 0f6da47
* commit '0f6da477cbf3232996770a17910d3e44a0b893ac':
Add debug for ANR
|
| bcb6eb9e26c923333b25074d39722a5dfa8c0320 |
|
13-Jan-2015 |
Craig Mautner <cmautner@google.com> |
Add debug for ANR
Help for bug 17721767.
Change-Id: If863f3e6536be8af2c189dcc37d503c4d6b663b4
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 2f5e606ec511fefe55e4f51b42a623db6a646f85 |
|
19-Dec-2014 |
Craig Mautner <cmautner@google.com> |
am c14a4b10: Merge "Fix racing condition of mTouchExcludeRegion" automerge: 6007d9a
* commit 'c14a4b10caed67131d656ba5dda5944a52b48c0a':
Fix racing condition of mTouchExcludeRegion
|
| 33d8e739206b7a5ed99cf9bf73d63f9b6c0d2a4e |
|
25-Oct-2014 |
tingna_sung <tingna_sung@htc.com> |
Fix racing condition of mTouchExcludeRegion
Copy region from DisplayContent.mTouchExcludeRegion instead of
directly refer to the same object of DisplayContent, and able to
protect it by lock of self class, don't have to lock out mWindowMap
on every tap.
This fix is to avoid racing condition of mTouchExcludeRegion.
Change-Id: I7401968167c2e539b4da2afe71e3020038fbfcbf
Signed-off-by: tingna_sung <tingna_sung@htc.com>
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| e8b85fd41904ceaaa4ac09200b2b39106f9c5c37 |
|
22-Oct-2014 |
Craig Mautner <cmautner@google.com> |
Fix dumpsys display apptoken ordering.
Ordering was bottom up stack ordering but top down apptoken ordering
within each stack. This makes it top down ordering throughout the
dump.
Change-Id: Ie15dbbfc3b21b8df101a0803e556094142dc408e
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 333c2ec88305a71ab1d59bf0482193273fac61af |
|
02-Oct-2014 |
Craig Mautner <cmautner@google.com> |
Remove misleading error log.
It's perfectly ok for a secondary display to not have a home stack.
There is no reason to report it.
Related to b/17677973.
Change-Id: Ia9d52cabb601760d32d2b847dfa0ca4f304e4e2a
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| fabab90d1e3b723db64ccb0cf4564971edd361d8 |
|
17-Sep-2014 |
Craig Mautner <cmautner@google.com> |
Eliminate misleading warning.
Remove token from deferred list of tokens to be removed once token
is removed. Leaving it in the list leads to logging messages like
"WindowManager: removeAppFromTaskLocked: token=AppWindowToken{...
} not found" when an attempt to remove it a second time fails.
Discovered in logs from b/17512377.
Change-Id: Ic83d81841b9b74ae5c4c433d1086d3bbda8e1d64
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| 95da1087ed3c7b9983b571bc5409827ae390f15f |
|
25-Feb-2014 |
Craig Mautner <cmautner@google.com> |
Clean up activities and displays when done
More maintenance fixes.
Fix bug 13157352.
Change-Id: Ic86d39a84452a1cf1dc1762cec517b419ad0a852
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java
|
| b660b9d8cf6b951b85a35599d636c470795e9a1a |
|
13-Feb-2014 |
Craig Mautner <cmautner@google.com> |
Update DimLayer sizes on rotation.
Required replumbing and updating the TaskStack bounds calculations
to match the new separation of TaskStack from DisplayContent.
Fixes bug 12780687.
Change-Id: I061c92831c06f4eb3e673ad6296e721b0c0f3202
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.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/DisplayContent.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/DisplayContent.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/DisplayContent.java
|
| e0a3884cb627efc650e19fbe76b1b3343468cf57 |
|
17-Dec-2013 |
Craig Mautner <cmautner@google.com> |
Extend stack management to other displays.
- Abandon ActivityContainer.startActivity() in favor of
IActivityManager.startActivityAsUserInContainer().
- Modify Am to test starting an activity on a container.
- Create a DisplayContext as the base context if the activity token
is on a different display.
- Test for home display in more cases when manipulating home stack.
- Rename mDisplayInfos => mActivityDisplays.
- Create new method for moving task to front of stack regardless of
which display it is on.
Change-Id: I4fcb83ae844c5839ee3e2722229623d1a80ed921
/frameworks/base/services/core/java/com/android/server/wm/DisplayContent.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/DisplayContent.java
|