The attached frame is the frame of the parent window that its child
attaches to, as long as the child is not
TYPE_APPLICATION_ATTACHED_DIALOG. It is a factor while computing the
window frame.
Previously, we let the child obtain the attached frame from its parent
view root. However, if the parent and the child are not in the same
process, it can be tricky.
This CL sends the attached frame from the server to the client via
ClientWindowFrames. In this way, the child can compute its window frame
without having to accessing the parent view root.
Bug: 161810301
Bug: 175861127
Test: atest ActivityRecordTests WindowLayoutTests
Change-Id: Ia844a4c927027e305a56114216eaee2bf7933b1f
When the enableOnBackInvokedCallback is set to false (or not set),
registering an OnBackInvokedCallback should be a no-op to avoid
overriding the default compat callback.
Test: Manual testing registering a callback on an app with the flag
disabled and doing a back gesture. Currently we don't have test
executing a back gesture so automated tests are not possible
Bug: 235206960
Change-Id: I54d843f11130a78ed5a68cbe4722e601a2086ee1
Merged-In: I54d843f11130a78ed5a68cbe4722e601a2086ee1
(cherry picked from commit aa48dc3c2d)
This is missing while introduced the new private flag. To include it and
print it out when it's set to help debugging layout related issue.
Bug: 236101339
Test: LayoutParams#toString()
Change-Id: Ifa37a989f497f6f6d0f4d2ac2f884f83d537c9aa
This registers system default clear-top xmls and propagate the
showBackdrop flag.
Test: atest RemoteAnimationsControllerTest
Bug: 221048002
Change-Id: I664f7edd181fd7d625b7010a77cd1f7b58fc3113
The host visibility was always invisible while making an Activity
window active because the host visibility was updated afterward
(in ActivityThread#handleStartActivity). Therefore, #relayoutWindow
could be skipped and not recreating Surface if the view visibility is
not changed since last traversal.
Bug: 226324982
Test: repro steps on the bug
Change-Id: Id677a375bc2f75b055a9d35c8b8488e97c24eae9
When LOCAL_LAYOUT is enabled, the client needs to use the params for the
rotation to layout.
Bug: 161810301
Test: presubmit
Change-Id: I41c94970a600a7a4a3d5bcbab9e79adc1d93d72e
If a window is in a sync, but it already drew it's sync buffer, it
normally would be allowed to continue processing draws and just block
when it runs out of buffers. It would unblock once the sync is complete
at the sync buffer was sent to SF. However, this has a few issues
1. In some cases, WMS wants to retry the draw again due to configuration
changes. This could cause deadlocks because the client may already be
blocked since there are no more buffers. Instead, the client will
block and WMS would be responsible for dropping the last buffer and
notifying the client that it can draw for a sync again
2. If there are multiple UI threads, each can block each other due to
the shared Render Thread. If one of the windows in the sync continues
to draw and then blocks RT due to no more buffers, all other UI
threads are unable to draw. If the behavior in 1 is desired, we'd
need to make sure no one in the same sync continues to draw until
everyone is complete. This is to ensure dropping will actually allow
another render to occur. If other windows are blocking the RT, then
even with dropping, the requested sync window cannot get another buffer
and will cause a deadlock.
Test: Current sync requests work
Bug: 233625646
Change-Id: I3a0a4f36bf61a6677507672578e447060b806651
There're 3 different parameters trying to affect the insets provided by
a window and can be set independently but are related. This change will
make a new class InsetsFrameProvider to let the window set all the
information needed for the insets at the same place.
Besides, this change also extends the insets calculation logic to
support more use cases. With this, the bars can provide insets outside
of its window frame as well.
Test: atest DisplayPolicyLayoutTests
Bug: 161689946
Bug: 232044523
Merged-In: I7059b3a222745818b6852a288416e197e2afd7b2
Change-Id: I7059b3a222745818b6852a288416e197e2afd7b2
VRI is not currently waiting for SV to draw since SV may start its draw
before VRI opened the SyncSet. If that happens, VRI will not include SV
in its SyncSet and report draw finished even if SV is not complete.
This fix has SV create its own SyncSet when redrawNeeded. Then if VRI
creates a sync, SV will merge its own SyncSet into that one. If SV
already finished drawing, then nothing will get merged, but it means SV
is ready already. If SV is not finished, VRI will now also wait for SV's
draw to finish before calling finishDraw.
Test: Long delay in surfaceRedrawNeededAsync
Test: SurfaceSyncerTest
Bug: 230998394
Change-Id: I44331b8f54951e6dc633a4845bbf690abde0f95e
We will need to dump the transaction id in transition traces to be able to reliably associated the start and end of a transition to the states in the SF trace.
Bug: 230462538
Test: N/A
Change-Id: I2a040503d9e1f4f4636549bae6b7fe12d5632049
* changes:
Use System Property to Control Animator Pausing
Disable debug logging in AnimationHandler
Allow system to disable behavior of pausing animators for bg apps
Pause animators when app is not visible
There is some checks in performDraw that will skip drawing. For example,
if the display is off or if there's no view. In those cases, we don't
want to wait for a frame since there will be none and instead
immediately report back that the sync for this VRI is complete.
Test: Repro from bug
Fixes: 234426290
Change-Id: I7d5993f9980b9cdafc99a5712e74a4de704aef47
This is to prevent getting unexpected results while calculating the
width or height of the rectangle, due to the overflow.
This CL defines the borders of the window layout with large enough
integers, which are also the borders of the safe bounds.
Fix: 227276622
Test: atest ConfigurationScreenLayoutTest#testScreenLayout
Change-Id: Iee14e6de48f57be4999f64dbdce01815de88a9df
In the Vulkan pipeline, the GPU start time was measured to be when
swapBuffers starts. But the command queue has already been submitted at
this point, which means that the GPU work would already have begun. This
means that it's possible to measure a negative time since for very light
GPU workloads, the GPU fence can fire prior to CPU making it to
swapBuffers().
To compensate, instead measure from after skia completed submitting GPU
commands, until the GPU fence fires. Since it is theoretically possible
for GPU work to complete if the render thread gets descheduled
immediately after submitting the GPU, we also add some clamping to
ensure that the duration from command submission -> completion of GPU
work is nonnegative.
Bug: 230713131
Test: atest android.view.cts.FrameMetricsListenerTest
Change-Id: Ia30b7732eaab71e4e29766f788d5cd94ec63c38a
Surface already has a lock on the native object so it's safe to call
destroy without holding additional locks. This also fixes ANR issues
where an app is still attempting to render when the window is destroyed.
Test: App from bug doesn't ANR
Bug: 234006724
Change-Id: I0d323c03f299e5857d1950870498f3182d019924
If a type of insets doesn't provide any insets to a window, the previous
logic would think the type is controllable. This is wrong.
If a type of insets provides the entire inset to a window, the previous
logic would think the type is not controllable when the width or height
doesn't match the display frame. This doesn't make much sense as well.
This CL fixes the issues mentioned above and also refines
WindowInsetsTests. It displays the name (string) of the controllable
types, not the value (number).
Fix: 234426300
Test: WindowInsetsTests
Test: atest InsetsControllerTest
Change-Id: Ice71db61cc4963c6d8489096bec9c295d58bfd78
Currently the cloned windows is avaialbe from window list,
however the node info from the cloned window is incorrect.
To avoid confusion, we would drop them for a short term solution.
Bug: 230300971
Test: manually test with switchaccess
adb shell dumpsys accessibility to observe the window list
Change-Id: I7a03376567698a493c9eb5e26d1f3390aacdb408
