Rolls back one line of ag/2257919.
Bug: 63811145
Test: TalkBack no longer reads the page backwards in:
Settings > System > Reset > Factory data reset
Settings > Connected devices > Android Beam
Change-Id: I6b04e64cd650ebda193da4a54bf0721bd256820c
The events were ending up not important for a11y and
with invalid window ids, which prevented TalkBack from
seeing them properly.
Bug: 64428961
Test: Ran YouTube in PiP, now able to select it.
Change-Id: I38ccbf5f2f35ffda255b84f229e98ca23e6b11aa
Add black background behind letterboxed apps on displays with tall
aspect ratio. This is needed to make sure that other windows won't
bleed through status/navigation bar area, because letterboxed
windows are not considered fullscreen.
Bug: 63156733
Bug: 62893418
Test: go/wm-smoke
Test: Trigger animations to/from recents with different rotations.
Change-Id: If0eac9a3801518185d560a87d9f88ee0aafa3a9c
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
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
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
SurfaceControl.
In a recent CL we introduced a call to Surface#createFrom, in order to
recreate the Surface object from the underlying SurfaceControl, as a
workaround to emulate when it was parcelled over binder in the past.
However this is causing BufferQueue abandoned errors when stopping and
resuming some applications. To understand them, we need to revisit the
SurfaceView destruction process when handling onStop.
First mWindowStopped will be set to true (SurfaceView#windowStopped),
and we should then enter updateSurface. Our requested visibility will
now be false and so we emit the Surface destroyed callbacks. Notice in
the finally block in mUpdateSurface, we will release mSurface, but we
will NOT null mSurfaceControl. Inline documentation explains why.
In the case that the activity is not actually being destroyed, it's
possible that we may not get a dispatchDetachedFromWindow. This means
that we will not null mSurfaceControl. Now if the activity is
un-stopped and we re-enter updateSurface we encounter a problem
state. "creating" will be set to false since mSurfaceControl != null,
however mSurfaceControl will not point to a valid surface.
Prior to the introduction of the #createFrom call, this unwanted state
didn't cause any problems. Because mSurface was released back in the
finally block as we were stopping we now fall out of the
mSurface.isValid() block in updateSurface. As we reach the finally
block again, we would now set mSurfaceControl=null since the app was
no longer stopped. Later when we reach updateSurface again (which
tends to happen quite often) it will now be null and we will correctly
set creating=true, create a valid SurfaceControl, and move along
happily. However following, the introduction of this
Surface#createFrom call we will now reinitialize the Surface from an
invalid underlying SurfaceControl. This means we will enter the
mSurface.isValid block, but will proceed to emit an invalid Surface to
the client in the callbacks.
We avoid this state by making creating=true even if
SurfaceControl=non-null when the calculated visibility changes from
invisible to visible.
Bug: 63251745
Test: Manual of app from bug and apps from previous related bugs. go/wm-smoke. Additional manual testing of many SV apps.
Change-Id: Icc32a34cac239d65267da705cc23feb23e1ceb67
Fixes: 37245619
Test: go/wm-smoke; Go to home, turn off phone, observe that during the transition to AOD the navigation bar hide animation does not play.
Change-Id: I9a2fce4295900648a680e8e7e8fee0fbb447dd3d
The constant will become visible once
the corresponding feature is supported.
Bug: 62433331
Test: make
Change-Id: I310338033dd861e9fd0cc1492a8e34fb53ce0415
Previously, the server side would omit reporting new configurations
during resize and relayout if the current configuration matched the
last reported. However, if the last reported came through a resize,
the client side handling would be enqueued as a Handler message. This
leads to the possibility of the client getting a new window frame but
not a new configuration where this is synchronously handled, such as
ViewRootImpl::performTraversals.
To address this issue, we now always send the current configuration
from the server to the client. The client then identifies changes
against its own record of last reported configuration and updates as
appropriate.
This changelist also adds a call to force window relayout during
updateConfiguration, as it's possible this is called after
performTraversals is called or resize is handled, leading to a stale
window frame.
Bug: 24671393
Test: go/wm-smoke
Test: Open Camera while rotating phone to landscape. Added
temporary logs to detect inconsistencies between measurements
and reported rotation on draw.
Change-Id: I0d5143dfe80400f6a43ce710750f9fc9d4b93f74
Certain activities are dependent on the rotation of the device to
determine layout. In these cases, orientation does not provide enough
details.
This CL adds the field (hidden) to the configuration.
Change-Id: Idb3ba10cb4de8838737c25e92264e6cee224e264
Fixes: 32839232
Test: go/wm-smoke
This is a followup to ag/2370980/ to expose the API more
externally as a WindowManager API. This allows application
access without needing to reflect on IWindowManager.Stub.
We require this to get the current IME touch region to
display it properly in VR contexts.
Test: Manual
Bug: 62194867
Change-Id: Ibbf336e1e473b65d4c76a1492da187d50cfda424
The attributes for View, paddingHorizontal and paddingVertical,
were added in the O release and are documented in R.attr. But they
should also be referenced in View itself, alongside the other
padding parameters.
Similarly, the new layout_MarginHorizontal and
layout_marginVertical should be referenced in
ViewGroup.MarginLayoutParams.
Bug: 63128350 Add docs about new padding/margin params
Test: built docs, checked the result
Change-Id: I3021df5ea83c469811b4a6ec6ecd3ab2966ec384
The description for `AutofillManager.isAutofillSupported` doesn't make
clear that either the device or the user can make autofill unsupported.
Bug: 62604325
Test: Ran 'make ds-docs -j16' and staged content to
go/dac-stage/reference/android/view/autofill/AutofillManager.html#isAutofillSupported()
Change-Id: I298b9f535e23dc3cb54fabed36642523753c13a5
