| Age | Commit message (Collapse) | Author |
|---|
|
into tm-qpr2-release.
Change-Id: I33ee618b57888960c7a24bde307a40032333b807
|
|
- This is part of fix of commit
Id9d9012d4ede9c8330f0ce1096bcb78e51b7c5df for backporting.
Bug: 248031255
Test: test using displaytoken app manually on the phone, test shell
screenrecord during using displaytoken; atest
android.hardware.camera2.cts.FastBasicsTest
Change-Id: Id9d9012d4ede9c8330f0ce1096bcb78e51b7c5df
Merged-In: Id9d9012d4ede9c8330f0ce1096bcb78e51b7c5df
(cherry picked from commit 5d1b23522b6a164c43375bd11e3369b4c1f49ac5)
Merged-In: Id9d9012d4ede9c8330f0ce1096bcb78e51b7c5df
|
|
tm-qpr2-release
Change-Id: Ia0dc88dae1bd1f54fcdf89a681067485fc40be4f
|
|
tm-qpr-dev
|
|
before it is cleared"" into tm-qpr-dev
|
|
Temporary property was introduced in Ie0a9859a43948b97414c97db279ff4d32bce3ac1
Test: manual
Fix: 246793311
Change-Id: Ic7e102201196285cba18e12e27c7cd4d40dcc8e4
|
|
cleared"
This reverts commit ff0c66e855925476c5ce06ad133f9084e725f96a.
Reason for revert: b/263272128
This platform change causes a regression in CTS tests. Since the CTS test fix will only be released in the next quarterly release, we must wait for the test to be released before landing this fix.
Change-Id: If2db80acb83f6731f66b49f8827f428a85e27370
|
|
tm-qpr2-release
Change-Id: I38c2e91833d69fbdbd77fd1859343833d4b11bc7
|
|
tm-qpr-dev
|
|
tm-qpr2-release
Change-Id: I5ca43ef222b73620bb330f7d4ef0a2cc07167e7c
|
|
tm-qpr2-release
Change-Id: Ie945518f02858e615e23dcac15815f67d7c23284
|
|
The display id of the last hover window must be checked before
it is cleared when a window changes for a display.
If display id of the last hover window is not checked, then the
last hover window is cleared every time a window changes on a
different display which is faulty.
The last hover window should only be cleared when the window
is removed from the same display as the display of last
hover window.
Add test that ensure that only one hover enter is generated
followed by several hover move when the mouse is moved in
a window on primary display when windows on second display
are removed.
The CTS test, VirtualMouseTest, must also be updated.
Reference patch:
Correct CTS test VirtualMouseTest#sendRelativeEvent
Ie4a54ee3469ed0b7c88abea946f32f66203da38f
Bug: 239687726
Bug: 262701886
Test: atest VirtualMouseTest
Change-Id: I70ebcb994ebc31327b85303110753ce3d40329be
Merged-In: I70ebcb994ebc31327b85303110753ce3d40329be
(cherry picked from commit dae9dfcf89fb79cdf27353d7f4220a36f83b343d)
|
|
tm-qpr2-release
Change-Id: Ib29f621144969c523bff6f6c9257f95f0f4962d8
|
|
SF does not yet support concurrent modeset on multiple displays, as the
scheduler/modeset/VSYNC state machines are tied to the internal display
that is powered on, a.k.a. the active display.
When SF detects a change in the DM policy for a display, it initiates a
transition to the new display mode, which includes syncing to its VSYNC.
However, the per-display calls to setDesiredDisplayModeSpecs that start
this process occur after the setPowerMode calls to turn off/on the old/
new active display, respectively. Before this CL, a change in policy on
the now inactive (powered-off) display triggered a partial display mode
transition (that would start resync but abort before HWC modeset), such
that SF wound up internally inconsistent and out of sync with HWC.
Fix this by deferring the applyRefreshRateConfigsPolicy of the inactive
display until it becomes active. Later, in onActiveDisplayChangedLocked,
the Scheduler::Policy is cleared by Scheduler::setRefreshRateConfigs, so
ensure that Scheduler::getPreferredDisplayMode subsequently initializes
Scheduler::Policy::mode to the chosen mode for the newly active display.
Otherwise, applyRefreshRateConfigsPolicy falls back to its default mode.
Bug: 260092798
Test: No intermittent jank on outer/inner displays after fold/unfold.
Test: DisplayModeSwitchingTest.multiDisplay
Change-Id: Iebe1a6bb4749630333ef954955ac33807c95dd9f
Merged-In: Iebe1a6bb4749630333ef954955ac33807c95dd9f
|
|
This is a partial cherry-pick of
cf875ab292ffebdf6165c037a00e0fc344b39b74
Bug: 262287992
Change-Id: I40c0b6f7d0e67ffc1ee01c6cb1dfbcfc96b37d62
Merged-In: I40c0b6f7d0e67ffc1ee01c6cb1dfbcfc96b37d62
|
|
tm-qpr2-release
Change-Id: Ia476c7950ab21a3f486e556e0705b92064400561
|
|
When a display becomes active, apply its RefreshRateConfigs' policy,
as it may have changed while the display was inactive.
When booting while folded, DisplayManager first sends DisplayModeSpecs
for each display, and then powers on the outer display. Before this CL,
the outer display would become the new active display, but its
DisplayManagerPolicy would never be applied.
This backport also includes I63d21c2216a3ab864b040bdb2c9e8fba0768b66a
for expanded unit tests.
Bug: 250421145
Test: Force 120 Hz, and reboot while folded.
Test: SetPowerModeInternalTest.activeDisplay{Boot,Single,Dual}
Change-Id: I15e0f5a280e62baf6d4e6ea2748d95342e79ac44
Merged-In: I15e0f5a280e62baf6d4e6ea2748d95342e79ac44
|
|
In I3a2eae4efc4a5c6113700a9ca9e9b261e364a878, a display's power mode is
std::nullopt (unknown) until the first setPowerMode. The condition to
power on the display from that state relies on undefined behavior, as
it dereferences std::nullopt. It only works because PowerMode::OFF is
0 and the memory happens to be zeroed.
Bug: 250421145
Test: Boot
Change-Id: I0db8970b37da6eb308043157cd2ac7a9f6764294
Merged-In: I0db8970b37da6eb308043157cd2ac7a9f6764294
|
|
Introduce debug.sf.ignore_hwc_physical_display_orientation to allow ignoring physical orientation provided through hwc API in favour of 'ro.surface_flinger.primary_display_orientation'
Test: manual
Bug: 246793311
Change-Id: Ie0a9859a43948b97414c97db279ff4d32bce3ac1
|
|
tm-qpr2-release
Change-Id: I3d0cb4c520295775af53a62578c8ca28cc1a3927
|
|
Update the logic used in GraphicsEnv to decide whether shared objects
can be inserted into the process. This is used by Vulkan layers,
GLES layers, and ANGLE when deciding whether libraries from outside
packages can be used.
The new logic doesn't just use PR_GET_DUMPABLE which is no longer set
by default in platform debug builds. It also incorporates
ANDROID_DEBUGGABLE, which is defined when `debuggable` is true in
Android.bp. This happens for eng or userdebug builds of the platform.
The use of `debuggable` is the replacement for reading ro.debuggable
which can no longer be read at runtime (see b/193912100).
Tested with:
export APP_PACKAGE=<app from Play Store>
adb shell settings put global angle_debug_package org.chromium.angle
adb shell settings put global angle_gl_driver_selection_pkgs $APP_PACKAGE
adb shell settings put global angle_gl_driver_selection_values angle
Test: Released app able to load from angle_debug_package on userdebug
Test: Released app cannot use angle_debug_package on user build
Bug: b/193912100
Bug: b/253678459
Change-Id: I3dda4258e23871ee2fab2cf5ba367612e00de0e2
(cherry picked from commit 5d32e628450494b72473c039c7d6f6ce57540bb1)
|
|
tm-qpr2-release
Change-Id: Ic1b3c37373ece8892cda3333fbfcb90518d2924c
|
|
tm-qpr-dev
|
|
As a workaround for lost release callbacks, we try to
release buffers in the submitted queue. If the buffer
was released previously but held in the pending release
queue, we would log incorrectly. This fixes the misleading
logs.
Test: presubmit
Test: logcat
Fixes: 255679881
Change-Id: I7e46f21f4c4fa1ee8c70e3ee8cd3f3665fe7442a
(cherry picked from commit 28fe2e694f5cafaf0eaad1417e15fdee2943b15b)
|
|
This fix the second pointer will use the identity transform because the
returned touched windows should be refreshed after updating the new
pointerIds to the temporary touch state.
This also fixed wallpaper window can't receive up event.
Bug: 258382964
Bug: 240308355
Test: atest inputflinger_tests
Change-Id: I96a738dcb01bf1c9e2792d3fee547c147dba33b5
Merged-In: I96a738dcb01bf1c9e2792d3fee547c147dba33b5
Merged-In: Ibf82b494e45e35babe9ba9f3dd1236fee8bcea6d
|
|
RegionSamplingThread::captureSample intentionally passes null, which is
already checked for below, but missing in this failure case of
`!renderArea`
Bug: 259021062
Test: presubmits (cost/benefit ratio of adding a new test for this seems
high, given current testing flows and simplicity of change)
Change-Id: I460539404be7a7ae434812aa1f583bba6247a812
Merged-In: I460539404be7a7ae434812aa1f583bba6247a812
|
|
tm-qpr2-release
Change-Id: Iafb92e91af6ea164f9c2ec8f92da5acaa7fca17b
|
|
|
|
tm-qpr2-release
Change-Id: If849652650726232d9e0d975f4510bd50713e690
|
|
|
|
tm-qpr2-release
Change-Id: I04647fa774a927feb50a6e34b2f500670b1fa601
|
|
The change in ag/19758680 made it so that we now reset TouchInputMapper
after the viewport is disabled.
When resetting, we cancel any ongoing gestures. Since the mapper is
re-configured before the gesture is canceled, this means that as the
viewport is getting disabled, the mapper (which was previously in
POINTER mode) is set to DISABLED mode. When the pointer gesture is
canceled afterwards, it is happening while the mapper is already
DISABLED.
In this CL, we allow pointer gestures to be aborted even when the mapper
is not in POINTER mode.
Bug: 257071757
Test: atest inputflinger_tests
Change-Id: I5c80a5c1c411d16f70ed4f7cce6dd97ed91e124f
Merged-In: I5c80a5c1c411d16f70ed4f7cce6dd97ed91e124f
(cherry picked from commit b80b6c0e6d9c69957fb9ffa3d0467ad626af2fbe)
|
|
tm-qpr2-release
Change-Id: I5005a715113a00ee3b6d396cca2062b5b58e54aa
|
|
|
|
tm-qpr2-release
Change-Id: I8d12eb661c50050bdca04dd2075b2627d521f914
|
|
The current logic only checks if dirty is not empty, but doesn't account
for no content changing. Instead use the same logic that's in
beginFrame to compute mustRecompute and use that when determining if the
display should queue a buffer.
This fixes an issue where a Displays first few frames could be black
until the content is loaded.
Bug: 239888440
Test: First frame from screenrecord is no longer black
Change-Id: Ibb568302bf2d50db167a1f9ca76a0f37e2c65bf5
(cherry picked from commit 09fa1d6665aa6022d5c6c8f61fc81f950b476a2f)
|
|
tm-qpr2-release
Change-Id: Ifb27e6503863a60f0ad1a7aa0eddb8b3e5c041b9
|
|
The existing pattern in InputReader is that when a mapper is reset, all
of its state is cleared and state of the buttons/axes is
queried through EventHub to rebuild the current state of the mapper.
This approach does not work for multi-touch devices, since there is no
way to query the current state of the contacts through the evdev
multi-touch protocol.
Since we cannot fully rebuild the current state of a multi-touch device,
we work around this limitation by never clearing the multi-touch state.
Bug: 248506674
Test: atest inputflinger_tests
Change-Id: Ic59d9fcb4e13fe262c422825c2485185004b719b
Merged-In: Ic59d9fcb4e13fe262c422825c2485185004b719b
(cherry picked from commit afabcde5a9ac2b77586d61ad4a226718130663c3)
|
|
Currently only a single corner radius can be applied on a
layer. If the layer's x and y scale do not match, the average
is used to scale the corner radius. This can cause visual
defects in the rendered rounded corners.
This defect can be seen when moving the Camera app
to recents. The camera buffer is submitted with a rotation
and the layer's x and y scales are used to stretch the buffer
to the desired size in portrait mode.
Bug: 145094543, 250491108
Test: atest librenderengine_test
Test: adb shell wm size 1000x1900 & animate camera app to recents
Change-Id: Ie76581eb200a57b847f619f4da0e61758f70dce7
(cherry picked from commit 50c0afe2457ec631fc3c9a7731aa4b9c8e18fd76)
Merged-In: Ie76581eb200a57b847f619f4da0e61758f70dce7
|
|
tm-qpr-dev
|
|
When an event hub device is going away, the controller associated with
it should be deleted.
Before this CL, mController would remain, and its use would result in an
illegal memory access, because it was storing a reference to a deleted
context.
Bug: 245770596
Test: atest inputflinger_tests:InputDeviceTest#DumpDoesNotCrash
Merged-In: I298f43172472f74fa4d5d8e0b7f52bd5c13d14f7
Change-Id: I298f43172472f74fa4d5d8e0b7f52bd5c13d14f7
(cherry picked from commit 30feb8c162aa2e5348bba20e99e8db2a61bac6e7)
|
|
This is a cherry-pick from of a CL from sc-v2 adding a safety mechanism
for lost buffers. The original CL probably should have been merged in to master,
and I can't relate to my thought process adding DO NOT MERGE on the
original CL. Recently we have started seeing some of these ANRs again.
Well actually we have seen them continuously, but most have been due to
GPU hangs. Recently we started seeing some which aren't due to GPU
hangs. We found one trace, which showed the sort of situation described
below, which lead me to realizing this code was never merged in to
master. It shoud be relatively safe since we released it on sc-v2.
Perfetto telemetry shows a cluster where a transactionComplete is
arriving but an earlier releaseBufferCallback has never arrived.
This leads to blocking and ANRs. We try to work around this by
generating a fake release buffer callback for previous buffers when we
receive a TransactionCompleteCallback. How can we know this is safe? The
criteria to safely release buffers are as follows:
Condition 1. SurfaceFlinger does not plan to use the buffer
Condition 2. Have the acquire fence (or a later signalling fence)if
dropped, have the HWC release fence if presented.
Now lets break down cases where the transaction complete callback
arrives before the release buffer callback. All release buffer callbacks
fall in to two categories:
Category 1. In band with the complete callback. In which case the client
library in SurfaceComposerClient always sends release callbacks
first.
Category 2. Out of band, e.g. from setBuffer or merge when dropping buffers
In category 2 there are two scenarios:
Scenario 1: Release callback was never going to arrive (bug)
Scenario 2. Release callback descheduled, e.g.
a. Transaction is filled with buffer and held in VRI/WM/SysUI
b. A second transaction with buffer is merged in, the release
buffer callback is emitted but not scheduled (async binder)
c. The merged transaction is applied
d. SurfaceFlinger processes a frame and emits the transaction
complete callback
e. The transaction complete callback is scheduled before the
release callback is ever scheduled (since the 1 way binders are
from different processes).
In both scenarios, we can satisfy Conditions 1 and 2, because the HWC
present fence is a later signalling fence than the acquire fence which
the out of band callback will pass. While we may block extra on this
fence. We will be safe by condition 2. Receiving the transaction
complete callback should indicate condition 1 is satisfied.
In category 1 there should only be a single scenario, the release buffer
callback for frame N-1 is emitted immediately before the transaction
callback for frame N, and so if it hasn't come at that time (and isn't
out of band/scheduled e.g. category 2) then it will never come. We can
further break this down in to two scenarios:
1. stat.previousReleaseFence is set correctly. This is the
expected case. In this case, this is the same fence we would
receive from the release buffer callback, and so we can satisfy
condition 1 and 2 and safely release.
2. stat.previousReleaseFence is not set correctly. There is no
known reason for this to happen, but there is also no known
reason why we would receive a complete callback without the
corresponding release, and so we have to explore the option as
a potential risk/behavior change from the change.
Hypothetically in category 1 case 2 we could experience some tearing.
In category 1 we are currently experiencing ANR, and so the tradeoff
is a risk of tearing vs a certainty of ANR. To tear the following would
have to happen:
1. Enter the case where we previously ANRed
2. Enter the subcase where the release fence is not set
correctly
3. Be scheduled very fast on the client side, in practicality
HWC present has already returned and the fence should be firing
very soon
4. The previous frame not be GL comp, in which case we were
already done with the buffer and don't need the fence anyway.
Conditions 2 and 3 should already make the occurence of tearing much
lower than the occurence of ANRs. Furthermore 100% of observed ANRs
were during GL comp (rotation animation) and so the telemetry indicates
the risk of introducing tearing is very low.
To review, we have shown that we can break down the side effects from the change in
to two buckets (category 1, and category 2). In category 2, the possible negative side
effect is to use too late of a fence. However this is still safe, and should
be exceedingly rare. In category 1 we have shown that there are two scenarios,
and in one of these scenarios we can experience tearing. We have furthermore argued
that the risk of tearing should be exceedingly low even in this scenario,
while the risk of ANR in this scenario was nearly 100%.
Bug: 247246160
Bug: 244218818
Test: Existing tests pass
Change-Id: I757ed132ac076aa811df816e04a68f57b38e47e7
|
|
SurfaceFlinger::doDump previously contained two layer traversals, one on
the main thread and one off the main thread. During concurrent dumpsys
commands, the layer traversals may race with each other, which causes
shared ownership of the underlying storage of a SortedVector containing
the z-ordered list of layers. Because the implementation of
SortedVector's STL iterators assumes that the underlying storage may be
edited, this can cause the storage to be copied whenever SortedVector::begin
and SortedVector::end are called, which means that SortedVector::begin()
+ SortedVector::size() == SortedVector::end() is not always true, which
causes invalid iteration.
In general, this use-after-free can happen as long as the off-main
thread traversal exists in doDump(), because the traversal can run in
parallel with any workload on the main thread that executes a layer
traversal. So, this patch moves the traversal for dumping out the list
of composition layers into the main thread.
A future patch could explore either fixing SortedVector to fix judicious
iterator invalidation, or building LayerVector on top of std::set, but
either option is an invasive data structure change.
Bug: 237291506
Test: Test script that calls dumpsys SurfaceFlinger on many threads
Change-Id: I0748396519c924dc1b84113d44259f22d0d7ebd6
(cherry picked from commit 6761733ad1dd775f011588c59d5a6d210175c546)
Merged-In: I0748396519c924dc1b84113d44259f22d0d7ebd6
|
|
|
|
|
|
A mirror for misc_ce and misc_de storage is created for each new volume
UUID and a bind mount occurs from /mnt/expand/<uuid>/misc_{ce,de} to
/data_mirror/misc_{ce,de}/<uuid>.
This is similar to how apps use data_mirror. In addition, when a private
volume is unmounted, the mirror for that volume UUID is deleted.
Bug: 214241165
Test: atest GtsSdkSandboxInprocessTests
Ignore-AOSP-First: Will cherry pick once other CLs are merged in as well
Change-Id: I3ea99145e38ed3781a701c1305720f2d4dbe54ce
Merged-In: I3ea99145e38ed3781a701c1305720f2d4dbe54ce
|
|
When needsComposite is zero in persistBrightness(), the mBrightness
needs to be updated to avoid unexpected skipping.
Bug: 244268674
Test: adb shell cmd device_state state 0 or 1 repeatly
Change-Id: Iccf925c1407e4be489da2dba521b93eee1b1c4b5
|
|
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/native/+/19775140
Change-Id: I965677ab70958604ad123e8a2c86c4d9c9020509
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/native/+/19775140
Change-Id: Ie6aa47c375f59647fa7027aa1fa5654cf995eb9e
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
|
