| 0823c9ff5cbbe954bd747d4713b18f5856bdd371 |
15-Jun-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Remove snapshot when screen gets rotated in mean time" into oc-dev
|
| 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
askSnapshotSurfaceTest.java
|
| 04c3cc6d12012dcb39f8aef9a07143d91328ba77 |
15-Jun-2017 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Use splashscreen if we can't fill horizontaly with snapshot" into oc-dev
|
| 42befc64c43377bfcec0e8cfe6fbcb9fdf5f0953 |
13-Jun-2017 |
Jorim Jaggi <jjaggi@google.com> |
Use splashscreen if we can't fill horizontaly with snapshot
A gap at the right side of the snapshot looks pretty bad. Thus,
we use a splash screen in case there would be a gap on the right
side. However, we don't want to do this from recents as we'd
produce another flicker
Test: go/wm-smoke
Test: Open app portrait, go launcher, rotate, open app landscape
Test: Open app landscape, go launcher rotate, open app portrait
Fixes: 62094756
Change-Id: Iaf1fecced822685187477a4698fa6b67c6e485d7
ppWindowContainerControllerTests.java
|
| 4a526c124554e75dc4bc11a682645a73bd47d501 |
16-May-2017 |
Winson Chung <winsonc@google.com> |
Ensure that we use SF Vsync Choreographer for the PiP transition.
- Move the bounds animation onto the animation thread
- Remove existing code referencing the old sf-vsync choreographer
- Add ability for ValueAnimator subclasses to reference a different
AnimationHandler, which uses a different FrameCallbackProvider with the
sf-vsync choreographer in the animations that require it
- Ensure that PiP touch events are batched and sent aligned with the
sf-vsync
- Move GC onto its own thread to not block other BackgroundThread calls
Bug: 36371375
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: bit FrameworksServicesTests:com.android.server.wm.BoundsAnimationControllerTests
Test: go/wm-smoke
Change-Id: I6a41b35a4e4d4d6dbea82c2673452825fe3ffa58
oundsAnimationControllerTests.java
|
| 45ca0544ea03e04d1ecb11640484818fe2838c28 |
31-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix camera launch delay from Keyguard
When we launch the camera from the lockscreen, we launch a
trampoline activity that launches a real activity. Now, under
certain race conditions the trampoline activity was resumed but
then set to invisible immediately again such that the window
was never relayouted. Thus, the activity was stuck in
WAITING_RELAYOUT state in UnknownAppVisibilityController, leading
to a app transition timeout.
To fix this, we immediately remove the app from the unknown
visibility controller as soon as it gets set to invisible again.
Test: Set animation scale multiplier to 0, open camera, finish
activity by pressing back, turn off screen, launch camera via
double tap, observe no delay.
Test: go/wm-smoke
Fixes: 37677242
Change-Id: I103a89af5fb515d6635f86abe2c67a02d90abd79
nknownAppVisibilityControllerTest.java
|
| ae73ba4c591630bd5f90b8e8e3ceaed3be20fa56 |
05-May-2017 |
Bryce Lee <brycelee@google.com> |
Do not always skip preparing window to display when already visible.
The window flag FLAG_TURN_SCREEN_ON relies on this method to properly
flag the screen to turn on. An optimization was put in place to skip
this method when the window was already visible. As a result, we would
skip turning the screen on if the activity was recreated.
This changelist addresses this issue by causing this method to execute
always if the flag is set.
Change-Id: I82c05c66136f7cc252b8d574d305809d455732ce
Fixes: 37432034
Test: bit FrameworksServicesTests:com.android.server.wm.WindowStateTests#testPrepareWindowToDisplayDuringRelayout
Test: go/wm-smoke
indowStateTests.java
|
| 9eb635c428367f0b67ed8acd5bc11f3275c400af |
25-May-2017 |
Bryce Lee <brycelee@google.com> |
Merge "Use cached keyguard flags during relaunch." into oc-dev
|
| ef4e38f96fa696e92629e87edaabad151e5248f8 |
25-May-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Ensure that windows are drawn before starting transition into PiP." into oc-dev
|
| e7ba686f63682246d2e2d856208d23e23c801079 |
24-May-2017 |
Winson Chung <winsonc@google.com> |
Ensure that windows are drawn before starting transition into PiP.
- Building upon ag/2125930, we ensure that all windows are drawn before
starting the enter PiP animation.
Bug: 37420370
Test: bit FrameworksServicesTests:com.android.server.wm.BoundsAnimationControllerTests
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: I73fb71681f62bbc684efedbd3d40c3e1a670db46
oundsAnimationControllerTests.java
|
| b80cffad4bd64daf643302a99a9172c8536c27ff |
25-May-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix flaky tests" into oc-dev
|
| 081554b2e65b794189cd1412684d7fa9d07602fb |
25-May-2017 |
Bryce Lee <brycelee@google.com> |
Use cached keyguard flags during relaunch.
It is possible for the display to be unfrozen before an
AppWindowToken is finished relaunching. This allows for other window
containers (such as the StatusBar) to influence the rotation when
unfreezing.
This changelist prevents the cached keyguard flag values for the
AppWindowToken when relaunching. This prevents incorrect values from
being reported during transient relaunch window states.
Fixes: 38262879
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowTokenTests#testKeyguardFlagsDuringRelaunch
Change-Id: I2aa23ac282cf7626bb187c6cd1a4a3524f788877
ppWindowTokenTests.java
|
| 153badbf417c3b32fb2702c723185882ca1b3ba2 |
24-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix flaky tests
Need to wait until handlers are idle because the display gets
frozen when adding a new one, which will screw up starting window
creating.
Test: AppWindowContainerControllerTests x1000
Change-Id: Ic949efc4e53abe2a580eb5c410f5905f0361a75a
Fixes: 62037783
indowTestsBase.java
|
| cfeff74317f19d5b90335c3e458ef055bdbd17cd |
23-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix starting window leak when adding/removing quickly
The following race condition may happen when transferring starting
windows:
- Add thread (android.anim) calls Snapshot.create
- Remove thread (android.display!) checks that yes there is a
starting window, but no surface yet. Thus, it nulls out everything.
- Add thread returns from Snapshot.create: container.startingData
is null but startingWindow is also null. Thus, we never set
abort=true and we never set the starting window properly or remove
it properly.
Test: Some basic starting window sanity testing. Otherwise, pray
to the race condition gods.
Test: AppWindowContainerControllerTests#testAddRemoveRace
Fixes: 37888853
Change-Id: Ia287bfa52f708b36ff93ef7cd45a0d080bd4dd9c
ppWindowContainerControllerTests.java
|
| ff4cc4ebb516a39c6f3252a240a57646c3354484 |
19-May-2017 |
Keun-young Park <keunyoung@google.com> |
Merge "Wait for keyguard draw before stopping boot animation" into oc-dev
|
| 4136d2d54b986a09b237aee30974d3c00d308338 |
08-May-2017 |
Keun-young Park <keunyoung@google.com> |
Wait for keyguard draw before stopping boot animation
- Add check for keyguard drawn before stopping boot animation.
Otherwise blank screen can happen.
- Bind to keyguard service when sysui is launched to reduce waiting
time later.
- Increase keyguard timeout to 5 secs if it is not boot completed.
Otherwise (= normal screen on), keep the current 1 sec.
This timeout can still lead into blank screen so use bigger timeout
during boot-up to prevent such case.
bug: 37867510
Test: many reboots
Change-Id: Ibfdc42d295bb1d3f5b4ea316fe5aca9ab875e4be
estWindowManagerPolicy.java
|
| 64900ad13ccaa78b163d73783d484ccc4a7c607d |
19-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Take snapshot when screen is turning off" into oc-dev
|
| 009d0460f055b5e7fc7922891058d1189a7fbe59 |
19-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Purge StoreWriteQueue items to avoid system health issues" 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
estWindowManagerPolicy.java
|
| ef3651cff41b929b2fc0c3bd6effe93257f4d831 |
18-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Purge StoreWriteQueue items to avoid system health issues
If queue gets too deep we may run out of memory or cause other
system health issues.
Test: TaskSnapshotPersisterLoaderTest
Bug: 38416992
Bug: 37631016
Change-Id: I725c9a458f78af2e625f2451bb0030176035f596
askSnapshotPersisterLoaderTest.java
|
| 5a270bcd6665c705b9b761f8e956356fb492218e |
18-May-2017 |
Andrii Kulian <akulian@google.com> |
Merge "Don't report displays that are going to be removed" into oc-dev
|
| c7a31d197028bb537cdd01e195cf1fbacd259f2d |
17-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Use ArrayList as children" 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
isplayContentTests.java
|
| 612bb885bcef87034070e8e3bfc0b0e953c0f606 |
16-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Use ArrayList as children
Such that traversal is O(n) instead of O(n²)
Test: WindowContainerTests
Bug: 32668632
Change-Id: Ie52026a76a0f65c71ff6bd35d13b3d0c5d44bb3f
indowTestUtils.java
|
| 70aa4d18be4865ef28795aa9e78f6b36ac437d8a |
15-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Also add starting window when activity is not alive
The fact whether the process is running or not is not necessarily
a reason to not show a starting window. Sometimes the process with
an activity gets killed, but later gets restarted because of some
broadcast or service without recreating the activity. In this
case, we still need a splash screen to hide the recreation delay,
which is usually as expensive as if the process is not running.
Test: Open Calendar, kill `pid calendar`, reopen it, make sure
starting window is shown.
Test: As above but with a couple of other apps - with and widhout
trampoline activities.
Test: Boot freshly and open a couple of apps from recents
Change-Id: I8c4f928fca77b5446cab55c89bc69adbaaaa8da3
Fixes: 37951698
ppWindowContainerControllerTests.java
|
| 027f4753bcdbef5a830ed877f974701727e98d19 |
12-May-2017 |
Wale Ogunwale <ogunwale@google.com> |
Fixed exceptions during test tearDown
- Acquire WM lock when tearing down test. Prevent the handler thread
from modifying state at the same time.
- Don't set surface boundaries on window states without a surface
control.
- Avoid exception if process can read screen-edge-insets for Pip.
Change-Id: If4a2438032866eaec84ed79c30c1d716e0f89758
Fixes: 38113905
Test: this is it!
indowTestsBase.java
|
| 39791594560b2326625b663ed6796882900c220f |
26-Apr-2017 |
Bryce Lee <brycelee@google.com> |
Prevent non-fullscreen activities from influencing orientation
This changelist enforces that activities targeting O and beyond
can only specify an orientation if they are fullscreen. The
change ignores the orientation on the server side and throws an
exception when the client has an orientation set in onCreate or
invokes Activity#setRequestedOrientation.
Fixes: 33483680
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsServicesHostTestCases android.server.cts.ActivityManagerAppConfigurationTests#testNonFullscreenActivityProhibited
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsServicesHostTestCases android.server.cts.ActivityManagerAppConfigurationTests#testLegacyNonFullscreenActivityPermitted
Change-Id: I4f7f79744918fad6465a537633dfadec8d05c6df
ppWindowTokenTests.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
indowTestUtils.java
|
| 2ecf42f96c9d9ee0d1c849cc8961d703dc037e10 |
04-May-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Added TaskSnapshotCacheTest back to presubmit" into oc-dev
|
| bf08eb6da7d37b9ef035975068187905afe2d975 |
03-May-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix snapshots for secure windows" into oc-dev
|
| 68e882ce7f64d12a61de4f0a27403ecb3b70efae |
03-May-2017 |
Wale Ogunwale <ogunwale@google.com> |
Added TaskSnapshotCacheTest back to presubmit
The problem the test was having was fixed by ag/2179887
Also, fixed NPE during test tear down.
Change-Id: I974fcb9a12928dd4494525f9bae5c7c448657e30
Fixes: 35196891
Bug: 37682538
Test: TaskSnapshotCacheTest
askSnapshotCacheTest.java
askSnapshotPersisterTestBase.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
askSnapshotControllerTest.java
askSnapshotSurfaceTest.java
|
| 42bab7897f16c884d5c40ccc8a09f3e9f3338a65 |
02-May-2017 |
Wale Ogunwale <ogunwale@google.com> |
Disable flaky DisplayContentTests#testFocusedWindowMultipleDisplays
Reduce pre-submit noise. We can re-enable once we figure-out why it
is flaky.
Bug: 37908381
Test: disabled!
Change-Id: Ia82ba73fafafc433487027f2ee2d582dceb65ed2
isplayContentTests.java
|
| e163126d2e27ce1fbd5c74279dfb5d05c97b8392 |
29-Apr-2017 |
Wale Ogunwale <ogunwale@google.com> |
Don't try to create user for task snapshot tests
Seems user creation can fail in test harness some times.
Also, I am not sure there is a need to create a user in this
case when we can just use the user id of the current process.
Also removed SettingBackupTest from @Presubmit since it is still
failing.
Bug: 37684646
Bug: 37682538
Test: SettingsBackupTest
Test: TaskSnapshotPersisterLoaderTest
Change-Id: I523bb576217f7782027741916f9ea14fc6d7fb50
askSnapshotPersisterLoaderTest.java
askSnapshotPersisterTestBase.java
|
| 11cc516a925ac7fc814dbb0a79a7f0abfbfe1ce1 |
26-Apr-2017 |
Wale Ogunwale <ogunwale@google.com> |
Reduce use of static variables in window manager unit tests
This was causing test cross-contamination since different test might
expect different states from the variables.
Bug: 37682538
Test: tons of it!
Change-Id: Ie8a1ea400695b6346d7dfa3369b5c44bb467a33d
ppBoundsTests.java
ppWindowContainerControllerTests.java
ppWindowTokenTests.java
isplayContentTests.java
tackWindowControllerTests.java
askPositionerTests.java
askSnapshotCacheTest.java
askSnapshotControllerTest.java
askStackContainersTests.java
askStackTests.java
askWindowContainerControllerTests.java
estWindowManagerPolicy.java
nknownAppVisibilityControllerTest.java
indowContainerControllerTests.java
indowFrameTests.java
indowLayersControllerTests.java
indowTestUtils.java
indowTestsBase.java
indowTokenTests.java
|
| aca246565a7426654685ff0653519f40af8a3b01 |
20-Apr-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Delay PiP transition to fullscreen until activities draw." into oc-dev
|
| ecc06b32305ac234db24e3f76bcae0199b80c395 |
18-Apr-2017 |
Robert Carr <racarr@google.com> |
Delay PiP transition to fullscreen until activities draw.
To avoid awful stretching.
Bug: 37473110
Test: Transition app fullscreen verify no awful video stretching.
Change-Id: I810a72207e45b8f83a63c9f0b3cc9a433569852c
oundsAnimationControllerTests.java
|
| 467deff7e949d99451cd74c98bfbcc11e7a7e8f0 |
18-Apr-2017 |
Bryce Lee <brycelee@google.com> |
Merge "Allow at most one pinned stack task." into oc-dev
|
| 04ab3466fabb7244660adf54740a4f60874b02a1 |
11-Apr-2017 |
Bryce Lee <brycelee@google.com> |
Allow at most one pinned stack task.
This changelist enforces only one task may be present in the pinned
stack at a time. If a task is already persent, the existing task is
moved to the fullscreen stack.
Fixes: 36844394
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsServicesHostTestCases android.server.cts.ActivityManagerPinnedStackTests#testPipMovedToFullscreenStack
Test: bit FrameworksServicesTests:com.android.server.am.ActivityStackSupervisorTests#testDisallowMultipleTasksInPinnedStack
Change-Id: Iaf0fbda6df835d93738fdf6f7f3a8c5956c2b262
estWindowManagerPolicy.java
indowTestUtils.java
|
| 11139e913c3b4897c6ff37606e614d3db1f23418 |
17-Apr-2017 |
Winson Chung <winsonc@google.com> |
Merge "Schedule PIP mode changes at the beginning/end of the transitions." into oc-dev
|
| 22d4ef008dd1956424f1026f151930ccd47d7db6 |
17-Apr-2017 |
Bryce Lee <brycelee@google.com> |
Merge "Don't allow stacks above pinned stack." into oc-dev
|
| 8bca9e47c17c86a3092d5384b14713c5b50dd78c |
17-Apr-2017 |
Winson Chung <winsonc@google.com> |
Schedule PIP mode changes at the beginning/end of the transitions.
- When transitioning from fullscreen to PiP, ensure all PiP/MW/Config
changes come after the transition completes, and inversely, from PiP to
fullscreen, ensure that all changes come before the transition up starts
- Add a series of tests to verify the callback state when the animation
is canceled
- Also fixes an issue where the surface is preserved when we don't want
Bug: 37169080
Bug: 37103000
Test: bit FrameworksServicesTests:com.android.server.wm.BoundsAnimationControllerTests
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: I6425c95df358358ed76d9cc8a130606c2124062e
oundsAnimationControllerTests.java
|
| 2719cc134e68e4c8f0def68fdc1d68dc3de9c1d8 |
14-Apr-2017 |
Wale Ogunwale <ogunwale@google.com> |
Move stack to front in-sync with task reparenting
When reparenting a task to another stack have window manager move the
destination stack to the front at the same time it is reparenting the
task if REPARENT_MOVE_STACK_TO_FRONT is set to avoid jank.
Test: manual
Bug: 37299899
Change-Id: I45678e742188a4871f93a11178f7ab2b60c7bcc3
askWindowContainerControllerTests.java
|
| 19953caad316a6afc6446bb268bdc062a3f5ab90 |
11-Apr-2017 |
Winson Chung <winsonc@google.com> |
Tightening up rotation behavior for PIP (2/3)
- Change BoundsAnimationController to be more consistent:
1) Ensure that on animation end is always called even when cancelled to
ensure animation start/end parity in the callbacks
2) Ensure that setPinnedStackSize() is only called between start/end
3) Prevent calling setPinnedStackSize() to the final bounds if the
animation is cancelled
- With that, we add a flag to cancel the current bounds animation when a
rotation happens while the bounds are animating. In addition, we also
add a check from AM to WM before applying the resize during the animation
in the case where WM sends the bounds to AM, but AM lock is held while
updating the exact stack bounds (once that finishes the old stale bounds
would have been applied)
- In addition, we can then move the handling of the of the rotation to the
config change update in WM, if we handle it before the other checks.
Bug: 36879891
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: I62c6df8b349971cc82a7898ae8b26834723faec5
oundsAnimationControllerTests.java
|
| fe99773a70e6bdfb141cafa06c91760a9264354e |
12-Apr-2017 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Disallow task snapshot starting window for intent != ACTION_MAIN" into oc-dev
|
| bae01b1a70dd721e7343265bedfceee39bdc39f1 |
12-Apr-2017 |
Jorim Jaggi <jjaggi@google.com> |
Disallow task snapshot starting window for intent != ACTION_MAIN
We don't want to show a task snapshot if the intent wasn't the
launcher intent. Likely the app will show something different, so
we shouldn't show a snapshot in this case.
Test: AppWindowContainerControllerTests
Test: Open app, make sure we get snapshot window
Test: Open Chrome, go home, Open chrome incognito from shortcut,
make sure no flash
Change-Id: Ib608ba8070ce09f418f1036248d81eebfa354128
Fixes: 35099602
ppWindowContainerControllerTests.java
|
| cdef591e52e691a6f57e367caa5670fdc4ee1a8a |
03-Apr-2017 |
Jorim Jaggi <jjaggi@google.com> |
Improve caching behavior of thumbnails
Remove the retrieval cache on system_server. It's not needed at
this point.
Instead, we cache the low-res thumbnails on SystemUI side that
will be visible when recents launches. For that, we introduce
a strong thumbnail cache, which gets filled up whenever the task
stack changes.
Also fix a couple of issues like that the visibility report was
pretty wrong as well as some tasks got unloaded because tasks were
bound before layout happend.
Also fix a merge issue where we didn't load the reduced resolution
thumbnail :/
Test: TaskSnapshotCacheTest
Test: Open a couple of apps, open recents, make sure all
thumbnails are already loaded.
Fixes: 36374895
Change-Id: Idbf1acd4ceab6a7c4656e9791e245a8b102017f2
askSnapshotCacheTest.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
isplayContentTests.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
askSnapshotSurfaceTest.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
isplayContentTests.java
tackWindowControllerTests.java
|
| ed7993b5d147a6741d26fe0b16cc9fa5e34ceaee |
28-Mar-2017 |
Jorim Jaggi <jjaggi@google.com> |
Introduce android.anim thread in system_server
We create a new thread on which everything is running that
directly impacts window animations, i.e. layout, anim tick and
starting window creation. This is such that any work on
android.display can not lead to jank in the window animation,
specifically lock contention on activity manager lock that blocks
callbacks from android.display into AM can not lead to window
animation jank.
Test: Run animation, take systrace, make sure animation is on
android.anim
Test: AppWindowContainerControllerTestTest: AppWindowContainerControllerTestss
Fixes: 36792959
Change-Id: I5d41419a709b7984724e7053a3afdcc1ffe1aaa2
ppWindowContainerControllerTests.java
indowTestsBase.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
askSnapshotSurfaceTest.java
|
| 1edadac465f70629c66b0c9b053b8ac154133ec9 |
04-Apr-2017 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Handle case when snapshot dimensions don't match" into oc-dev
|
| 9f467df80493159c2a367ef8d08c79a14a7d52aa |
04-Apr-2017 |
Bryce Lee <brycelee@google.com> |
Merge "Clean up activity/stack associations." into oc-dev
|
| af691c0be7bbfea63e880dd717c51a38a0bc874a |
20-Mar-2017 |
Bryce Lee <brycelee@google.com> |
Clean up activity/stack associations.
The stack currently holds a reference to resuming and pausing
activities. These are usually cleaned up when the activity ends or
the task is reparented. However, it is possible for an activity to
lose its reference to its task in other areas (such as
ActivityStarter), which can lead to the stack not being updated
correctly.
This changelist adds a method to the ActivityStack to disassociate
the stack from an ActivityRecord. In addition to places where this is
called when an activity ends, this method is invoked on the children
of a task when the task is reparented. The task member variable of
ActivityRecord is also now surrounded by a setter/getter, with the
setter always invoking the dissociation logic on a previous stack.
Test: bit FrameworksServicesTests:com.android.server.am.ActivityRecordTests
Change-Id: Iffeccdb6f011958896271673946acfed28856f53
Fixes: 36387417
ppWindowContainerControllerTests.java
ppWindowTokenTests.java
isplayContentTests.java
tackWindowControllerTests.java
askStackContainersTests.java
askStackTests.java
askWindowContainerControllerTests.java
nknownAppVisibilityControllerTest.java
indowFrameTests.java
indowTestUtils.java
indowTestsBase.java
indowTokenTests.java
|
| 2c93764bee6c00526fda24a26f8a472c26d908c3 |
03-Apr-2017 |
Andrii Kulian <akulian@google.com> |
Merge "Fix some WM unit tests" into oc-dev
|
| 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
askSnapshotSurfaceTest.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
ppBoundsTests.java
|
| a95bfff74604bbf05a66ff37947b1b2fb2fdcaa2 |
31-Mar-2017 |
Andrii Kulian <akulian@google.com> |
Fix some WM unit tests
WindowFrameTests#testLayoutNonfullscreenTask and
sizes because test assumed that frame for window was always
bigger than screen size. Now we calculate all frames relative
to real display size.
TestWindowManagerPolicy used in WM unit tests reported incorrect
value from rotationHasCompatibleMetricsLw(), which lead to
DisplayContent#mAltOrientation set to "true" after any rotation
and resulted in shrinked display metrics.
DisplayContentTests#testDefaultDisplayOverrideConfigUpdate was
not restoring the config applied to default display because
it was trying update values in config from non-empty to empty,
which is considered a no-diff.
Test: com.android.server.wm.WindowFrameTests
Test: #testCalculatePolicyCrop
Test: #testLayoutNonfullscreenTask
Test: com.android.server.wm.AppWindowTokenTests
Test: #testLandscapeSeascapeRotationByApp
Test: com.android.server.wm.DisplayContentTests
Test: #testDefaultDisplayOverrideConfigUpdate
Change-Id: Ia0ed46307f67f6b47859209ebcf13253b59b8002
isplayContentTests.java
estWindowManagerPolicy.java
indowFrameTests.java
|
| ac52f2892d5c72c26387d510093ddfc741a8a632 |
30-Mar-2017 |
Winson Chung <winsonc@google.com> |
Ensure we show the PiP menu in response to KEYCODE_WINDOW.
Bug: 36687605
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testWindowButtonEntersPip
Change-Id: I0bb35fd666eb6a438e4676267f6726b44bffb3db
estWindowManagerPolicy.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
isplayContentTests.java
|
| e259c2c42be68fa2ead28eeed1df5042452d0eae |
27-Mar-2017 |
David Stevens <stevensd@google.com> |
Merge "Compute the focused window in display focus order"
|
| 469395638813abdb7423d0b91d6c42c2b1dcb78a |
24-Mar-2017 |
David Stevens <stevensd@google.com> |
Compute the focused window in display focus order
A WindowContainer's children are sorted so the focused child is at the
end of the list, so RootWindowContainer needs to iterate from end to
start when looking for the focused window.
Bug: 36590788
Test: DisplayContentTests#testFocusedWindowMultipleDisplays
Change-Id: I56e6b7d2054bc1e74b54a4f99706a08d278fa2e1
isplayContentTests.java
indowTestsBase.java
|
| 5e5a68dc063a3692ec8dcd9c07c9861680a18a52 |
25-Mar-2017 |
Wale Ogunwale <ogunwale@google.com> |
Fixed issue with SCREEN_ORIENTATION_BEHIND not working correctly
If an app specifies SCREEN_ORIENTATION_BEHIND, then use the orientation
of the app behind it regardless of the visibility state of the app
behind.
Fixes: 35281868
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerTests
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowTokenTests
Test: bit FrameworksServicesTests:com.android.server.wm.TaskStackTests
Change-Id: Ieba4e4bb1a7f47cd6f082491d37fcabcf5bd5199
ppWindowTokenTests.java
askStackTests.java
indowContainerTests.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
indowContainerTests.java
indowFrameTests.java
indowTestsBase.java
|
| c344373ed49c768f3b1cc8486c6ab376e5ef5256 |
22-Mar-2017 |
Bryce Lee <brycelee@google.com> |
Merge "Do not allow Tasks to influence orientation under some conditions."
|
| 541feb1ccf753a9db24109d38135ef1144080774 |
22-Mar-2017 |
Jorim Jaggi <jjaggi@google.com> |
Merge "When snapshots are disabled, fill it with single color."
|
| a359c9846d2fa8bfe2784222be350d2e6046de16 |
22-Mar-2017 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Add API to disable snapshotting of activities"
|
| 61fbcbcc94d1ca949afae47ec0ec7a8da80aadef |
10-Mar-2017 |
Bryce Lee <brycelee@google.com> |
Do not allow Tasks to influence orientation under some conditions.
When all AppWindowTokens belonging to a Task are closing, it should
not be considered for orientation. Likewise, if a task is moving to
the bottom, it should also not be considered.
Change-Id: Ie387457c413d5360afbb0ac8edb112f81feab81b
Fixes: 35699615
Test: bit FrameworksServicesTests:com.android.server.wm.TaskStackTests#testClosingAppDifferentStackOrientation
Test: bit FrameworksServicesTests:com.android.server.wm.TaskStackTests#testMoveTaskToBackDifferentStackOrientation
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsServicesHostTestCases android.server.cts.ActivityManagerAppConfigurationTests#testTaskCloseRestoreOrientation
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsServicesHostTestCases android.server.cts.ActivityManagerAppConfigurationTests#testTaskMoveToBackOrientation
askStackTests.java
|
| 8f4fe6eccbc3849686f08389cb5868f2d59f5fbb |
14-Mar-2017 |
Jorim Jaggi <jjaggi@google.com> |
When snapshots are disabled, fill it with single color.
Test: Launch DisableScreenshotsActivity, go to recents, make sure
content is blue. Reopen activity from home, make sure starting
window is blue.
Bug: 31339431
Change-Id: I29689774c3cdcb784d8f5bfa4f947a6f35b91e01
askSnapshotControllerTest.java
|
| 0fe7ce968bc7f0eff64f08e2d51c8b1e6b4a6fc8 |
22-Feb-2017 |
Jorim Jaggi <jjaggi@google.com> |
Add API to disable snapshotting of activities
Test: runtest frameworks-services -c
com.android.server.wm.TaskSnapshotControllerTest
Test: Launch DisableScreenshotsActivity, go to recents, make sure
content is white.
Bug: 31339431
Change-Id: I329925d2fca389e561da3389a67fe888b5bb1033
askSnapshotControllerTest.java
indowTestsBase.java
|
| 2dde2b122f620ba853d950cc1b88ae0596d958f6 |
21-Mar-2017 |
Jorim Jaggi <jjaggi@google.com> |
Merge changes I7f7a9842,I4c74b269
* changes:
Implement new thumbnail loading strategy
Also store reduced resolution screenshots
|
| 35e3f53a30588b79e0309fdbeef29a8c18eef65d |
17-Mar-2017 |
Jorim Jaggi <jjaggi@google.com> |
Also store reduced resolution screenshots
In order to speed up loading time when scrolling through it
in recents. They will be used in recents in the next CL. Also, we
use JPG instead as loading JPG is much faster than PNG.
Test: TaskSnapshotPersisterLoaderTest
Test: TaskSnapshotCacheTest
Bug: 34829962
Change-Id: I4c74b26969ae459bd3b1a42707011a49f425abd9
askSnapshotCacheTest.java
askSnapshotPersisterLoaderTest.java
askSnapshotPersisterTestBase.java
|
| 6272c7f83fd1e78ec610d84621abfd0b87680465 |
18-Mar-2017 |
Bryce Lee <brycelee@google.com> |
Do not remove the default display during tests.
The default display is used by some tests that exercise features only
functional only on the default display (like policy rotation). This CL
makes this display not get removed with the created test displays and
ensures no collision in id space from a previous test run (done in the
test setup).
Change-Id: Ia14b9c023c779d263283fe8c7b512dca17ff312f
Fix: 36385757
Test: bit FrameworksServicesTests:com.android.server.wm.StackWindowControllerTests#testRemoveContainer_deferRemoval
ppWindowTokenTests.java
indowTestsBase.java
|
| c1b59ed73eeea40c70cc81e2ab486cd54d94ed5d |
17-Mar-2017 |
Andrii Kulian <akulian@google.com> |
Merge "Separate global and override config sent to client"
|
| 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
estIWindow.java
|
| 6b9b130c9823f4473ccc374e853e19a5ed35a992 |
16-Mar-2017 |
Bryce Lee <brycelee@google.com> |
Merge "Fix AppWindowTokenTests#testLandscapeSeascapeRotationByPolicy"
|
| 310de9e5ee7b57b928e7a6613d61bcfb1c0bf166 |
15-Mar-2017 |
Bryce Lee <brycelee@google.com> |
Fix AppWindowTokenTests#testLandscapeSeascapeRotationByPolicy
Previously this test was marked as blocked by b/35034729. This bug
has been fixed, however the test still fails due to other issues
addressed here.
Addressed issues are as follows:
1. Updating rotation by display manager requires a display with the
default display id present. This display is removed during setup. The
first id to be used by a display after this point is the
default id + 1. We already have logic in place to avoid collisions so
it is safe and correct to start out at the default id.
2. Without allowing the animator to complete its steps after a
rotation, future rotations will be deferred. We must simulate the
steps taken by the and resulting from the animtor. These include
marking the orientation change as complete and performing a surface
placement afterwards.
Bug: 35034729
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowTokenTests
Change-Id: Ib01c047ac49982a4a3c1debaa3cee1b7b9b53632
ppWindowTokenTests.java
indowTestsBase.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
ppWindowTokenTests.java
|
| 192bb0bc54f6bb418f5778fe26eb2e68514290fb |
09-Mar-2017 |
Paul Duffin <paulduffin@google.com> |
Refactor code incompatible with Mockito 2.7.13
(cherry picked from 76e319f015c2b43498ce3ce610a253d63e76cbf3)
Some additional internal only refactorings were done as well.
Bug: 32912773
Test: make checkbuild
Change-Id: I96e3da967fad731fc8f39bde9db95f50ab7353fb
estWindowManagerPolicy.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
isplayContentTests.java
indowTestsBase.java
|
| 455e90add22835d0744fc0f5c2feb5fcaf03b28f |
10-Feb-2017 |
jackqdyulei <jackqdyulei@google.com> |
Add BatterySaverPolicy for power save mode
The BatterySaverPolicy is designed to consolidate all battery saver
knobs into a central location. Usually it is consistent to
mLowPowerModeEnabled unless it gets different data for specific
service. By adding these knobs, we can effectively tune the battery
saver.
This cl sets up the framework for BatterySaverPolicy and updates
following service to get battery saver data from BatterySaverPolicy
1. GnssLocationProvider
2. VibratorService
3. WindowManagerService
4. BackupManagerService
5. SoundTriggerService
6. NetworkPolicyManagerService
Screen brightness will come in a following cl.
Bug: 34693888
Test: FrameworksServicesTests
Change-Id: I6b040e93391614b44d136a485faa4a332c396e51
estWindowManagerPolicy.java
|
| 7fbeb8a5d754c7e5c330458cf241c5e2a718099c |
02-Mar-2017 |
Bryce Lee <brycelee@google.com> |
Remove mTask from AppWindowToken.
mTask was a duplicate reference to the WindowContainer's parent. The
main benefit of this refenrece was type, as its callers require an
instance of type Task.
With the introduction of the method getTask, we can shift away from
this variable and instead directly cast the parent here. If the
window hierarchy changes in the future (such as AppWindowToken parent
types not being Task), we can re-evaluate and adjust how task is
returned.
Test: manual
Change-Id: Idd6bba1121056ed79745911efe838edfa685bbf2
indowTestsBase.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)
ppWindowContainerControllerTests.java
isplayContentTests.java
askSnapshotControllerTest.java
indowTestsBase.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
indowTestsBase.java
indowTokenTests.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
isplayContentTests.java
indowTestsBase.java
|
| b327a4a34e9128d9a758232edbf9d06de53364fa |
21-Feb-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fixed issues with child windows been IME targets"
|
| 342479581e113a6cf05f6e1d6470a86ad6032bcb |
19-Feb-2017 |
Wale Ogunwale <ogunwale@google.com> |
Fixed issues with child windows been IME targets
- Fixed issue with WindowState.getWindow() returning the parent window before
its children with positive sub-layers. Positive sub-layer children should be
returned first, then the parent window, and then negative sub-layer children.
This was causing the the parent window to be selected as the IME target
instead of the child on-top of it since they both can be IME targets and the
parent window was returned first.
- Fixed issue with WindowState.forAllWindow() not returning the IME window if
the current IME target is a child window.
- Add test WindowStateTest.testGetWindow(),
DisplayContentTests.testForAllWindows_WithChildWindowImeTarget(), and
DisplayContentTests.testComputeImeTarget() to cover the failing cases.
Change-Id: I0c93e0344601fc870011e8a8d84528f62b0a2a06
Fixes: 34786357
Fixes: 34306127
Fixes: 34711958
Fixes: 35362942
Test: bit FrameworksServicesTests:com.android.server.wm.WindowStateTests
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
isplayContentTests.java
indowStateTests.java
indowTestsBase.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
estIWindow.java
|
| 12cb6628dbfc2f50a04502f37386d453956a02e3 |
13-Feb-2017 |
Winson Chung <winsonc@google.com> |
Merge "Create a new stack for the assistant activity."
|
| 4a73a224234a66dcbf597f83121ca9cd4692311e |
13-Feb-2017 |
Wale Ogunwale <ogunwale@google.com> |
Removed TaskSnapshotCacheTest from presumbit
Until b/35196891 is fixed.
Bug: 35196891
Test: TaskSnapshotCacheTest
Change-Id: I636b1da5149e45f24ef740d0d7619743856d6df4
askSnapshotCacheTest.java
|
| 8347163dbb64fb61012c0393163283106a0a351e |
13-Dec-2016 |
Winson Chung <winsonc@google.com> |
Create a new stack for the assistant activity.
- Add a new stack that is not resized with multiwindow, and
appears above the fullscreen and docked stacks, but below
the pinned stack
- Add a method on VoiceInteractionSession to allow the assistant
to launch activities into this new fullscreen stack.
- Also prevent any activities in the assist stack from the
fetching of the on screen assist data.
Bug: 30999386
Test: android.server.cts.ActivityManagerAssistantStackTests
Change-Id: I22ab7629b5f758cf1e66d7d1c26648af6bc887c9
indowLayersControllerTests.java
indowTestsBase.java
|
| f2ecbbc35ee4119839e830f0c55657465fb1e11d |
10-Feb-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix WindowFrameTest error."
|
| 186d9dee1bea76d3af1cfff0213925245d28c54b |
09-Feb-2017 |
Robert Carr <racarr@google.com> |
Fix WindowFrameTest error.
It appears somehow we are using real display sizes and it varies from
device to device. This itself is somewhat concerning, but easy enough
to handle. If you look at the line before the modified lines
it seems like this is what I meant to do initially but somehow it didn't happen.
Test: bit FrameworksServicesTests:com.android.server.wm.WindowFrameTests
Fixes: 35197592
Change-Id: I05880ba95a8ee3b790fb14daf00c878b4f85095c
indowFrameTests.java
|
| 17f175ca1a75d5a4864b88126f5d2a59935d52fd |
08-Feb-2017 |
Wale Ogunwale <ogunwale@google.com> |
Fixed failing WM pre-submit tests
- Pre-submit wasn't really enabled so several changes were merged in
that caused test failures
- Specify that AppWindowTokenTests token fill their parent since that
is important for the orientation tests it runs
- Disable testLandscapeSeascapeRotationByPolicy() until we have time
to figure-out the problem with the test.
- Initialize ActivityManagerInternal local service mock when we
initialize the test object for window manager.
- Changed UnknownAppVisibilityControllerTest to use test
infrastructure in WindowTestsBase.
- Fixed testGetOrientation_childSpecified to check the correct expected
state.
- Allow testAssignWindowLayers_ForImeNonAppImeTarget to create an alert
window at internal system window z-order.
- Remove all non-common windows for the system after each test run.
Bug: 35034729
Test: adb shell am instrument -w -e package com.android.server.wm
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I4726811e382b18fbef6b9d9b12a5ee56776628e4
ppWindowTokenTests.java
askPositionerTests.java
estWindowManagerPolicy.java
nknownAppVisibilityControllerTest.java
indowContainerTests.java
indowLayersControllerTests.java
indowTestsBase.java
|
| 069bbd382898d3330d284912b3a472495045c363 |
03-Feb-2017 |
Wale Ogunwale <ogunwale@google.com> |
Removed android.R.attr#onTopLauncher
The product that the feature was intended for never launched, so
removing the complexity from the code base.
Test: builds
Change-Id: I75e60ee2da46f6012f03a6077f77bc6b9acecad5
indowFrameTests.java
indowTestsBase.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
estWindowManagerPolicy.java
indowFrameTests.java
indowTestsBase.java
|
| a163b76570d15e0bbfd318b2962c4966a8a538e5 |
24-Jan-2017 |
Bryce Lee <brycelee@google.com> |
Allow opening activity to specify orientation.
An activity's window is initially not visible. This means it is not
accounted for until it becomes visible, which means requested
orientations will not be honored until after onCreate.
This changelist removes the visibility check previously used determining
the orientation.
This changelist also addresses an issue where an ActivityRecord member
variable tracking the last configuration sent was not being initially
updated.
Fixes: 33844887
Fixes: 33814250
Fixes: 34165818
Fixes: 34177026
Fixes: 33809086
Fixes: 34111451
Fixes: 33844423
Test: Verified reported issues fixed in apps mentioned in bugs
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerTests
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test android.server.cts.ActivityManagerAppConfigurationTests
Change-Id: If9243792b9f2d137dc5addbf6fb735a0048fa192
indowContainerTests.java
|
| ffc7b784348282b7641cf973012b0f67190cecf9 |
27-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Reparent the activity in the task with associated window containers."
|
| 3048004087968674c3af97e1c0b110a223f04703 |
26-Jan-2017 |
Winson Chung <winsonc@google.com> |
Reparent the activity in the task with associated window containers.
- Currently moveActivityToStack() adds the activity to the top of the
new task in the new stack, but the code path to update the window
container controllers assumes that they are in the same task and
attempts to position it by index. Instead, we should properly
reparent the activity in the new task (just like we reparent tasks
into new stacks), and also reparent the associated app window tokens
into their new tasks on the WM side.
- Also should fix an issue when trying to reparent an activity from one
task to another task by affinity.
Bug: 34394702
Test: AppWidgetContainerControllerTests#testReparent
Test: android.server.cts.ActivityManagerPinnedStackTests#testEnterPipFromTaskWithMultipleActivities
Change-Id: Ib767f85eb4f469cfd1c108c55242996325bdb866
ppWindowContainerControllerTests.java
indowTestsBase.java
|
| c24bb2c4a6cd9a618453f2c72145656c1287cf1b |
26-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix shared dim layer not cleared when all users removed"
|
| 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
imLayerControllerTests.java
isplayContentTests.java
tackWindowControllerTests.java
askWindowContainerControllerTests.java
indowTestsBase.java
|
| 3787de16d24001eeb452e1c711d4290a396e67c9 |
21-Dec-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Implement pointer capture API
When in pointer capture mode, mouse pointer disappears and
further mouse events are dispatched to the focused view
in the window which has requested capture.
The captured events have the source SOURCE_MOUSE_RELATIVE
belonging to SOURCE_CLASS_TRACKBALL. They are
dispatched through dispatchCapturedPointerEvent /
onCapturedPointerEvent. There is also a new listener.
Pointer capture mode may only be granted to a currently
focused window, and will be canceled upon a window focus change.
Test: cts-tradefed ... --test android.view.cts.PointerCaptureTest
Bug: 30897034
Change-Id: I6e5934aa415ac2b6dda1cee173d0f23e5021af84
estIWindow.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.
ppWindowTokenTests.java
isplayContentTests.java
tackWindowControllerTests.java
askStackContainersTests.java
askWindowContainerControllerTests.java
indowTestsBase.java
|
| d339538a67b7d6bb3d7ad73f31ad20ffc932f891 |
13-Dec-2016 |
Winson Chung <winsonc@google.com> |
Remove dependency on resizable activity to enter PiP.
- Removing the requirement for activities to have both the
resizeableActivity and supportsPictureInPicture attribute
to enter PiP. The activity may still be resized when
entering picture-in-picture.
Bug: 34256643
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: If6bd4721c53072e5518f554a8c7598705517c132
indowFrameTests.java
indowTestsBase.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
askSnapshotSurfaceTest.java
indowFrameTests.java
indowTestsBase.java
|
| 9bafc7150ea41758cf40ba60eb90deb62217fc34 |
19-Jan-2017 |
Jorim Jaggi <jjaggi@google.com> |
Starting window tests, yay!
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowContainerControllerTests
Fixes: 34364463
Fixes: 34361417
Change-Id: Ie1b8debc894e5cad8fe517912a1991a38661dfaa
ppWindowContainerControllerTests.java
estWindowManagerPolicy.java
nknownAppVisibilityControllerTest.java
indowTestsBase.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
|
| 7361babf94baa985eaa8bd2e94fcb16f00670998 |
16-Jan-2017 |
Jorim Jaggi <jjaggi@google.com> |
Implement restoring & correct caching of snapshots
Introduce a retrieval cache that holds the last accessed
snapshots, in addition to the cache of the activities
that are the top most activtiy of a task that have a
running process.
Change everything to use an integer id instead of a Task object
to work around the issue that some tasks SystemUI might access
might not exist in WM yet (not yet restored from recents).
Don't put anything in the cache on the SystemUI side, but still
retrieve the thumbnails after a task changed event to make sure
the cache on the system_server side is fresh.
Test: runtest frameworks-services -c
com.android.server.wm.TaskSnapshotCacheTest
Bug: 31339431
Change-Id: I8e56365459a677735320adaa169da8fb033ceab0
askSnapshotCacheTest.java
askSnapshotPersisterLoaderTest.java
askSnapshotPersisterTestBase.java
|
| 4cbec883f103b9c6bf553ef4f77df492287d30dc |
21-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Set permissions for launching on private displays"
|
| fb1bf69d5d7fc8c45e3ddbb8916e21ae57432ff1 |
17-Jan-2017 |
Andrii Kulian <akulian@google.com> |
Set permissions for launching on private displays
- System UIDs must be allowed to launch anything and everywhere.
- Display owner must be allowed to launch activities on it.
- Apps that are already on target display must be allowed to launch
there.
- All other apps mustn't be allowed to launch on private displays.
Bug: 34230873
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testPermissionLaunchFromSystem
Test: #testPermissionLaunchFromAppOnSecondary
Test: #testPermissionLaunchFromOwner
Test: #testPermissionLaunchFromDifferentApp
Change-Id: Ic98005649a6368370c512e822cba4e9decc18ae9
estWindowManagerPolicy.java
|
| f9084ecae2e0f042730ab32b9c94204a0e21bb2a |
16-Jan-2017 |
Jorim Jaggi <jjaggi@google.com> |
Persist task snapshots to disk
So they can be used again after rebooting or when the process gets
killed, but the snapshot is still used for recents.
Also implement TaskSnapshotLoader, to restore it from disk. The
infrastructure around restoring and caching snapshots for recents
will be implemented in the next CL.
Test: runtest frameworks-services -c
com.android.server.wm.TaskSnapshotPersisterLoaderTest
Bug: 31339431
Change-Id: Iaec03c4cc92e04b6dd7e623bca755ddc92613bce
askSnapshotPersisterLoaderTest.java
|
| aba241892e204a050562e5889c1b94e0f75eaaeb |
19-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Notify task about display change when moved to new stack"
|
| 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
askStackContainersTests.java
askWindowContainerControllerTests.java
indowTestsBase.java
|
| 2ec59897cf892666146f378825d2adcf972248ac |
18-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge changes I01e81b9c,I532c2d74
* changes:
Add a listener when task snapshots change
When app dies, destroy snapshot
|
| fb9d78afb77b1d304b24f470a637244d52a7e1df |
05-Jan-2017 |
Jorim Jaggi <jjaggi@google.com> |
Add a listener when task snapshots change
Since we start recents before we take the snapshot, we need to add
a mechanism to inform recents about task snapshots changes.
We add a new method to TaskStackChangedListener,
onTaskSnapshotChanged, which gets called whenever a task snapshot
changes. Then, SystemUI registers such a listener and updates the
task thumbnail view for the specific task.
Test: Open app, press recents, make sure thumbnail is up-to-date
Bug: 31339431
Change-Id: I01e81b9cd11886da734da671c68d5732aa51009f
indowTestsBase.java
|
| 10abe2fe297ce1ec60c15a3bd947757aee5b14b3 |
03-Jan-2017 |
Jorim Jaggi <jjaggi@google.com> |
When app dies, destroy snapshot
Also destroy snapshot when we remove the AppWindowToken.
Test: runtest frameworks-services -c
com.android.server.wm.SnapshotCacheTest
Test: Open app, go home, kill app, make sure snapshots are
destroyed.
Change-Id: I532c2d7499a86164175f9fcbc8b77c6eb6bfeae6
askSnapshotCacheTest.java
|
| 059df13f3253dceb9d38c29d708e355221faedab |
17-Jan-2017 |
Andrii Kulian <akulian@google.com> |
Merge "Add unit tests for 180 degree rotation"
|
| c5cc301689649695e03f502e7d1c1492ef5e5d1e |
13-Jan-2017 |
Wale Ogunwale <ogunwale@google.com> |
Have better separation between adding, positioning, and reparenting task
Several methods in activity manager and window manager performed adding,
positioning, and reparenting a task operation and sometimes failed silently
when things don't work due the callers using the methods for a particular
operation, but getting a different operation due to programmer error.
This CL better separate the methods responsible for adding, positioning, and
reparenting a task and also fails hard when there is an error.
Test: bit FrameworksServicesTests:com.android.server.wm.TaskWindowContainerControllerTests
Test: Manual testing existing PiP doesn't leave the device in a bad state.
Bug: 34260633
Change-Id: Id64367da30fc6214eb6f95b2bd5e58ed0e953a88
ppWindowContainerControllerTests.java
askWindowContainerControllerTests.java
indowContainerTests.java
indowTestsBase.java
|
| 4ede3e0d0a9e76c701db19e073d2d1ff487d2a64 |
12-Jan-2017 |
Andrii Kulian <akulian@google.com> |
Add unit tests for 180 degree rotation
These tests if an app window token reports resize when device is
rotated from landscape to seascape.
There is also some additional plumbing to be able to perform a
rotation in unit test. Also dynamic stacks are now allowed to
influence the orientation of the device.
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowTokenTests
Bug: 33607506
Change-Id: I7b23e2de48d56c9fe485eae6a165378dbbbd08bb
ppWindowTokenTests.java
estWindowManagerPolicy.java
indowTestsBase.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
askSnapshotControllerTest.java
estWindowManagerPolicy.java
indowTestsBase.java
|
| 3c6f28aa5968b1edb823495efa15e7358de5261e |
11-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Added TaskWindowContainerController"
|
| b6aa0cc60ccfb4e1d8bd02f5a05ebae15fc55713 |
11-Jan-2017 |
Andrii Kulian <akulian@google.com> |
Merge "Fix typo that caused excessive display config updates"
|
| e1fe7fa288a34ecaaab390f49ef540edc4a6c52d |
16-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added TaskWindowContainerController
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
ppWindowContainerControllerTests.java
askWindowContainerControllerTests.java
indowFrameTests.java
indowTestsBase.java
|
| d68501e66dabe30dd7bb2ac9e50f8cbac29f698c |
11-Jan-2017 |
Andrii Kulian <akulian@google.com> |
Fix typo that caused excessive display config updates
Applied incorrect configuration object while doing original
configuration refactoring.
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
Test: #testDisplayOverrideConfigUpdate
Change-Id: Ief5979feebb50f689b6cb532e1dba93e47dcbc40
isplayContentTests.java
|
| ba41f4b9e3629c097cdd7b6538c5bcf4602728b8 |
15-Dec-2016 |
Jorim Jaggi <jjaggi@google.com> |
Clean up starting window to prepare for saved surfaces
- Move all starting window logic to AppWindowContainerController
- Use startingView to hold any kind of contents for startingWindow
- Remove some conflicting code which looks very old and doesn't
apply anymore.
Test: Make sure starting window still works.
Bug: 31339431
Change-Id: I018dd013ab7e64a44932b6d54ae9bb4a47f315d3
estWindowManagerPolicy.java
|
| f51b4ff7b1ac09b22772dcbdf7ae24b611c37171 |
06-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Make sure cleanup is always done when task is removed"
|
| 45a61fe5296d6fd3b9e2872c5dfc8d01f6a5b455 |
06-Jan-2017 |
Andrii Kulian <akulian@google.com> |
Make sure cleanup is always done when task is removed
When Stack#removeImmediately() was called it also recursively
called Task#removeImmediately(), which remove tasks from stack.
This lead to Task#mStack reference being nullified, but task
dim layer user was still registered in DimLayerController.
Therefore there was a crash when dim layer animation occured.
This CL moves most of the logic from Task#removeIfPossible() to
Task#removeImmediately() to make sure that cleanup is performed
every time when task is removed.
Change-Id: Id8d72dc8c66b9eeefbf5c918cf0a0df4ea027fde
Fixes: 34052466
Test: bit FrameworksServicesTests:com.android.server.wm.TaskStackTests
Test: #testStackRemoveImmediately
askStackTests.java
|
| 26c0dfed7a0cd54abafdd0ccbb5b757506d51c76 |
14-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Support for WindowContainer controllers and listeners
- 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
ppWindowContainerControllerTests.java
nknownAppVisibilityControllerTest.java
indowContainerControllerTests.java
indowContainerTests.java
indowTestsBase.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
askStackContainersTests.java
|
| 77b165f0af2f4c9c5957c122afadec87a012cf41 |
28-Dec-2016 |
Andrii Kulian <akulian@google.com> |
Merge changes I2ac2cdba,I6ade7874
* changes:
Fix crash when removing a display with activities
Add positionChildAt method to WindowContainer
|
| 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
isplayContentTests.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
askStackContainersTests.java
askStackTests.java
indowContainerTests.java
indowTestsBase.java
|
| 46a26a84af520cf9f13874b6c2646f15b38be683 |
16-Dec-2016 |
Jorim Jaggi <jjaggi@google.com> |
Reenable test for presubmit
Bug: 33498346
Change-Id: Ie08b8da82efa897eb80b78e61962031db70b8960
nknownAppVisibilityControllerTest.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
isplayContentTests.java
indowTestsBase.java
|
| 0bb1f8919e9ce5a0f9c7d88806db2fbc8b085fe9 |
13-Dec-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fixed window ordering issue with TYPE_VOICE_INTERACTION."
|
| 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
isplayContentTests.java
indowTestsBase.java
|
| 72919d2c310db04fdb860e926ccb0bfe6e3aef08 |
09-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Untangle creation of Task from addition of AppToken in WM.
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
indowFrameTests.java
indowTestsBase.java
|
| c6dc9b53d80565a2a9d17f84ebf673d310ac70c3 |
10-Dec-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Disabling presubmit tests until they fixed
Test: manual
Bug: 33498338
Bug: 33498346
Change-Id: I50f15d39e2bf1195b192fc882b38601ba2372740
askPositionerTests.java
nknownAppVisibilityControllerTest.java
|
| ea92d977333bef11c6ab243d785a1b2d9c1f66ff |
08-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Don't return null in WS.getTopParentWindow on child detach
Fixed issue with WindowState.getTopParentWindow() returning null when
the child window is removed from it's parent. In this case it should
return itself as the method documentation states.
Change-Id: Iae40ca21241306048cae136887afc88593a6898d
Fixes: 33446267
Test: bit FrameworksServicesTests:com.android.server.wm.WindowStateTests
indowStateTests.java
|
| 6cd5d2f8385fa363edfb8c214b29876321486695 |
08-Dec-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Adding orientation preserving resizing"
|
| 322347ba58f02b960dc87eca3cb0ebe0455c9253 |
02-Dec-2016 |
skuhne@google.com <skuhne@google.com> |
Adding orientation preserving resizing
Adding freeform resizing to activities which require
a certain orientation. This is needed for e.g. ARC++.
Bug: 33267688
Test: runtest frameworks-services -c com.android.server.wm.TaskPositionerTests
Test: Visually on ARC++
Change-Id: If708c1602cb2ff464174389af4648ad767b0b079
askPositionerTests.java
|
| 805d9ecc476134ffafc85a07b05e94a14b1d398c |
07-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Don't allow IME windows to be IME targets
IME targets are required to be below the IME windows and that wouldn't
be possible if the IME window is its own target which leads to issues
elsewhere in the code where that is expected to be the case.
Change-Id: I34a723ff4ce2519cd80e0eea0eaea04712b6cf8f
Fixes: 33336368
Test: bit FrameworksServicesTests:com.android.server.wm.WindowStateTests
indowStateTests.java
indowTestsBase.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
indowStateTests.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
ppWindowTokenTests.java
indowTestsBase.java
indowTokenTests.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
isplayContentTests.java
indowLayersControllerTests.java
indowTestsBase.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
indowLayersControllerTests.java
|
| 84884684feb33086faf82bee14579989379d08ee |
30-Nov-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Some cleanups for window cropping functionality."
|
| fbbde85b045dde25450ce5cef075934102e28339 |
18-Oct-2016 |
Robert Carr <racarr@google.com> |
Some cleanups for window cropping functionality.
At a high level I had two sorts of goals:
1. To remove the weird pinned logic in setSurfaceBoundariesLocked
2. To seperate base crop calculation, and animation exceptions, between
window state and window state animator.
Itemized changes are as follows:
1. Rename updateSurfaceWindowCrop and calculateSurfaceWindowCrop to
applyCrop/calculateCrop. It doesn't feel that "SurfaceWindow" was
adding much.
2. Split screen space and window space (final v non) clip rect
computation, to make clarity about when each one should be used.
3. Eliminate weird case for pinned stack in setSurfaceBoundaries by
building it in to calculateFinalClipRect.
4. Extract calculateSystemDecorRect to WindowState as it mostly accesses
window members.
5. Extract part of calculateCrop to WindowState as
"calculatePolicyCrop". This was the part that fills mSystemDecorRect.
6. Extract wallpaper animation logic outside of calculatePolicyCrop
Test: bit FrameworksServicesTests:com.android.server.wm.WindowFrameTests
Change-Id: I8ff1dc6ec1206a34994f50ba44d765ab619efbff
indowFrameTests.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
indowStateTests.java
|
| 241ae10b2189f449e57d8d660235ac56d8fb1b80 |
03-Nov-2016 |
Jorim Jaggi <jjaggi@google.com> |
Add explicit method to dismiss Keyguard
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
estWindowManagerPolicy.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
indowStateTests.java
|
| 782b247fdbef531c04b839cd43cbcc3d42b27318 |
16-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Fixed issue with IME displaying on-top of nav bar."
|
| 93726a41a0b724e2aea865e7c0ce505c9cc095e1 |
16-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Don't include sysUI insets on secondary displays"
|
| 44fbdf5b1e13398e35d4bafb7236d194a51ee7af |
16-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed issue with IME displaying on-top of nav bar.
Caused by some recent refactoring. We now make sure the IME
has the higher animation layer in its base layer of the window
it is targeting.
Also, consolidated some of our test functions.
Bug: 32916670
Test: bit FrameworksServicesTests:com.android.server.wm.WindowLayersControllerTests
Change-Id: I0b1abd6fead981cfc810488cc785261abba5341d
ppWindowTokenTests.java
isplayContentTests.java
indowLayersControllerTests.java
indowStateTests.java
indowTestsBase.java
indowTokenTests.java
|
| db8e106fa35ca75f4a8bf9795edc7676fbf8e003 |
16-Nov-2016 |
Andrii Kulian <akulian@google.com> |
Don't include sysUI insets on secondary displays
Currently there is a single instance of WindowManagerPolicy
used in Window Manager and it is configured according to
primary display settings. Because of that it reports display
size with navigation bar insets even for secondary displays.
This CL adds displayId param, so it can adjust reported metrics
correctly when requested.
Bug: 32910901
Test: android.display.cts.DisplayTest
Change-Id: I14967fc13907c4fde17aed6a769d03cbde3ec1be
estWindowManagerPolicy.java
|
| 3c9006d842d25468760abc5935c50676bcf97f74 |
16-Nov-2016 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Fix that window was not hidden after policy hiding animation"
|
| af221d16de434c3550cb4e645135e95992ce1203 |
15-Nov-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix that window was not hidden after policy hiding animation
When we removed WindowState.isOnScreenIgnoringKeyguard we forgot
to change WindowState.isOnScreen to also check policy visibility.
Test: runtest frameworks-services -c com.android.server.wm.WindowStateTests
Test: Open camera app, make sure status bar is hidden
Change-Id: I780f50c8ed3e675f2fab623fdba4fcfc5b6f1d5b
Fixes: 32890266
indowStateTests.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
isplayContentTests.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
ppWindowTokenTests.java
isplayContentTests.java
indowTokenTests.java
|
| 15dd7efeb7491b80add341b0599027e246d07c6f |
03-Nov-2016 |
Robert Carr <racarr@google.com> |
Tests for computeFrameLw docked type scenarios.
Add some computeFrameLw unit tests for non fullscreen
windows. A test a day keeps the chase-list away.
Test: bit FrameworksServicesTests:com.android.server.wm.WindowFrameTests
Change-Id: Ifd7c07f5d174b35aa73b78ddc3432520fb096bf9
indowFrameTests.java
|
| 5b6714c2fa3cdd87642766e3fb0a1478d2422ec2 |
02-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added support for window TYPE_PRESENTATION
Switched presentation feature to use new window TYPE_PRESENTATION
and also add its own window token to the display the presentation
is running on. This is needed as window manager no longer allows
tokens to have windows on multiple displays.
Bug: 32566372
Test: Presentation mode works.
Change-Id: I9c2998311b65640743b8e23ec4f10bf1ffbfd785
estWindowManagerPolicy.java
|
| 73294b6cf79910dc688e5b62d673082a3dec773b |
27-Oct-2016 |
Jorim Jaggi <jjaggi@google.com> |
The big keyguard transition refactor (4/n)
Nuke KeyguardScrim
Test: Kill SystemUI while lockscreen is showing, make sure nothing
is visible when being killed.
Bug: 32057734
Change-Id: I9f8d1e5a0e0f968460d8170627a849623c6a7245
estWindowManagerPolicy.java
|
| 77e104322920cb93c0ac3d5f101115826728d3d1 |
27-Oct-2016 |
Jorim Jaggi <jjaggi@google.com> |
The big keyguard transition refactor (3/n)
Notify activity manager when dreaming showing state changed so
KeyguardController can update the occluded state when the device
is dreaming.
Test: Set dreaming while charging, wait until screen times out,
make sure that dream is occluding Keyguard.
Bug: 32057734
Change-Id: Ied6f485d9b4a1526cb4cd5f0701f86b1ea05830a
estWindowManagerPolicy.java
|
| 5a108c225a81cedacb1cec9b5b1986f2f3eff75c |
13-Oct-2016 |
Jorim Jaggi <jjaggi@google.com> |
The big keyguard transition refactor (2/n)
Introduce UnknownVisibilityController, which keeps track of apps that
may or may not be visible when launching an activity behind Keyguard.
When Keyguard is occluded and we launch another activity, we don't
know whether we still have to keep Keyguard occluded until the app
has gone through the resume path and issued a relayout call to update
the Keyguard flags.
This class keeps track of that state and defers the app transition
until the unknown visibility of all apps is resolved.
Test:
1) Have an occluding activity that starts another occluding
activity, ensure that there is no flicker.
2) Have an occluding activity while the Keyguard is insecure, start
a DISMISS_KEYGUARD activity, ensure there is no flicker.
3) runtest frameworks-services -c com.android.server.wm.UnknownVisibilityControllerTest
Bug: 32057734
Change-Id: I5145b272722ab8c31dd7c5383286f5c9473e26a4
nknownAppVisibilityControllerTest.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
ppTransitionTests.java
estWindowManagerPolicy.java
|
| e4ee8f8ab836ee115e9cbab360f35773e37fd5d5 |
31-Oct-2016 |
Robert Carr <racarr@google.com> |
Add some more computeFrameLw tests.
This time for producing insets in the fullscreen case.
Test: bit FrameworksServicesTests:com.android.server.wm.WindowFrameTests
Change-Id: I2566572af996f024d4b07c3bac945bc8ef7005b9
indowFrameTests.java
|
| c3a0627f10310c4bb0ceb4b727d7a7fc13ee4def |
31-Oct-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge changes If8232b90,I3176837e
* changes:
Deobfuscate computeFrameLw parameters.
Begin series of computeFrame unit tests
|
| 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
indowContainerTests.java
|
| 16a4e3cbf7068504e4628ed6e81e7700a6f8edbc |
28-Oct-2016 |
Robert Carr <racarr@google.com> |
Begin series of computeFrame unit tests
Start with a fixture and some simple unit tests
for WindowState.computeFrame.
Test: bit FrameworksServicesTests:com.android.server.wm.WindowFrameTests
Change-Id: I3176837ee60dbd474f22a3b1857f19b4e82afee7
indowFrameTests.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
ppWindowTokenTests.java
indowTokenTests.java
|
| b94292e5fe18a459aa521b9b9631d2db0485ac1b |
19-Oct-2016 |
Andrii Kulian <akulian@google.com> |
Fix NPEs when display is added or removed
- In WindowContainer set parent of the child after it is actually
added. This way if the child class depends on this in overridden
methods it will be in correct state.
- Reconfigure display only if it is attached. Otherwise there is no
corresponding DisplayContent record with configuration.
Change-Id: I20c51522d82f9d0ca98f098070585e6472a23e98
Test: Updated WindowContainerTests.
indowContainerTests.java
|
| cfca258639f81b33dd60aa9c05dbc4f4190ac11e |
19-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed monkey test failure
Avoid duplicate attempt to remove WindowToken from its parent
container when removeImmediately is called by first removing the
token from the display before calling super.removeImmediately
which only tries to remove the child from the parent container
if it is still attached to the parent.
Also, added test for the failure case the monkey test was
triggering.
Bug: 32239922
Test: WindowTokenTests.testChildRemoval passes
Change-Id: I4153669d18260d956c4b570944d2f48516d692ac
estWindowManagerPolicy.java
indowTokenTests.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
ppWindowTokenTests.java
indowStateTests.java
indowTokenTests.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
ppWindowTokenTests.java
indowStateTests.java
indowTokenTests.java
|
| 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
indowContainerTests.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
indowContainerTests.java
|
| 7203d62563e8877449ad40356dee0592ff6b005a |
21-Sep-2016 |
Brian Carlstrom <bdc@google.com> |
Track new WindowManagerPolicy methods
Test: make checkbuild
Change-Id: Id6a0c2c0b408e356afdaa8e2e3437a515a1aa54f
estWindowManagerPolicy.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
indowContainerTests.java
|
| d90546abd1425873f9a8baa8e6ba6c8fa35f970d |
10-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Changed WindowContainer to take child type as a generic
Removes the need for sub-classes to cast the children list.
Also means the children list can only contain a single type,
but that is okay.
Bug: 30060889
Test: Existing unit tests still pass.
Change-Id: Ie880f389b8ab790ee65adcdba23b32bdb568854f
indowContainerTests.java
|
| 5fc70966a770eb33dac2928fb5c4a6a85a872f60 |
10-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added WindowManager unit tests to pre-submit
Change-Id: Iaba2de367ab478916610d96b0e3f69d34e0b471c
ppWindowTokenTests.java
indowContainerTests.java
indowStateTests.java
indowTokenTests.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
indowContainerTests.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
ppWindowTokenTests.java
estWindowManagerPolicy.java
indowContainerTests.java
indowStateTests.java
indowTokenTests.java
|
| a7e3b64507250ab19a1294d58febea03cfa2b327 |
29-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Converted window manager unit tests to use JUnit4
Change-Id: I5248d5fcc9f0f5b44bab1d57f16d1cf2ad4b8209
ppWindowTokenTests.java
indowContainerTests.java
indowStateTests.java
indowTokenTests.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
indowContainerTests.java
|
| d1c3791659572529dbc749b70d1c33bda1bdbc32 |
16-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Switched WindowToken/AppWindowToken to use WindowContainer
Bug: 30060889
Change-Id: Ia82aedfd9ea86410acdcd3a55a7a7fc456be2fc3
ppWindowTokenTests.java
indowContainerTests.java
indowStateTests.java
indowTokenTests.java
|
| 1839645126c8e7e0909e8ed8f0686c2122ba6078 |
28-Jul-2016 |
Evan Rosky <erosky@google.com> |
Add support for custom user-switch UI
Given config_customUserSwitchUi, AM/UserController will not show any
UI during user-switch (no dialog or screen-freeze).
Provides a mechanism (WM.setSwitchingUser) by which a custom user-switch
UI can notify WM/Keyguard when it expects a user-switch operation to
be running.
Bug: 29329555
Change-Id: Ic903fc251d7ec3a54bc6a77906d3afa45a6a5fac
estWindowManagerPolicy.java
|
| 91355d5901f51b24ac1166a3197f5f9226a92389 |
06-Aug-2016 |
Guang Zhu <guangzhu@google.com> |
add missing dummy implementation of new method in test code
Change-Id: I91b6da823d7e3e44f9a70f9726d45b490b6783b2
estWindowManagerPolicy.java
|
| d63594a8d116b9fb25a031cb489ca033f716226a |
18-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added WindowContainer and WindowContainerTest classes.
The WindowContainer class defines common functionality for objects that
can hold windows directly or through their children
(e.g. WindowState, Task, AppWindowToken, ...). The WindowContainerTest
class as the name implies contains tests for the WindowContainer class.
Bug: 30060889
Change-Id: I1dd2c460c56cfc82aee67c033032a96843ed051d
indowContainerTests.java
|
| caa53afa0cae85a69da1b5bfb9b8368b152c917b |
17-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made WindowState.mParentWindow private scoped.
Bug: 30060889
Change-Id: Ic1d702cb6329fb2f03d006939f5610681d1d07bd
indowStateTests.java
|
| adde52ee32b656bb436f7e92f39f7d0d97cc9306 |
16-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made WindowState.mChildWindow private scoped
This involved:
- Moving method that operated on mChildWindows and mostly touched
WindowState fields into WindowState class.
- Creating new methods for getting information about child windows
outside WindowState class instead of accessing the child list directly.
- And, tests ;)
Bug: 30060889
Change-Id: I339cecb926b44b5db7ead1970e356304d5429c8f
estWindowManagerPolicy.java
indowStateTests.java
|
| 9d14790d299d1e2b96db287601c86f82850019c9 |
16-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Track hidden state of window in itself vs. all child windows.
It makes the code easier to follow if the hidden state of a window
is tracked in itself vs. all chils windows. Child windows can call
WS.isParentWindowHidden to get the hidden state of their parent window.
Also, moved the performShowLocked method from WindowStateAnimator to
WindowState since most of the fields modified in the method belong to
WindowState.
And, don't forget the test for the change ;)
Bug: 30060889
Change-Id: I5be13b936a2284fd8fe10218b80fe41cc197d1a7
indowStateTests.java
|
| 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
estIWindow.java
estWindowManagerPolicy.java
indowStateTests.java
|