Fixes 36869204
Test: create another account, enroll a fingerprint in the new account
touch the sensor and make sure the finger you just enrolled gets highlighted
Change-Id: Ib3e8d9ddc987a2c8b7f0878a83f4cbd025e13f7a
Using a feature will allow app developers to find out if a
particular device supports running activities on secondary
screens before using the APIs.
Bug: 36776777
Test: android.server.cts.ActivityManagerDisplayTests
Change-Id: I7121bdb782cac9df70121e9df5cbf3fcb76f4a93
When a 2D app is launched from a VR app, since the VR app was on
DEFAULT_DISPLAY, the 2D app is also moved to DEFAULT_DISPLAY. This needs
to be addressed by moving any non-VR 2D app launch in VR mode to the
virtual display.
Bug: 37111307
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testVrActivityLaunch
Test: #testVrActivityReLaunch
Test: #testPostVrLaunch
Change-Id: I83bffe94bb89415a6b3c026dd7077e70fe36fee0
Signed-off-by: Karthik Ravi Shankar <karthikrs@google.com>
Test: mediaplayer doesn't send error notify to client when only one track has error.
Bug: 24761723
Change-Id: I7221dfdbc6a256532186c654406bbe06de831798
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.
(Manual merge from commit 687bb44b437f7bb24dd3dddf072c2f646308e2ca)
Change-Id: I7746c9175a2da28f75d4f4b169d7997abadf1852
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.
(Manual merge from commit 687bb44b437f7bb24dd3dddf072c2f646308e2ca)
Change-Id: I7746c9175a2da28f75d4f4b169d7997abadf1852
These values can change for themes that are dependent on the size,
such as the DialogWhenLarge theme. In this case, different layouts
are loaded that could depend on updated LayoutParams.
This CL identifies the case when the layoutparams change and informs
the activity.
Change-Id: Icde8d94cc089ca0c02a15120a860533ef540c850
Fixes: 31643268
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsServicesHostTestCases android.server.cts.ActivityManagerAppConfigurationTests#testDialogWhenLargeSplitSmall
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
- Adds a workaround to ensure that onStop() is dispatched to the PIP
activities when the PIP is dismissed
- Consolidating dismiss PIP behavior to call moveTaskToFullscreen().
Now we are consistent, and when we expand the PIP, we call
moveTaskToFullscreen(top), and when dismissing the PIP we call
moveTaskToFullscreen(bottom)
- Fixing issue where we were dispatching extra MW/PIP mode changes when
just expanding the PIP
- Fixing typo in last commit where PIP mode change was not getting
scheduled correctly
- Fixing issue where move-to-fullscreen log was sent for each task
Bug: 36567036
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testStopBeforeMultiWindowCallbacksOnDismiss
Change-Id: I303b88d75e9f136da0c238ef5987804e0684c78e
Signed-off-by: Winson Chung <winsonc@google.com>
Previous logic relied on the returnTo type of the task of the activity
we are launching which can get the wrong signal at times because the
original task might have been started from home, but since we are
already in docked mode it shouldn't cause recents activity to be
launched.
We now decide if recents ability should be shown based on if the home
stack is currently visible at the time we started the new activity.
Also, renamed ActivityStack.getStackVisibilityLocked() to
ActivityStack.shouldBeVisible() since it is used to determine if the
stack should be visible and also so it isn't confused with the new
method ActivityStack.isVisible() which returns true if the stack is
currently visible.
Test: manual
Change-Id: I051e72ce93c886d25526af2afef851c95812ab3e
Fixes: 37005549
When the following conditions happen together, another context in
Application stack was launched unexpectedly:
- There is a context of tasks in Application stack, which is launched
from a task on Home stack.
- All tasks/activities in the context are finishing.
Solution:
Add a condition check to see if the task is NOT one of the task
finishing on-top of the top running task.
Bug: 30883775
Test: manual
Author: Ichitaro Kohara <ichitaro.kohara@sonymobile.com>
Change-Id: I5d6097a7c8dc2733ff684957370c987dd158e329
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 687bb44b437f7bb24dd3dddf072c2f646308e2ca)
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 687bb44b437f7bb24dd3dddf072c2f646308e2ca)
This reverts commit 2d2315a66d81d29896e6a0ffedbfbbed3981b9ed.
Reason for revert: possible cause for b/37156733
Change-Id: I02d468449f0632d1281ab5ad2a381e7e36a5b0ea
