A phone call came when the screen was off, displayState may change from
Display.STATE_OFF to STATE_ON before registerDisplayListener, which
causes ViewRootImpl.mAttachInfo.mDisplayState of InCallActivity to
remain Display.STATE_OFF, which causes performDraw to return directly.
So we should update ViewRootImpl.mAttachInfo.mDisplayState after
registerDisplayListener.
Bug: 235446909
Test: pass existing
Change-Id: I60b2da453da0ac5c4df6e5a1040defe4bfe726ec
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
* 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
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
Change I97cc418a8 broke translation on apps which use ListView; messages
were re-translated with the animation even while on-screen. A new
message arrival triggers a re-layout which causes the temporary
detachment, which caused translation to be cleared, and the views get
translated again later.
The solution is to NOT clear translation in the case of temporary
detachment. When Views are actually recycled (e.g., by ListView and
RecyclerView), the detachment is permanent/non-temporary.
Bug: 232178488
Test: atest UiTranslationManagerTest
Test: Manual - Verified scrolling and new messages arriving when
translation is enabled. Tested on apps that use ListView and
RecyclerView.
Change-Id: Ibf1be58219c43252e00b06d4c9e27def5bd36fc2
The text is not selectable while translated. Making translated text
selectable requires many more changes.
This was tested in Nextdoor in the feed/posts activity. When there is a
"Read more" link in the post, the link doesn't work while translated,
and doesn't behave the same way after translation is paused.
Bug: 202966891
Test: atest CtsTranslationTestCases
Test: Manually - with Nextdoor on feed and chat activities
Change-Id: I6e8f532d427d85ff22df0deb248d8416a15f4821
If two insets source consumers handle the same public type (like
navigation bar and taskbar both provide Type.navigationBars()), one has
a valid source but the other one doesn't, we should only let the one
with the valid source update the compat system UI visibility.
Bug: 232327949
Test: atest WindowInsetsControllerTests\
#testSystemUiVisibilityCallbackCausedByInsets
Change-Id: I07b35f488c5af273cafaf4a8a41f0a51365038a0
The PopupWindow will show up above the anchor with the real rectangle.
If the anchor is doing an animation, it will get a temporary top of the
anchor because the rectangle is conisince changed by the animation. So
attach tooltip after a while for waiting the animation is done.
And when the tooltip overrides the inline suggestion, clicking the
suggestion won't work. Force the y offset above or below the anchor to
fix the problem.
Bug: 223088398
Test: atest android.autofillservice.cts.inline.InlineTooltipTest
Change-Id: I068efc3d20f4486decd2c9e690ebeb2981fb6722
Because animators are not tied to the lifecycle of any UI
elements, it is possible for an app to go into the background
and for the animators to continue running. Ideally, the app would
track the lifecycle of the activity/etc and pause or disable the
animators, but it is common for this to not happen, causing the
animators to continue spinning when the app does not need them.
The animators are not causing as much work as for a foreground
activity (since they do not cause any re-rendering), but they cause
work nonetheless by keeping Choreographer awake to continue pulsing
frames.
The ideal fix would be to introduce new API for animators that
tied them to lifecycle concepts (View, Activity, etc). But that kind
of fix would only be available for future versions of the platform,
and does not address existing app code. A workaround for the current
situation is to address the most egregious problems; infinite animators
running on backgrounded apps.
The fix here is exactly that: when an app's visible surface (either an
activity or, for Wallpapers, a WallpaperService) is backgrounded,
a request is sent to pause animators for that surface. When that surface
comes to the foreground, a request is sent to resume those animators.
Since all animators are handled on the same thread for the same process,
in AnimationHandler, we should only ever pause animators when *all*
surfaces for a process are not visible (and resume them when *any*
surface becomes visible). Also, to mitigate any issues with thrashing
animator state for apps which become only transiently backgrounded,
we delay pausing for some time.
Bug: 228598053
Bug: 233391022
Test: new AnimatorLeak CTS test, plus manual testing for activities
and wallpapers
Change-Id: I8b9f841cc80babb972244c724968a5c085a06b69
Merged-In: I8b9f841cc80babb972244c724968a5c085a06b69
The DisplayManager.getStableDisplaySize is not the right way to get the
size we want for screen decorations and display team is going to get rid
of it.
Instead, we use the maximum display size supported by the display as the
base size to define the cutout and rounded corner configs.
Also fixed a bug that DisplayCutoutBaseView didn't update the
shoudDrawCutout config when display change.
Bug: 230227839
Test: 1. On foldable device, fold and unfold the device and check if the
cutout is correctly drawn.
2. On device supporting multiple resolutions, switch resolution
between FHD & QHD and check if the cutout is correctly drawn.
Test: atest LocalDisplayAdapterTest DisplayCutoutTest
ScreenDecorationsTest RoundedCornersTest
DisplayCutoutBaseViewTest
Change-Id: I7a602b5abd7d6a21d17eae4f8e99414eaf765fa5
TV PiP repositioning in response to keep clear area changes will be
debounced in SystemUI, so the client side delay in setting a keep clear
area with focus becomes obsolete.
Instead the config is turned into a flag for whether focused views
should automatically be marked as keep clear areas.
Bug: 231309309
Test: atest KeepClearRectsTests
Change-Id: I0ac61e671bb75e22a95b400c9bd8d84004379e43
Merged-In: I0ac61e671bb75e22a95b400c9bd8d84004379e43
State is checked at the front half of some calls, but is
dispatched onto the UI thread. If the connection is closed
in this time, the queued call will NPE when the field it
uses is cleared.
This adds a simple null check in two places, and test for both.
Bug: 232375183
Test: atest ScrollCaptureConnectionTest
Change-Id: Ida7fbf0a21c206db8d774dc247b6ab5257dacabe
When MediaProjection sets the session details in
MediaProjectiondManagerService, clear and re-set the
calling identity (since we have entered the system server
across the aidl boundary).
Additionaly, verify that the call originated from a valid
MediaProjection session. In the current model for
MediaProjection, signature-level permission
MANAGE_MEDIA_PROJECTION is held by the component that shows the
acceptance dialog to the user. The user allowing some app to
capture with MediaProjection is represented by
the IMediaProjection token (see MediaProjectionManagerService#
isValidMediaProjection).
Bug: 230748205
Test: Manual
Change-Id: Iace8eb7eea6c7a99fba7ea726481461a11bd1c90
Previously when curRootView changes IMM, the back callbacks are not
moved to the new focused ViewRootImpl. As a result if IME is up during
the focus change, the back callback would fail to unregister when
IME tries to hide itself.
Test: atest InputMethodServiceLifecycleTest
Test: atest CtsInputMethodTestCases:InputMethodServiceTest
Test atest CtsInputMethodTestCases:KeyboardVisibilityControlTest
Bug: 232660571
Bug: 232331013
Change-Id: Id30e51c74afbcce1f22d87af77e8404b4f0ae7d2
Update View logic to cancel all RenderNodeAnimators
when it is detached from a window.
Updated HWUI Animation logic to enable a cancellation
flag to cancel all animators operating on a RenderNode
whenever the staging parameters are pushed to RenderThread
Fixes: 229136453
Test: Added core test to RenderNodeAnimatorTests
Change-Id: Id674e8474757bfc8dfe30394dde29da49d139bfc
Previously, destroy just directly called release, which was already
locked. Now, destroy invokes some functions in native. This means if
another thread is calling release during the destroy call, it could
cause crashes.
Test: Hard to repro bug
Bug: 223412469
Change-Id: Ie6415f505bbc86505e3fe3ea2a0bea96a3e78ad3
ViewRootRectTracker#computeChangedRects returns all tracked Rects if
there are changes to the Rects since the last call to that method, or
null if there aren't.
When ViewRootImpl checked for changed Rects, if only one of either set
of restricted or unrestricted keep clear rects changed,
then #computeChangedRects returned null for the other, which was
subsequently reported as an empty list. If there were keep clear rects
previously reported, this would mistakenly clear them.
This change separates the check for changes and retrieving the list of
latest Rects. If either set of Rects has changed, now it's always the
latest Rects that get reported.
Bug: 231532058
Test: Manual with app with restricted & unrestricted keep clear areas
Test: atest KeepClearRectsTests
Change-Id: Ida51420d0f0e7935a5dc9f3eab902857927c33f5
