| 38d44ec857a75ebc98818743d08addf81ddc923e |
|
15-Jun-2017 |
Jorim Jaggi <jjaggi@google.com> |
Remove snapshot when screen gets rotated in mean time
We also need to wait for windows that are not gone for layout, as
otherwise we'd unfreeze before the surface is actually created.
Test: go/wm-smoke
Test: Open Camera in landscape but home screen locked to portrait
Change-Id: I0fc7a016445e18af1eead292665702b768b4e95b
Fixes: 38261533
/frameworks/base/services/core/java/com/android/server/wm/TaskSnapshotSurface.java
|
| d261632710e822db1f3c94879a15f2821a993384 |
|
07-Jun-2017 |
Jorim Jaggi <jjaggi@google.com> |
Also inherit FLAG_FORCE_DRAWS_STATUS_BAR_BACKGROUND
To make sure we won't cause SystemUI to draw the black status bar
background while the starting window is visible.
Test: Warm open chrome
Test: go/wm-smoke
Bug: 38136531
Change-Id: I8dfc0926cafef9d41e78a637523316ac46ce05df
/frameworks/base/services/core/java/com/android/server/wm/TaskSnapshotSurface.java
|
| e4b0f28a47097b7b0c04f3ae80507e2a15e3314f |
|
17-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Enable starting window logging
Also extend it to make sure we catch the bug!
Test: Open a couple of cold/hot apps, make sure logs look accurate
Bug: 37888853
Change-Id: Ied394969748d4d2d40359af15e0b491a2dc2b078
/frameworks/base/services/core/java/com/android/server/wm/TaskSnapshotSurface.java
|
| 4448e1ebb2d00f31292abcc7c5161a4e6f050c2e |
|
16-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix GraphicBuffer leaks in system_server
IWindowId is being kept alive by binder in certain cases, which
will leak WindowState, which can leak a whole lot including
the snapshot GraphicBuffer.
- Fix a leak in WindowContainer.mTmpChain1/2
- When the window gets removed, make sure to release the reference
to the window state so even if Binder keeps IWindowId alive, we
don't keep WindowState alive
- Make sure that even if we leak TaskSnapshotSurface we don't leak
the GraphicBuffer.
Test: Boot, some basic sanity testing.
Bug: 36279079
Change-Id: I4a0a784b32bc2df47934b1bed1d62b0682beb2dd
/frameworks/base/services/core/java/com/android/server/wm/TaskSnapshotSurface.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/TaskSnapshotSurface.java
|
| d635a4ae20014b6ff52d8b05e7f4f622808d4efd |
|
03-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix snapshots for secure windows
First, also draw system bar backgrounds when drawing a fake
snapshot. For that, refactor the drawing into a separate class so
it can be reused. Also enable fake snapshots for secure windows.
Test: com.android.server.wm.TaskSnapshotControllerTest
Test: com.android.server.wm.TaskSnapshotSurfaceTest
Test: Secure activity with resuming delay, make sure system bars
are covered when reopening app.
Bug: 35710126
Change-Id: I2f0ebc7e7acb80015780a4e882f0a472599efa30
/frameworks/base/services/core/java/com/android/server/wm/TaskSnapshotSurface.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/TaskSnapshotSurface.java
|
| 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/TaskSnapshotSurface.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/TaskSnapshotSurface.java
|
| 446079600ece83b22cb91865bcbeb694292b0108 |
|
16-Mar-2017 |
Andrii Kulian <akulian@google.com> |
Separate global and override config sent to client
There is some flakiness in View#onConfigurationChanged callback -
if ViewRootImpl receives config update earlier than ActivityThread,
it may not detect the configuration change and skip inner updates.
Also now ViewRootImpl assumes that it receives the global config as
a param, but instead it gets merged config from WM. This means that
ViewRootImpl#sConfigCallbacks was sending incorrect values to the
recipients.
This CL switches to sending global and override configuration to the
client separately. Also in case if there is a corresponding activity,
it first updates it and waits for update callback to ViewRootImpl.
This way global config and override config for activity will always
be set first and resources will be updated before inner state of
ViewRootImpl is updated.
Bug: 35870157
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: testOnMovedToDisplayCallback
Change-Id: Ic9e7541cf25ecfac6ec90e48f7efb0ece91f657e
/frameworks/base/services/core/java/com/android/server/wm/TaskSnapshotSurface.java
|
| 39367cf662f5ba190d0d7627f0e788a367e1d71f |
|
13-Mar-2017 |
Jorim Jaggi <jjaggi@google.com> |
Make sure to notify WM about having "drawn" our surface
Otherwise window manager won't start the transition.
Test: Open app, reopen app, make sure snapshot is actually used.
Bug: 31339431
Change-Id: I57708b48768fe3b561f797a0b9c6aa5ce7f84976
/frameworks/base/services/core/java/com/android/server/wm/TaskSnapshotSurface.java
|
| a35e5de13cbeb20459b0946828846a18c356e550 |
|
04-Mar-2017 |
Robert Carr <racarr@google.com> |
Reenable task snapshots without using RenderThread in SystemServer.
Instead just directly queue the buffer to the Surface.
Test: Make sure recents works.
Change-Id: I9488ae614f117f39f9471f3c368bf98152c4f107
/frameworks/base/services/core/java/com/android/server/wm/TaskSnapshotSurface.java
|
| 6d41026f1b3dc910c9d34ab89993a280dc9679cf |
|
01-Mar-2017 |
Bryce Lee <brycelee@google.com> |
Clean up closing apps list when clearing anAppWindowToken's task.
Previously it was possible for an AppWindowToken to be removed while
on the closing apps list, used in transition animations. During these
transitions, the visibility of the token is modified. Since
visibility relies on the WindowContainer parent, a
NullPointerException would occur.
This changelist addresses the issue by making sure to remove any
AppWindowToken from this list when its task is set to null.
Change-Id: Id9234822b228f4658f04d42ac0fe7b49ded6f5a1
Fixes: 35352214
Test: manual (primarily code inspection)
/frameworks/base/services/core/java/com/android/server/wm/TaskSnapshotSurface.java
|
| b047b8bd7e363081e91ba6cbc8d09cd355624584 |
|
09-Feb-2017 |
Andrii Kulian <akulian@google.com> |
Report move to display for activities that handle config changes
When activity that is moved between displays handles all configuration
changes, it won't be restarted. This CL adds a callback to the client
to notify it about display change. Usually it will be followed by
onConfigurationChanged, except when configuration didn't actually change.
When activity is recreated, it won't receive onMovedToDisplay.
Bug: 34862802
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Change-Id: I9a9501cab788623ada15a31efb53e4b2378639fe
/frameworks/base/services/core/java/com/android/server/wm/TaskSnapshotSurface.java
|
| 829b9cd100ddea44fadb9931c0ff11b11aaba059 |
|
23-Jan-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fill task snapshot with background color
Make sure to fill the portions that are not covered by the
snapshot are filled with the task background color.
Also fix an issue where the starting window was removed across
configuration changes.
Test: runtest frameworks-services -c
com.android.server.wm.TaskSnapshotSurfaceTest
Bug: 31339431
Change-Id: I2451be87aff79b337015ab4bba72cfa03c0d3582
/frameworks/base/services/core/java/com/android/server/wm/TaskSnapshotSurface.java
|
| 2f24b65075d66c278fa7f279a1a62f7376331900 |
|
18-Jan-2017 |
Jorim Jaggi <jjaggi@google.com> |
Make sure to release surface
Otherwise CloseGuard will complain in the finalizer.
Bug: 31339431
Change-Id: I179d1093e4a08d062ce971cf8e5e0fca02156fca
/frameworks/base/services/core/java/com/android/server/wm/TaskSnapshotSurface.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/TaskSnapshotSurface.java
|