This is needed by VR to handle keyboards that display a window larger
than the interactable region
Bug: 62194867
Test: Manually with prints
Change-Id: I7288956ed8da8d24e7c46ffa8f27461f7abbca5e
(cherry picked from commit 56162a0a51)
Careless mistake on my part :). Sorry about that.
Test: Try an app with two SV like Netflix verify top SurfaceView doesn't occlude bottom one.
Bug: 62375611
Bug: 62113351
Change-Id: Ia33aabf8b8e276f70365d62b82f113ecd3bee2fa
This reverts a part of 2ae1bf568b
RecyclerView relies on the old behavior. Will un-revert this (with
targetSdk check) once we have a solution for RecyclerView
Bug: 38352147
Test: RecyclerView Focus tests now pass
Change-Id: I7b0dfda295cd75e407bbd39a948b5585f8ed6e08
Previously, it was possible for the view hierarchy to be measured,
laid out, and drawn around a window frame size that did not match
the current configuration. This stems from new configurations not
always propagating back from WindowSession#relayout, which is
called from ViewRootImpl.
This changelist makes WindowManagerService#relayoutWindow always
return the latest configuration. It also adds rotation to the
configuration.
Fixes: 32839232
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: I39daca338b4f87eff1a509eb99493f01e710ced1
Most @SystemApi methods should be protected with system (or higher)
permissions, so annotate common methods with @RequiresPermission to
make automatic verification easier.
Verification is really only relevant when calling into system
services (where permissions checking can happen on the other side of
a Binder call), so annotate managers with the new @SystemService
annotation, which is now automatically documented.
This is purely a docs change; no logic changes are being made.
Test: make -j32 update-api && make -j32 offline-sdk-docs
Bug: 62263906
Change-Id: I2554227202d84465676aa4ab0dd336b5c45fc651
- When the window for the activity enters PIP, update the outline provider
to override the alpha of the shadow (to be opaque) to ensure that is is
visible. Only applies to the task root activity.
Bug: 36741700
Test: Launch YT, ensure that there is a shadow when after it enters PIP
Test: go/wm-smoke
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: If089dae84e4916d3d0e7bbeb316215b46e522e05
In N we used a Dim-Layer to add a background to SurfaceView, from
the WM side. In O we forgot to reimplment this with the new SurfaceView
and so we once again can have holes for apps which don't implement
surfaceRedrawNeeded.
Bug: 62113351
Test: Manual from bug. go/wm-smoke
Change-Id: If3dac51886b9a8083140da7b5bc1b349da57860f
When wide color gamut rendering is requested, hwui will now
use an rgba16f scRGB-nl surface for rendering. This change
also fixes the way screenshots are handled in the platform
to behave properly with wide gamut rendering.
This change does not affect hardware layers. They also
need to use rgba16f scRGB-nl; this will be addressed in
another CL.
Bug: 29940137
Test: CtsUiRenderingTestCases, CtsGraphicsTestCases
Change-Id: I68fd96c451652136c566ec48fb0e97c2a7a257c5
- focusAfterDescendant ViewGroups that were also clusters would
continue to be remembered for restoreFocusedInCluster after
gaining focusable children. This caused undesired cluster-focus
loops
- focusableViewAvailable wasn't being called in all cases (specifically
when views were added). This meant focusAfterDescendant views
wouldn't transfer focus to children in some cases.
- 0-area views which became focusable weren't reporting
focusableViewAvailable. Since views gaining area doesn't report
focusableViewAvailable, this was another case of state change not
being accounted for. Also, this restriction doesn't exist for
gaining focus so these views are actually focusable despite having
0 area.
- focusableViewAvailable was reporting focusable views even when
ancestors (and therefore the new focusables) were not visible.
- restoreFocusNotInCluster tried to focus invisible views
- restoreFocusNotInCluster was sending focus to focusAfterDescendant
viewgroups which had focusable children IN a cluster.
Bug: 38010274
Bug: 38009598
Bug: 38352147
Test: cycling works in situations reported in bugs.
Added CTS tests around focusableViewAvailable and
FOCUS_AFTER_DESCENDANTS
Change-Id: I77f214f5384dcf9092324e08fc1daa3f1155bbad
THIS IS A MANUAL MERGE OF ag/2311240 (PART 1)
- This reduces the copy of the hardware bitmap when it is
parceled/unparceled.
Bug: 38507414
Bug: 62021436
Test: Launch Overview to/from app, ensure that the header bar shows
Test: go/wm-smoke
Change-Id: If644b18d7ca11569bd6544c7438b03ca13a9f0f4
- This reduces the copy of the hardware bitmap when it is
parceled/unparceled.
Bug: 38507414
Bug: 62021436
Test: Launch Overview to/from app, ensure that the header bar shows
Test: go/wm-smoke
Change-Id: I85a9a59a0a3699d1642158061d10fddef34393c3
Signed-off-by: Winson Chung <winsonc@google.com>
When the device is unlocked using the fingerprint sensor in an
orientation opposite to the lockscreen orientation, the app that
will be visible is first relaunched in the current lockscreen
orientation and then later relaunched in the correct orientation.
If the keygaurd is going away then:
- Don't let keyguard affect device orientation. We want to use the
orientation of the app that will be visible.
- Allow the rotation sensor to be enabled even though draw isn't
complete so window manager can get the updated or last rotation
reading.
- Don't clear the previous proposed sensor reading to allow
window manager to use the information to update the orientation as
needed vs. falling back to the previous orientation.
Change-Id: I8369723d6a77f2c602f1ef080371fa7cd9ee094e
Fixes: 38494778
Test: Launch an app that doesn't fix orientation like clock, hold
the device in landscape, press the power button, unlock the device
using the fingerprint sensor, and verify the the app isn't
relaunched.
