This CL removes the strong reference added for mapping display ids
and Resources to Displays. Instead, the key pair is now the display
id and ResourcesKey, and the mapping is pruned when key is
invalidated.
Change-Id: If91368171212b28c40e03c15fb39c72412a44811
Fixes: 36625868
Test: make -j32 cts; cts-tradefed; run cts --module CtsAppTestCases --test android.app.cts.DisplayTest#testRotation
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
Change-Id: I342a133ae8d7f38008cb03706d160e6f2e2cca97
Fixes: 37002720
Test: Start instant app [adb shell am start -a android.intent.action.VIEW -c android.intent.category.BROWSABLE -d http://www.realestate.com.au/property-apartment-nsw-pyrmont-124879602] and see that hitting the 'share' icon works
As far as I can tell this has always been broken. We've always had
intermittent reports of buffer-queue-abandoned as well (a recent bug
came with some reports from N). During onStop SurfaceView relies on
onWindowVisibilityChanged, to trigger a visibility change. At this
point SurfaceView will emit the SurfaceDestroyed callback in order to
stop the client from further use of the Surface. The contract we've
been using with ViewRootImpl is at any point following
Activity.performStop returning the WindowManager was free to destroy
the Surfaces. This is why in setWindowsStopped we destroy the hardware
resources for the ViewRoot. However we aren't dispatching anything to
the SurfaceView. The WindowManager will send an app visibility
notification, but that would go through the handler. This means by the
time we return from Stop, there is no guarantee that the
onWindowVisibilityChanged callbacks have been invoked at all. It
seemed most sensible to dispatch the visibility callbacks directly. We
also ensure that getHostVisibility will return false after this point,
so that performTraversals will not reverse our visibility request if
it occurs again prior to the window visibility notification from the
WindowManager. We also guard against emitting a second window
visibility changed callback in the traversals. I don't know at this
point what value the window visibility notification provides but I
don't feel excited about removing it in this CL at this point in
the development cycle.
Test: Put Chrome in PiP. Turn screen off. No Crash!
Bug: 36561071
Change-Id: Id1673561b2299d477b2761b3ac6afa14eabbf7fb
Fix a bug where a malformed Parceled representation
of an AccessibilityNodeInfo could be used to mess with
Bundles as they get reparceled.
Bug: 36491278
Test: Verified that POC no longer works, a11y cts still passes.
Change-Id: I10f24747e3ab87d77cd1deba56db4526e3aa5441
(cherry picked from commit 687bb44b43)
Added ActivityManager#supportsMultiDisplay() to check if system
supports running activities on secondary displays.
Bug: 36776777
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testMultiDisplayDisabled
Change-Id: I18f98f2f6a9e865ad8dc63a470210190536d3271
