hideInsets(IME) may not be delivered to the control target if
the window requesting hide is no longer available in WindowManager's
window map. However, it is still nicer to deliver it to the default
display's control target rather than not delivering it at all.
Fix: 159623277
Test: Manually using steps in bug.
Change-Id: I22cdf20627da2183d30af444f6dd9d0375d417c1
If display is rotated 180 degree, the display might not have
configuration change. And if there is remote rotation and it hasn't
done, the rotation of display is still the old one. Once there is
a path calls stop-freezing-display, the rotation animation will be
executed directly with 0 degree delta. And if the activity needs to
relaunch, there will be obvious flickering.
Fixes: 160107205
Test: atest DisplayContentTests#testRemoteRotation
Change-Id: I66a02b67f7066abafd65c2c282144222701feaae
Add more dumps and logs to better help debug IME insets better
Logging can be enabled by setting InsetsController.DEBUG to true.
Bug: 154348613
Test: manually build and flash.
Verify showing and hiding IME shows logs.
verify adb shell dumpsys window windows has new dumps
Change-Id: Iad0a21d81a22d6acfaaf5c5ca8b5131eec411e79
When quick switch a delayed task, before onTaskAppeared called,
if the user holds gesture on nav bar, TRANSIT_WALLPAPER_OPEN from closing
app happens will cancel recents animation when
WC#applyAnimationUnchecked, and that will cause the black screen if the
delayed task not yet drawn and there is no recents task snapshot on top.
Since cancelling recents animation during quick switching doesn't make
sense, to fix that, we should check the animation task target if is
still controlled by recents animation, if so, we should not cancel it.
Also, make sure if the appeared task has already been in task target list,
(i.e. task A appreared, quick switch to task B, before task B appeared,
quick switch back to task A) if so, we don't need to callback task
appeared again.
Fix: 156670249
Test: manual as issue test steps.
Change-Id: I303403d63c91c08fabcb8c5b1b1aac42c4ec65db
This is an implementation of long screenshots supporting
interactive, incremental capture of scrolling content using
a cooperative API between the app process and the system.
Design goals:
- Provide for tile based incremental screenshots of scrolling content
- Support existing apps without developer action
- Provide support for non View-based Apps & UI toolkits
Bug: 148131831
Test: atest \
FrameworksCoreTests:android.view.ScrollCaptureClientTest \
FrameworksCoreTests:android.view.ScrollCaptureTargetResolverTest \
FrameworksCoreTests:com.android.internal.view.ViewGroupScrollCaptureTest \
FrameworksCoreTests:android.view.ScrollViewCaptureHelperTest \
WmTests:com.android.server.wm.DisplayContentTest
Merged-In: I6c66a623faba274c35b8fa857d3a72030a763aea
Change-Id: I6c66a623faba274c35b8fa857d3a72030a763aea
In quick switch flows, launcher will first swipe task snapshot
through recents animation, and then start new task with custom animation
options through startActivityFromRecents after gesture finish detected,
and then finish recents animation finally.
But that way user may experience flickering before the new task launch
and recents animation finish.
To improve quick switch flickering, we ignore the new task's custom
animation from recents and generate task remote animation target,
and then trigger a callback for launcher to control/animate this
task surface, more like a part of RecentsAnimation,
Also, adding removeTask method for launcher can flexibility remove the
new task animation target once no need to animate, so that launcher
can decide when to finish recents animation.
Bug: 152480470
Test: manual as below steps:
1) Doing quick switch task.
2) Make sure launcher can receive onTaskAppeared callback.
3) Make sure launcher calls removeTask successfully.
4) Make sure launcher can finish recents animation after 3).
Change-Id: I0692a280a49719229fa8871509bad37a1343a00f
The root causes of this issue are:
1. WindowTokenClient#attachContext makes WindowTokenClient has strong
reference to WindowContext, which leads to WindowContext cannot be
GC'd.
2. WMS#removeWindowToken needs MANAGE_APP_TOKEN permission which
normal apps don't hold.
This CL does following things:
1. Use weak reference instead on WindowTokenClient#mContext.
2. Relax WMS#removeWindowToken to check callingUid if
MANAGE_WINDOW_TOKEN permission is not held
3. Deliver config changes to the client side in
WMS#addWindowTokenWithOption
4. Some minor fixes
fixes: 150812449
Bug: 150715095
Test: atest WindowContextTest
Test: atest WindowManagerServiceTests
Test: atest WindowTokenTests
Test: atest WindowManagerPermissionTests#testMANAGE_APP_TOKENS
Test: atest
WindowManagerPermissionTests#testADD_WINDOW_TOKEN_WITH_OPTIONS
Change-Id: I9f1d73af2abb78fc9844e6d9eb25e9f0293514e7
Support addWindow with the other userId which can be different from Uid.
This can be used when client want to addView for secondary user.
Example:
1. Create context with createContextAsUser or similar method.
2. Get WindowManager with this context.
3. WindowManager#addView
Bug: 151414297
Test: atest WmTests WindowAddRemovePerfTest AddWindowAsUserTest
Change-Id: I13e58d76b1f056f3829bc984c2b61496c8f8d535
Even DeadObjectException is thrown, it is not equivalent to the
window is died (transaction failed by small size data will be
DeadObjectException). Sometimes it may be caused by the binder
buffer of process is temporarily full. If the window is removed
directly but the process is still alive, the application client
and window manager are out of sync. Especially if the window is
important system window, e.g. status bar, notification shade,
navigation bar, which might need to reboot to recover. Ideally,
if the process is really dead, there should be a binderDied
callback that also removes the window.
The original purpose of the removal is to avoid display frozen
(e.g. rotation) always timeout which is caused by resetting
WindowState#mOrientationChanging in each layout traversal. Now
the window states are still updated as "resized" has reported,
so it won't block unfreeze display.
Bug: 151814107
Bug: 147448299
Test: atest WindowStateTests#testReportResizedWithRemoteException
Test: Hard code to throw RemoteException for a specified window
and rotate the display.
Change-Id: Id295456cc99ab9af30aa5fad2eedada6afb862a2
Renamed TaskContainers to TaskDisplayArea and added getDisplayArea()
method to WindowContainer that finds the first display area in the
hierarchy above the node. ActivityRecord and Task override it to
return the TaskDisplayArea class.
Bug: 152116619
Test: WM CTS and unit tests
Change-Id: I4525afbcd794848e1020213cdca04d89a646dd55
Created a SurfaceFreezer class which lives in WindowContainer
and manages/will-manage per-container freezing (snapshots).
This replaces the one-off change transition code.
Change Transitions used to create its own temporary leash
on initialization and that leash would be replaced/cleaned-up
as soon as the animation leash was created.
Now, the SurfaceFreezer creates the animation leash immediately
and SurfaceAnimator can take a SurfaceFreezer instance when it
starts an animation. At this point it will take the leash that
was already created by the freezer and use that. This removes
the messy reparenting/cleanup.
To deal with this, though, leash callbacks into Animatable
needed an extra stage: onLeashAnimationStarting. This is called
when SurfaceAnimatior is actually starting to animate the leash.
Next, DC.mChangingApps was converted to list of WindowContainers
rather than ActivityRecords. Some of the existing change code was
cleaned up (ie. there was some visibility stuff that doesn't make
sense because changing apps are visible->visible) and some of the
Activity-specific functions were generalized. For now, there are
a couple things that use the top-activity for changing Tasks.
The result of this means that windowing-mode change transition can
now fully live at the Task level. This also should allow freezing
at any hierarchy level which enables app-freezes that don't freeze
the whole screen and potentially mixed seamless/snapshot-based
rotations.
Bug: 149490428
Test: existing tests pass. Manually open app in freeform and
maximize/restore it.
Change-Id: Ib32524ebbbb084a98442d3d035897306a11ee6c2
(cherry picked from commit e55b9e0f9d)
Introduce IWindowToken to report config/display changes from
server side. When config change callback is received,
it will update the resources associated with the window token.
Test: WindowContextTests
Bug: 128338354
Bug: 146820733
Change-Id: I871bd78a21dbde1286786e65c340b6259b873660
... and any other display that isn't considered a public presentation
display, as per Display.isPublicPresentation()
Bug: 141745510
Test: atest CtsWindowManagerDeviceTestCases:PresentationTest
Change-Id: I2aaab1903dee54190338f7b6e49888aa51437108
Introduces the concept of a DisplayArea, corresponding to an area
on a logical display within which content can be placed.
DisplayAreas can contain more DisplayAreas, WindowTokens and ActivityStacks.
A future CL will expose an API which allows leashing a DisplayArea to transform
all its content simultaneously.
DisplayAreas are managed by a DisplayAreaPolicy, which creates and places the
areas, and decides which area a container is placed in.
This CL introduces the concept, but applies a no-op policy that maintains the
current orderings and does not apply any overrides.
Future work that remains:
- Writing the feature policies
- Adjusting Display & DisplayMetrics if the area is constraining its children.
- Moving the policy into an product-adjustable component
Bug: 147406652
Test: atest WmTests
Change-Id: If6fb1bba3b65ebf7ac9fdf99408c54bf77f602c9
Animation type is specified when starting a surface animation,
and is passed as an argument of a callback which is triggered
when a surface animation finishes.
Bug: 131661052
Bug: 142617871
Test: atest DimmerTests SurfaceAnimatorTest
Change-Id: I89c671cf49b049dd241b874096d8ef245deb547d
App window requests IME, IME would be shown when showSoftInput() is
called from currently IME target.
This CL handles cases when IME target changes after showSoftInput was called
from the initial window and new window has received focus within same
app/task.
This CL also reports current control target on every startInput, which
sets current control target in WM.
Bug: 111084606
Test: atest CtsInputMethodTestCases
1. Open files app
2. Tap editor and make sure IME shows.
3. Open bubbles app.
4. Create a bubble and try typing in it.
5. verify IME shows as expected.
Change-Id: I9e8984b7e5aa989a53ece9e2576393f795b9ef94
Previously we only animated ActivityRecord. When hierarchical animation
is enabled, we find the top most entity from the window hierarchy (i.e.
ActivityRecord < Task < ActivityStack) which we can animate without
user visible changes, and set app transition animation on it.
The hierarchical animation is disabled by default. To enable it,
system property "persist.wm.hierarchical_animations" must be set.
Test: atest AppTransitionControllerTest
Bug: 131661052
Change-Id: I4709fd178de09d289d72cf1833b056b4e34fc92b
- Replace isHidden() and setHidden() by isVisible() and setVisible()
in accordance with variable names.
- Move isVisible() from AppRecord to WindowToken
Test: Refactoring CL, existing tests pass.
Bug: 80414790
Change-Id: Ib39200acbedf204adf57c06a8b8bbb3d07f959d1
- Task#numberFullscreen was only used in one location where we
needed to figure-out if the task has occluding activities.
Just use the hierarchy to figure that out vs. keeping track of
a variable that adds confusion.
- ActivityRecord#sendingToBottom was used to prevent focus and
orientation changes from activity moved to the bottom, however
since we are traversing the hierarchy from top-to-bottom we
should process activities on-top first vs the onces that have
already moved to the bottom.
- ActivityRecord#remove is no longer needed as the object won't
be connected to the hierarchy when it is removed.
Test: They pass!
Bug: 80414790
Bug: 35699615
Change-Id: I23f6501a65bf745dc0fb819c30543cd21241fa91
- Replace visible and hiddenRequested flag by a single flag
mVisibleRequested.
- Merge setVisible() into setVisiblity().
Test: Refactoring, all existing tests pass.
Bug: 80414790
Change-Id: I7bafdb86e6b8431046775d3968d24f85c3fac45a
This reverts commit cf0d2ae88d.
Reason for revert: broke dev test (com.roidapp.photogrid)
Fixes: 144403961
Change-Id: I77920d16062190b4565d4c95687b06fc587f9817
This reverts commit c0edbbb521.
Reason for revert: broke dev test (com.roidapp.photogrid)
Fixes: 144403961
Change-Id: I71ef435cfbdab46d2e57f2ed68af3eff04958a99
- Replace isHidden() and setHidden() by isVisible() and setVisible()
in accordance with variable names.
- Move isVisible() from AppRecord to WindowToken
Test: Refactoring CL, existing tests pass.
Bug: 80414790
Change-Id: Ie77bf1d00336e655b1fbee15d419c6959da2e0c9
- Replace visible and hiddenRequested flag by a single flag
mVisibleRequested.
- Merge setVisible() into setVisiblity().
Test: Refactoring, all existing tests pass.
Bug: 80414790
Change-Id: I2a959632430d90ef5c0f738aa791ef230c4a21f1
Merge Task and TaskRecord into a single Task class. Also Consolidate
updateTaskMovement() call points to TaskStack.onChildPositionChanged().
Bug: 80414790
Test: Existing tests pass
Change-Id: Iec0101b211bf34fab42131aae6cddfe1262e2add
The onAnimationEnd callback was not called when a cutstum animation was
set (e.g: JUMPCUT) causing WindowState.mOrientationChanging to never be
reset to false and drawing being held.
Bug: 142255739
Test: atest PixelCopyTest#testWindowProducerCropTopLeft
Change-Id: If35a0bb0ad94050fba086cb81f8265c0bf0535eb
- Add WindowContainer#getAnimationAdapter for all window hierarchy.
- Extract logics related Remote animation / Local animation adapter
creation from applyAnimationLocked into WC#getAnimationAdapter.
- Make RemoteAnimationRecord can accept in each window hierarchy.
Bug: 142617871
Bug: 131661052
Test: Refactoring, existing tests pass.
Change-Id: If1c39d09966d82653faf7ebd975592eaeacd7c24
- Updated Configuration#onParentChanged to take params newParent and
oldParent to make logic of reparenting less complex to deal with in
classes that extend.
- Introduced WindowContainer#reparent to consolidate reparenting logic
and also allow us to only set onParentChanged once for the operation.
- Simplfied logic flow around adding/remove/reparenting activity to
task by using methods like addChild(), onChildAdded(), and such.
- Removed Task.mDeferRemoval which no longer makes sense and was leading
to task and stack leaks.
Bug: 80414790
Test: Existing tests pass
Change-Id: I4ffa79a1c731dc137213bdd3d7f04b8f013decc4
This change kept AppWindowTokenTests as it's originally based on top of
WindowTestBase, and merging that into ActivityRecordTests needs to
change the base class to ActivityTestBase, which requires additional
work and may change test behaviors. Therefore delay that to
follow-up CL.
Bug: 80414790
Test: Existing tests pass.
Change-Id: I6d73975ee77be9817c41b297f067de2d92a68499
Make ActivityRecord extend AppWindowToken so we have a single object
for acitvities in the hierarchy.
Bug: 80414790
Test: Existing tests pass.
Change-Id: Ia7f52ef444cba88223f4e8a9586f6c12b1b5e4ea
