Consider this VirtualDisplay (VD) scenario:
HostActivity creates a VD which holds SettingsActivity. When EditText
on SettingsActivity is tapped, it gains focus.
On eventual taps, it loses focus i.e. the Window in VD loses focus and
the host activity in primary display gets the focus instead. This
happens because WM's TaskTapPointerEventListener.onPointerEvent()
is called on the default display only.
Root cause:
1. Tap detector isn't registered for non-default display.
2. Tap detector has no info on which displayId touch was received.
3. InputFlinger doesn't deliver InputMonitor events for
non-default displays (fixed in a separate CL)
Fixing above results in onPointerEvent(MotionEvent) to deliver the
Touch events successfully to VD. We restrict these changes to physical
multi-displays and VR VirtualDisplays (which uses virtual touch device).
[VrManagerService calls WMInternal.setVr2dDisplayId(int)]
In future, displayId should be part of InputEvent. Bug: 64258305
Bug: 62033391
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
Change-Id: I3626f4de5aa9bcf905da9abd39f3ab1baefc4c48
Instead of ANR in an infinite loop, this will detect
a cycle and return null.
Bug: 62960867
Test: Added in CTS FocusFinderTest#testChainVisibility
Change-Id: Ifb4638e3350642f065c40b3bea112cc12efff447
We need to omit it from screenshots, and screen mirroring, so SurfaceFlinger
will have to have some knowledge. Eventually we'd like to do this by
having everything else have a parent, and mirroring and screenshotting will
operate on that parent. Since we aren't comfortable doing that for DR though, here's
a quick and dirty hack to tide us over with low risk.
Bug: 63311708
Test: screencap, screenrecord, android.view.cts.SurfaceViewSyncTest
Change-Id: I2b43be00567ee19cf27aeef344e5415f4a69297f
Following four steps with RecyclerView - CardView - ImageView:
a. fade in imageview in onBind:
calling imageView.setTransientState(true)
b. RecyclerView animate the item: calling
cardView.setTransientState(true)
c. fade-in finishes, calling imageView.setTransientState(false)
d. RecyclerView animation finishes: calling
cardView.setTransientState(false)
After these four steps, RecyclerView unexpectedly has transient
state.
The problem is in step b, when calling cardView.setTransientState()
it incorrectly calls parent.childHasTransientStateChanged(this, true)
which causes RecyclerView's mChildCountWithTransientState increased
to 2. And it's decreased to 1 in step d and stay as 1 forever.
The child should only call childHasTransientStateChanged() when
actual hasTransientState() changed.
Bug: 64235615
Test: ViewTransientStateTest
Change-Id: I99ed35cc9c49e54d36590d8f1d206501fd3288f2
FYI: We have plans to reintroduce this in some form in the near future.
Fixes: 62571798
Fixes: 64096360
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Change-Id: I864d6c1143af6a2485cabdfe85116b5922a3e315
This CL logically reverts a compatibility hack I introduced [1] for
apps that had relied on @hide method SurfaceView#setWindowType(int).
[1]: I5217f6417a73690ae8a978754218b7b089070fdd
3b5011afc9
Fixes: 62054282
Test: Manually verified that Bug 36345857 is still not reproducible
Change-Id: Icee198c554de558cfa4ffe0b264064969839654e
The presence of these new flags leads to issues with application that
do not expect their presence. Since these flags can appear at
critical times, such as on orientation change, these issues are
brought to the surface often.
This CL remedies this problem by first removing the rotation
property. It is not used and the original issue of orientation and
Configuration alignment has been addressed. For app bounds, the CL
reverts the behavior back to identifying diffs as a screen size
change.
Fixes: 64004417
Test: bit FrameworksServicesTests:com.android.server.wm.AppBoundsTests
Test: go/wm-smoke
Change-Id: I1fabb564dfb5c13d897336708523cf7cd5099fa0
These features can be set on a surface to reduce perceived latency
at the expense of visible tearing.
Bug: 63858546
Test: Manual, CTS test coming
Change-Id: Ica3f480bd1cb8f77dff57218d2fa8783433d3396
When taking a snapshot, always include the full stack bounds.
When showing a snapshot starting window, use the SystemUI flags
from the top fullscreen window in the task - this is the same way
as we do it when the real windows are going to be visible.
Test: Revoke contacts permissions, launch contacts, go to recents,
go back.
Test: go/wm-smoke
Fixes: 63268663
Change-Id: If8d9701f6d34abd56116ed04fe27fe82688e506a
We're now only showing the notification header instead of the
repetitive contents hidden string. On Aod, we're still showing
a string however, since without it, it looked too empty.
Test: manual, set sensitive setting on lockscreen, observe notifications
Change-Id: If2bb66b9b3b366715aa68087e5c35cf1cdff3693
Fixes: 63741232
Some display hardware can't do the transition from doze display states
to the on display state cleanly, so in order to hide any janky-ness of
the transition we force the display off and cover the screen with a
black surface. This lets us keep the screen black until SystemUI and the
display are both ready.
Bug: 63531607
Test: manual
Change-Id: I66bd483e5f01e1dbd5069465aa122828af5f1903
A recent change allowed animations while the screen is
turning on, but not fully turned on; this allows rotations
while the device is going to sleep though. To prevent that,
we now disallow animations if the device is going to sleep too.
In addition, we also prevent the rotation animation when the screen
is not fully on or non-interactive.
Change-Id: I9b84f68a02a07067e48b11c008bcaf4bcb7c41a0
Fixes: 63760853
Test: Turn phone to landscape on an app that can rotate. Press power button. Verify AOD shows without a rotation; go/wm-smoke
We were using width/height as top/bottom...not much more to it
than that :).
Bug: 62752640
Test: go/wm-smoke
Change-Id: I57f081b4fab555f0f551e753618725bdd3780305
The default manifest value needs to be unspecified, not rotate,
as rotate overrides the LayoutParams specified value.
Bug: 63151981
Test: Manual from bug. go/wm-smoke.
Change-Id: I2ad6e3fdd06eeef0166bbe09d07b57cc45ed6e50
When an application doesn't support tall aspect ratio of the
screen where it's displayed, it should be positioned on the
opposite side from navigation bar. It's supposed to create
an effect of extended black nav bar.
Bug: 62893418
Test: go/wm-smoke
Test: ActivityRecordTests#testPositionLimitedAspectRatioNavBarBottom
Test: ActivityRecordTests#testPositionLimitedAspectRatioNavBarLeft
Test: ActivityRecordTests#testPositionLimitedAspectRatioNavBarRight
Change-Id: I2cd3d236ee8d0cc263fee4c0a436d78c755eb9b7
Removes the @NonNull requirement on TextClassification.text.
e.g. TextClassifier.NO_OP doesn't classify text and thus returns
TextClassification.EMPTY which doesn't set TextClassification.text.
This is ideal as we need not make copies of this object when NO_OP
was performed.
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
bit FrameworksCoreTests:android.widget.TextViewActivityTest
bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: I0b3ac5bf0027cbd67ba40d1110f1100280c8c3a2
