| Age | Commit message (Collapse) | Author |
|---|
|
The directory is being moved to its own project in frameworks/layoutlib
Bug: 36889565
Test: Built manually
Change-Id: I69a1a826d0bac8ede1f9a337c9c1d930bbcd04f3
|
|
Bug: 36687605
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testWindowButtonEntersPip
Change-Id: I0bb35fd666eb6a438e4676267f6726b44bffb3db
|
|
Displays can be rotated separately and rotation watcher clients
are only interested in rotation of some specific display. This CL
adds displayId to rotation watchers and only informs them about
changes on their display.
Bug: 34242678
Test: Manual and debug.
Change-Id: If0f03804da0392c2b14a4e7c2d6a06068ad8760b
|
|
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
|
|
- #1: Move logic for handling IME size changes into SysUI, and only rely
on PinnedStackController to provide bounds when first entering
PiP and on rotation
- #2: Doing #1 allows us to move PipMotionHelper to SysUI completely, which
lets us aggregate the animation calls out of PipTouchHandler
- #3: Add proper callbacks to the listeners when the movement bounds
changed from config change, ime change, or aspect ratio change. This
allows SysUI to calculate the associated movement bounds for the
expanded state, and we can then remove the corresponding WM call.
It also means that SysUI is the only thing that needs to know about
the expanded state.
- #4: Fix issue where TV was getting the default bounds, not taking the
aspect ratio when the PiP was entered into account. Doing #3
allows us to report the right bounds.
- #5: Remove dead code related to edge snapping/minimizing now that they
are on by default and associated tuner setting, and controller
callbacks
Test: android.server.cts.ActivityManagerPinnedStackTests (all existing tests pass)
Change-Id: I3ef361bdf8d44094b4c0a11c70ba4db7d697fdec
Signed-off-by: Winson Chung <winsonc@google.com>
|
|
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.
|
|
Pass information about content insets of a snapshotted task to
SystemUI and use it there to correctly offset the snapshot
when drawing.
Test: Open app, go to recents, make sure app aligns before
and after the animation.
Bug: 31339431
Change-Id: I2ff9bd44534bd8f66b591385da1e1e3aec40b6c5
|
|
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
|
|
For linking TaskRecord in AMS to Task window container in WMS.
Bug: 30060889
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowContainerControllerTests
Test: bit FrameworksServicesTests:com.android.server.wm.TaskWindowContainerControllerTests
Test: Existing test pass and manual testing.
Change-Id: I16248f3e96e5087ba24198a48a3bd10a12ae76a6
|
|
- WindowContainerController class allows a component outside window manager
to create a window container and communicate directly with it to make
changes. For example, the ActivityRecord class in activity manager uses the
AppWindowContainerController class to create and communicate with
AppWindowToken window container class which is its counterpart on the window
manager side.
- WindowContainerListener interface allows a component outside WM to get
notified of changes to a window container. For example, the ActivityRecord
class in AM implements the AppWindowContainerListener interface to get
notified of changes to the AppWindowToken container.
Bug: 30060889
Test: Existing tests pass and manual testing.
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerControllerTests
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerTests
Change-Id: I2896bfa46a80b227052528c7da8cf4e56beab4bc
|
|
Makes it easier to follow what is going on and also clean-up in
preparation of stand way for AM to interact with containers in WM.
Test: Existing tests pass and manual testing
Change-Id: I91754b6d974dce2f696453cdaed175efb0f10c73
|
|
The flag is a bit clunky for most cases, and a method is more
clear.
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test
android.server.cts.KeyguardTests
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test
android.server.cts.KeyguardLockedTests
Test: runtest systemui -c
com.android.systemui.keyguard.DismissCallbackRegistryTest
Bug: 30961403
Bug: 27422134
Change-Id: I39de90c7cfecd99350a74f72cd76418e337f2b79
|
|
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
|
|
Cleanup:
- Make sure all the state is nicely dumped.
- Remove some unused stuff.
- Fix a flicker when occluded -> unlocked
Bug: 32057734
Change-Id: Id87e26adccef740d608b325c2dc1f6db14dd4ec3
|
|
- 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>
|
|
- Ensure we use the right display size when calculating PIP bounds.
- Also update interface to take the display id.
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testPinnedStackDefaultBounds
Test: #testPinnedStackMovementBounds
Change-Id: I01fd8ba6dee212c29a9a092673ee8f7843e41af6
|
|
Now display-specific settings, such as dimensions and orientation,
are stored in display override config. For default display it is
mirroring the global config. Each time when global config is updated,
override of the default display should be updated too and vice versa.
Test: Existing and manual tests still pass.
Change-Id: Ic6c2190092d328820f314a05bed43c875db18170
|
|
- This CL provides the framework for manipulating the pinned stack using
an input policy (to be determined later) provided by the SystemUI.
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testNonTappablePipActivity
Change-Id: I025c41fff26ed05a35d68e59f10330680ed11ea8
|
|
am: b7a673ed95
am: dccfd4394e
Change-Id: Ie8bbbfb5c24957f64036e8de23d6a29e6669ea18
|
|
- Prevent third party apps from inadvertently changing internal SystemUI
flags through a call to setSystemUiVisibility(). These flags are only
set in the individual SystemUI components and can be updated in WMS
directly.
Bug: 29875297
Change-Id: I5ea238c8fb16a0eccd6e993d95a912acb359cee6
|
|
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
|
|
am: 48818fa811
Change-Id: I19f5810159ed772ac8ed1e9d498f8fe0036a95d0
|
|
Bug: 30839993
Change-Id: I5368accddfc4a03b8025a257b4155fcdc6197f11
|
|
Restrict saved surface to launcher start (ACTION_MAIN&CATEGORY_
LAUNCHER), or there is no intent at all (eg. task being brought to
front). If the intent is something else, likely the app is going
to show some specific page or view, instead of what's left last time.
This solves problems like the launcher shortcuts on DeckClock,
each of them is a different intent and will show one specific
view regardless of last states. Another example is Chrome tab
opened directly by action VIEW to open some URL.
(Note that this doesn't solve the problem with Chrome homescreen
shortcuts, it will still start with saved surface (if Chrome
is already open). This is because the shortcut is a trampoline
activity that starts the real chrome tab activity, but when
the trampoline is started, the whole task is already brought
to front, and ChromeTab could become visible with the task
before we actually start it.)
bug: 31055479
bug: 27747315
Change-Id: Id3e61c61ef516b0edc1f174320f02661222f226b
(cherry picked from commit ad24f96def42016049de05220593aa049b136def)
|
|
Restrict saved surface to launcher start (ACTION_MAIN&CATEGORY_
LAUNCHER), or there is no intent at all (eg. task being brought to
front). If the intent is something else, likely the app is going
to show some specific page or view, instead of what's left last time.
This solves problems like the launcher shortcuts on DeckClock,
each of them is a different intent and will show one specific
view regardless of last states. Another example is Chrome tab
opened directly by action VIEW to open some URL.
(Note that this doesn't solve the problem with Chrome homescreen
shortcuts, it will still start with saved surface (if Chrome
is already open). This is because the shortcut is a trampoline
activity that starts the real chrome tab activity, but when
the trampoline is started, the whole task is already brought
to front, and ChromeTab could become visible with the task
before we actually start it.)
bug:27747315
Change-Id: Id3e61c61ef516b0edc1f174320f02661222f226b
|
|
Change-Id: I32a8e0e5cb5209133e00dbc0589bc8b87f46260b
|
|
addAppToekn and setAppTask have a new argument.
Change-Id: I8a66863ba4e1cb2991a9f2ae355d0b89e9789f57
|
|
When quickly toggling between two apps, app could be resumed while
it's stopping but not yet stopped. Upon resuming, it could have
surfaces that's marked mDestroying and waiting for the stopped
to be destroyed.
We need to dispose these surfaces properly. If the window is already
removed, we destroy them. Otherwise, clear mDestroying flag so that
the window is ready to be used again. Leaving mDestroying=true makes
the window ineligible for certain things such as receiving wallpaper.
bug: 30255354
Change-Id: Id881653550595ab8e702d6950949bf202ac5a0d9
|
|
Bug: 29963541
Change-Id: If0a574004f8bddf1ba170587a8187253fe045ef4
|
|
When activity transition triggers a rotation change, the starting
window will normally be the top window at the time we try
to select the window animation. However, these layout params won't
have the apps rotation animation set (as the client code will set that
on the real window, not the starting window). Eventually we would
like to add API to specify rotation animation via manifest to solve
this problem cleanly. In the mean time, we can force a specific rotation
animation from the double tap gesture, and clean up some camera
ugliness. We accomplish this by attaching an animation hint to
ActivityOptions.
Bug: 28838855
Change-Id: If052cd8cbae76651da43f3b4c590cd9dcc1afc0f
|
|
Bug: 29127791
Change-Id: Ib5f85a207bdb79eeac0418fda78e452d225761bc
|
|
- Added ActivityOption to mark a starting activity as a taskOverlay
activity. That is the activity will always be the top activity of the
task and doesn't cause the task to be moved to the front when it is added.
- Only set the starting window state of the ActivityRecord to shown if
window manager actually showed the starting window for the activity.
Avoids incorrectly trying to remove starting window for an activity that
didn't show any.
- When starting additional activity in a task, transfer the starting
window from the top most activity with a starting window. It is possible
the top most window does have a starting window like in the case of the
forcedResized activity.
- Only ensure visiblity of an activity we are starting in a task whose top
activity is a task overlay. They need to start in the visible-paused state
and not the resumed state which just causes extra churn in the system.
- Always add additional starting activities in a task with an overlay
activity below the overlay activity.
Bug: 28751186
Change-Id: I3624a4313ae9c406d42c67a3537f67ad685791af
|
|
bug: 27834014
Change-Id: Ib5d03818d285c50d220c45ebace635faf6771ff3
|
|
Update configuration with WM first and check if the stacks need to be
resized due to the update. If so, let activity manager resize the stacks
inline, instead of letting WM schedule another pass of resizeStack. This
way the configuration will be updated to the latest before ensureActivity-
ConfigurationLocked, and we don't need another relaunch there.
bug: 27834014
Change-Id: Ib761a96cada0c3247b0480f18370670c593159da
|
|
This is an input consumer similar to the one used when hiding the navbar,
but placed above wallpapers. It might be useful for processing touch
events over "desktop" in freeform MW mode.
Re-landing I9d6d28a624f750ad48fc39f9b149dd1f989cceba after fixing build.
Bug:26688904
Change-Id: I89fdabd9c72cdd4a1d7ca626c33ddc99ddea97f9
|
|
Bug: 27673736
Change-Id: Ie72807aa8c2bfd142b081a6a915e101c16d31473
|
|
Hides the wallpaper when it's not needed and fixes
the unlock animation to not unnecessairly show the
wallpaper if neither the Keyguard nor the underlying
app need it.
Also fixes a bug where the enter animation had a background
set, which led to uglyness when no wallpaper is involved.
Bug: 27533740
Change-Id: I667c6f7ca6c0e1ff7e9f793c6ddc13f6da8387b1
|
|
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
|
|
It is possible for an activity to be in the stopped state without
setting it's visiblility to false in window manager.
For example, the home acitivty behind the lock screen. Since the
lock screen isn't an activity it doesn't affect the visiblity set
of the home activity, so AM doesn't tell WM to hide the app token.
However, AM uses another channel to detect that the device is locked
and moves the activity into stopped state. WM on the other hand also
detects that the device is locked and hides the window surfaces of
all windows behind the lock screen. So, at this point AM has also
told WM that the activity is stopped. Once you unlock the screen
AM resumes the activity but doesn't report any visiblility changes to WM
since it's internal state didn't change. So, if you go from the home
activity to another app the home activity window will be destroyed
before the activity is stopped because mAppStopped is set to true.
We now set mAppStopped to false when the activity is resumed.
Bug: 27286867
Change-Id: Ic75456d30abd582fa44f932f5aeeb449950157ee
|
|
The registered shortcut will be called from PhoneWindowManager,
before dispatching
Change-Id: If26128939b45a639c8895719a7a23ca433f39fd9
(cherry picked from commit 4da863c5a8872dcabb179a978a2b2157d9081679)
|
|
Prior to this commit in this case of activity pause, with finishing=true
the activity manager will notify us of app visibility and we will begin
an exit animation. When this exit animation finishes, we will destroy
the application surface (unless its eligible for saving). However there
are two cases where this breaks down:
1. The exit animation finishes before the activity thread handles
the stop transition. Many activities stop rendering on Pause
but many do not and it is totally legal to do so. Sometimes this
results in non fatal dequeue buffer errors and sometimes results in
fatal errors with Pixel Buffers, etc...
2. We may resume the activity shortly after asking the window manager
to pause it. If the window wasn't eligible for animation, we will
immediately destroy it after being told of the visibility change
following PAUSE_FINISHING. It's possible for this to complete
before we process the resume. On the other hand the client
happilly processes the resume and transitions back from PAUSE
and then crashes once it attempts to use it's surface.
In this commit we have the activity manager notify the window manager
when an application has actually finished (or we have timed out
waiting). For windows which have not been explicitly removed by the
client, we defer destruction until we have received both this signal
and the animation has completed.
Bug: 26793431
Change-Id: Ib6ee8fbdd1f03450fbbfd62468a19e97774befab
|
|
Change-Id: Ifed64dc2a4db9a58c3588ea0ca899f628efe685a
|
|
Changes activity manager and window manager to use resizeMode
as defined by ActivityInfo#resizeMode instead of a boolean.
Bug: 26774816
Change-Id: I8cef46d9fba6bfdd21df7da63ed5d5330ad03d4b
|
|
Bug: 22405482
Change-Id: I8fc522885801e9735544ec3820c8fdd4a4368d71
|
|
Change-Id: Ifd69818ca6d5dbf129f6c956c1a7dfae760e30d6
|
|
Change-Id: I694a885e705d2543e671fd2809bbb518176c3804
|
|
When an activity is moved to a stack using the
ActivityStack#moveActivityToStack API a new task is created to
hold the activity in the stack. However, when the new task is
created in the window manager side it uses the stack id of the
previous stack the activity was in. We now pass the stack to use
from activity manager to window manager.
Bug: 25987309
Bug: 25961636
Change-Id: Iecc71f6d9b3e70a8d88e134b42f7532ba5327bad
|
|
We achieve the removal by notifying System UI about the visibility of
the dock divider. This way System UI can change visibility of the root
view, which in turn will cause the WMS to destroy or create the surface
as necessary.
Bug: 25844096
Bug: 25683717
Change-Id: Idbc33368db697a059af49106dfadb80c3d7d06c1
|
|
- Adding “focused” stack state to support paging
- Changing the paging to match UX spec (only auto-page after the first
tap)
- Removing old header focus animation
Change-Id: Id72825b8a1b1c0a2238ee184a6695b13c1d8cb1c
|
|
Bug: 25392381
Change-Id: Ib507f53bcd2aad4771c2546f5e8bfe771769e9a2
|
