To reduce the delta of the upcoming ANR refactor, add a basic ANR test
here. This will also help highlight the difference in behaviour from the
current code to the new code.
To cause an ANR today, the socket needs to be blocked, which means that
we need to send ~ 50 events to the unresponsive window.
These workarounds will be removed when the ANRs are refactored.
Bug: 143459140
Test: adb shell -t /data/nativetest64/inputflinger_tests/inputflinger_tests --gtest_filter="*InputDispatcherSingleWindowAnr*" --gtest_repeat=1000
--gtest_break_on_failure
Change-Id: I0a1b28c2785d03d8870691641e0f7c6b1ca3b85e
Merged-In: I0a1b28c2785d03d8870691641e0f7c6b1ca3b85e
The current implementation of layer history discards all the history
if a layer is considered inactive. This leads to an issue in the scenario
that a layer is posting infrequent updates so slow, that by the time we
get the next buffer, the layer is considered inactive, and we bump the
refresh rate to Max, instead of detecting that layer as infrequent.
As a fix, we keep around the layer history even if it is inactive.
To avoid cases where detect animations too late, we clear the history
on touch event.
Bug: 156654519
Test: add a new unit test that simulates the buffer pattern
of a Netflix playback
Change-Id: Ie076891806d74dde814fbbb3b1a73c38e0b2ae34
This change allows creating an effect layers without a color fill so
we can avoid an additional sf transactions when creating effect
layers.
Fixes: 157646690
Test: go/wm-smoke
Test: atest SurfaceFlinger_test
Change-Id: I3d8a4f4820d7b8fb05daab697c25cff8def612c1
While refactoring ANR logic, we discovered that an existing Q behaviour
was broken by the focus refactoring. The behaviour aims to prevent keys
from being sent to incorrect windows.
The desired behaviour is as follows: if there are any unfinished events,
then do not process key events (keep them pending), which would allow
these key events to go to a new window, if one becomes focused. The
intent is that if the user hits "Alt+Tab" to switch to another window,
and starts typing right away, we want to make sure that we have
processed the focus event for the new window prior to determining where
to send the new key events after Alt+Tab.
The behaviour is broken today because we put the focus events at the
back of the queue. So even if we process the focus event first, it would
still go to the app after the key event, which would mean that the new
window may receive it, but would drop it because that window does not
yet have focus (since we haven't sent the focused event to it).
The proposed solution is to always put the focus events in the front of
the queue. But, we still need to preserve the relative order of focus
events. To account for that, we put a new focus event always at the
front of the queue, but behind any other focus events that may be there.
Bug: 143459140
Test: added in ANR CL because this behaviour is updated there.
Change-Id: I95256bd3f57988d1990cf1f21267c8f405892e8e
Merged-In: I95256bd3f57988d1990cf1f21267c8f405892e8e
InputReader was already responsible to bind device/event and display. It
makes sense to further extend it to control the display where mouse
cursor is shown.
Bug: 146385350
Test: Mouse cursor shows up at expected display.
Test: atest inputflinger_tests
Change-Id: Ie7a9546550b70c8834462b06de929472196fe713
Merged-In: Ie7a9546550b70c8834462b06de929472196fe713
- Restructure the code in RefreshRateConfigs to be able to clear
LayerHistory frames on the first touch event. Without this change we
clear the history on every frame as long as the touch timer hasn't
expired.
- Add log prints for debugging
Test: Play 24fps video in YouTube PIP mode and rotate the device - no jank
Test: Chrome playing video - no refresh rate switching
Test: Hide/Show keyboard when inputting text
Test: Running Hay Day and observing refresh rate
Bug: 157096772
Change-Id: I7cabecd6ea27ec335e773aa22bb111fa8ec89195
This reverts commit 1adbb72759.
Reason for revert: Causing regression with b/157096772
Change-Id: Ib2009f7a4ecbd268ea69304853a91bd22674ec1e
Test: Play 24fps video in YouTube PIP mode and rotate the device - no jank
Test: Chrome playing video - no refresh rate switching
Test: Hide/Show keyboard when inputting text
Test: Running Hay Day and observing refresh rate
Bug: 157096772
Bug: 155062712
Bug: 156654519
This reverts commit eeb74561b6.
Reason for revert: Causing regression with b/157096772
Change-Id: I031219588cedf5cfcb75255430f707428ed59f72
Test: Play 24fps video in YouTube PIP mode and rotate the device - no jank
Test: Chrome playing video - no refresh rate switching
Test: Hide/Show keyboard when inputting text
Test: Running Hay Day and observing refresh rate
Bug: 157096772
Bug: 157110371
This reverts commit 39db2c9b07.
Reason for revert: Causing regression with b/157096772
Change-Id: I058d6f8efa637cb36371276761281f51b7aa3dd3
Test: Play 24fps video in YouTube PIP mode and rotate the device - no jank
Test: Chrome playing video - no refresh rate switching
Test: Hide/Show keyboard when inputting text
Test: Running Hay Day and observing refresh rate
Bug: 157096772
The Layer lifecycle is tied to BufferLayerConsumer so when the Layer is
removed, the BufferLayerConsumer is abandoned. However, abandoned
doesn't necessarily mean it was cleaned up yet. Therefore, we need to
check whether the BufferLayerConsumer was abandoned before accessing the
raw pointer mLayer. If the BufferLayerConsumer was not abandoned, then
mLayer will be valid.
Test: Builds and runs. Hard to reproduce race condition
Fixes: 157535966
Fixes: 155679049
Change-Id: I8b309c9e1fe57746bceabab1deda56248087b189
Preparation for removing implicit include paths for jni.h from soong.
Bug: 152482542
Test: m checkbuild
Change-Id: I06873e61e519b6e54d7325f90231bce732790366
Merged-In: I06873e61e519b6e54d7325f90231bce732790366
Exempt-From-Owner-Approval: build clean-up
(cherry picked from commit e32877afcc)
When we render on a framebuffer with smaller size than the
currently active mode the destination clip can get outside
of the display bounds. For examlple, if the currently
active display mode is 4K, but we render on a 1080p framebuffer,
dest clip = 4k, but display bounds =1080p. As a result of that
only the top left quarter of the image is visible on screen.
Bug: 153991408
Test: manually make sure the image is properly displayed on sreen
1. boot device
2. turn off HWC with adb shell service call SurfaceFlinger 1008 i32 1
3. turn on HWC with adb shell service call SurfaceFlinger 1008 i32 1
4. start a youtube video and repeat 2 and 3.
Test: take a screenshot and check it's correctly displayed
Test: atest libsurfaceflinger_unittest librenderengine_test
Merged-In: Ia7b6ebd311c1b751c1966a34a9294b9b85a2aa0b
Change-Id: Ia7b6ebd311c1b751c1966a34a9294b9b85a2aa0b
(cherry picked from commit fcfe1360a4)
Layers that voted with FrameRateCompatibility::ExactOrMultiple
will still allow touch boost as those layers are typically not
interactive and therefore touch is probably meant for a different
layer. For the same reasoning, we should continue to heuristically
calculate frame rate for layers in the same tree.
Bug: 157254751
Test: run Swappy with statistics overlay and observe refresh rate
Test: run YouTube, play a video, scrolling the recommended videos and observe refresh rate
Change-Id: I9311512a663eba61dfcae6277a52c077e135a244
A layer will be considered frequent unless proven otherwise, in order
to make sure animations will change the refresh rate as soon as possible.
In addition, if a layer is classified infrequent, then we will keep it
infrequent until we get a burst of frames. These two policies combined
allow us to differentiate between an animating layer and a layer that
usually doesn't animate.
Bug: 157096772
Test: Play 24fps video in YouTube PIP mode and rotate the device - no jank
Test: Chrome playing video - no refresh rate switching
Test: Cursor blinking on Messages - switch to lowest refresh rate quickly
Change-Id: I3629b6e4786cd43919f51465e347f2abb52234d9
Tune the threshold for detecting inactive layers to treat 24fps
videos without presentation timestamps as frequent.
Bug: 157110371
Test: Chrome playing video and observe systrace
Change-Id: I6908761ef2af7e40cd40eda6e1e66c8e1a01393f
Some devices might takes a few frames to change the refresh rate.
Calculating the frame rate should ignore frames sent while changing
the refresh rate as those might result in an inaccurate frame rate
due to frame misses.
Bug: 156530990
Test: Running Hay Day and observing refresh rate.
Change-Id: I99f364cd1816c3ce2ba3c3145331eb618dcaea71
Use the correct display transform in calculateOutputRelativeBufferTransform().
When SF_PRIMARY_DISPLAY_ORIENTATION is set, DisplayDevice only updates the
logical to physical transform; OutputCompositionState.orientation doesn't
change.
Test: - OutputLayerTest.displayInstallOrientationBufferTransformSetTo90
- Run "dumpsys SurfaceFlinger" on a device with SF_PRIMARY_DISPLAY_ORIENTATION
set to 90 and verify that the HWC transform is 0 (identity)
- screencap
Change-Id: I079b5ea22de8d47a7fb7233d01decfbd4b578be8
Merged-In: I079b5ea22de8d47a7fb7233d01decfbd4b578be8
When DMS enforces a fixed refresh rate to hide user-visible flickering,
we must respect that refresh rate to avoid unnecessary switches during
scenarios such as idle and touch boost.
We must still respect app votes when they explicitly provide a frame
rate.
Bug: 156315203
Test: Exoplayer
Test: Modified version of SetFrameRateTest to simulate 60hz video
Test: libsurfaceflinger_unittest
Change-Id: I5fe974ddaff30e2f02e381cb63e0a6418834fdb5
