| Age | Commit message (Collapse) | Author |
|---|
|
4851836, 4851837, 4851855] into pi-dr1-release
Change-Id: I1d831b82080179bb9bd87cad066949f9462f0c73
|
|
Bug: b/113041377
Test: manually
Change-Id: I651357d456f13ff67961b75d3630aca91aa512ac
(cherry picked from commit cf39b7bcad8c4d099b29ad42c6d524837fe3b2ea)
|
|
Bug: b/112869712
Test: adb shell screencap in all screen rotations
Change-Id: I62b38775f8253bea85a1870ad63cd27715754656
Merged-In: I62b38775f8253bea85a1870ad63cd27715754656
(cherry picked from commit 9ad73bc2967d6d97d359cbad16996fcd7b83d30f)
|
|
Bug: b/112869712
Test: adb shell screenrecord
Change-Id: I9f3f99de1a5bafc5318b24484f1916d28dcdfaa7
Merged-In: I9f3f99de1a5bafc5318b24484f1916d28dcdfaa7
(cherry picked from commit 1d465af5fce0678c1d269f626f61178da72602bc)
|
|
4844695, 4844696, 4844697, 4844698, 4844699, 4844700, 4844701, 4844715] into pi-dr1-release
Change-Id: I4b865e67b6ddaff426364074e0064db2782c703d
|
|
Bug: 112876936
Test: enable notchless simulation, try seascape apps, try swiping down
Change-Id: I8a155e16c19c474e605cb5a8d938e04461646027
(cherry picked from commit c597d61a615091f3d7176fa0cb3efc56b3dbda66)
|
|
Right now we just check that touches are within the reported axis
bounds, but really we should be checking whether they're in the physical
frame before notifying the rest of the system about them.
Also, fix a bug in touch transformation code where translations were
being incorrectly applied. We should only apply top and left
translations when we're in portrait and landscape orientations, as in
seascape and upside down orientations they'll just exceed their stated
maximum naturally.
Bug: 112876936
Test: enable notchless simulation, try seascape apps, try swiping down
Change-Id: I0f2119d5bdae10d6197bee942829fd0eed3f5dfa
(cherry picked from commit 358bcc73146c10946f7e9f292385557c646a329a)
|
|
Bug: b/112869712
Test: long press power button to take screenshots && adb shell screencap
&& apps to take screenshots and check
Change-Id: Ieb83373c9103f9847775eca5788358b567a05b24
Merged-In: Ieb83373c9103f9847775eca5788358b567a05b24
(cherry picked from commit f4e02874b260f85acb7eba2d61fe9af37e290c0f)
|
|
4682774, 4683234, 4683235, 4685438] into pi-dr1-release
Change-Id: I8dc38f80caee484ac880da467843b8d6045e7d9a
|
|
Classes which inherit indirectly from Layer and which override
onFirstRef need to also call their parents' onFirstRef to ensure that
Layer is initialized correctly.
Bug: 111854867
Test: atest UiAutomationTest#testWindowContentFrameStats
Change-Id: I5e29b6619d1a2e48277ad465a64d1f13bb92905c
Merged-In: I5ceb531a5d59587ab489342d0b19a42c1a286402
(cherry picked from commit 56eb975447788a58b3a8f858655c964d35e0ba75)
|
|
Change-Id: Icf30b62ed24c7129e089553ceb5f8b70108d15bd
|
|
4595368, 4593805, 4593576, 4593577, 4593578, 4593161, 4593806] into pi-dr1-release
Change-Id: I96fa260500394e1b75f013357483174725ef3cb2
|
|
Adds a pool of GL texture names.
Prior to this change, Layer creation was forced to run on the SF main
thread because it would need to call into RenderEngine to generate a new
texture name.
By creating a pool of pre-generated texture names, this operation no
longer needs to run on the main thread, which unblocks the rest of the
system during operations such as fingerprint unlock.
Bug: 110477323
Test: SurfaceFlinger_test + manual: examine systrace and observe that
layer creation no longer blocks on access to the main thread
Change-Id: I9d68874d6c6f704c8884676454e84d916cd86507
Merged-In: I9d68874d6c6f704c8884676454e84d916cd86507
(cherry picked from commit 9fdb7e0c8204aba5666d8e9f7f526682c8efc203)
|
|
|
|
Change-Id: I85dea305937096e2ff64f3beb1d262dc0a86263f
|
|
There is really no point in doing that because this can be done
in an async way such that the first and subsequent dequeueBuffer
still don't block because at that point allocation is very likely
done.
Furthermore, avoid calling setAsyncMode initially, as it will also
block RT on buffer allocation. However, the default is false in
any case, so we really don't need to call it.
Also, only allocate one buffer at a time and don't block in
dequeueBuffer on allocating buffers. It will likely have one buffer
available already, and there is no point in waiting for other
buffers to be allocated.
Test: Press home with memory contention, observe less delay.
Test: General smoke testing for increased jank
Bug: 111517695
Change-Id: I9deb435013b2503178d2fe032151c1aaedd667af
|
|
Change-Id: I0e9478f8ffa6f9baba22f69516469ad9e325ea2d
|
|
Added more info to the protobuf to help identify the root cause of the
bug.
Bug: 111062294
Test: go/winscope
Change-Id: Ife93907482ad89341b20a5508acce04ad4a5b32e
Merged-In: Ife93907482ad89341b20a5508acce04ad4a5b32e
|
|
Change-Id: I6b24536bbf125db7606d083c2c9494434e621ec8
|
|
Bug: 111062294
Test: adb bugreport
Change-Id: I40aa5f75d40b401b4f0eef5390106b3dac62ef43
|
|
Change-Id: I8640c03be0d748e48c5283ee7d999781c4f79ac2
|
|
* changes:
surfaceflinger: default to DisplayColorSetting::ENHANCED
surfaceflinger: signalRefresh after boot animation starts
|
|
into pi-dev
|
|
DisplayColorSetting works like a hint. On devices that do not
support RenderIntent::ENHANCE, RenderIntent::COLORIMETRIC will be
picked.
Bug: 79434305
Test: Pixel 2017 and 2018 boot animations
Change-Id: Ie85cca6eae75cf6ada3a4a364c402d09dc2920f9
|
|
Assume BootStage::BOOTLOADER initially. Switch to
BootStage::BOOTANIMATION on first buffer latch and switch to
BootStage::FINISHED after bootFinished is called.
Do not invoke signalRefresh when in BootStage::BOOTLOADER. We do
not want to replace bootloader splash by a blank screen. This saves
HWC from workarounds that may or may not work reliably.
Bug: 79434305
Bug: 110772452
Test: reboot and observe
Change-Id: I9e892e629303177431acd2cfe23f0f984ca6866e
Merged-In: I9e892e629303177431acd2cfe23f0f984ca6866e
|
|
Change-Id: I165faacd404af83537d437f7fdb493e36b5d8064
|
|
mode." into pi-dev
|
|
The 'lowmemorykiller' directory isn't used for lmk tracing on devices that have userspace lmk.
Bug: 110999121
Test: The memreclaim option is available in Traceur on a device with
userspace lmk.
Change-Id: I5dadb5c6c55cb04b6fe079b5f10a3dc35f1ee3f1
|
|
Previously, SurfaceFlinger would query Power HAL speculatively at the first
time color mode is set when device is booted. Howerver, Power HAL is not
necessary started before SurfaceFlinger and it's not necessary to query Power
HAL when color mode is not switched. As a result, the boot time is very long
because SurfaceFlinger needs to wait for Power HAL to start. Thus, in this
patch, we avoid querying Power HAL until color mode is switched, which won't
happen until we enter wide-color-gamut Apps.
BUG: 110112323
BUG: 111009852
Test: Build, flash and boot device, check hardware.power output with adb logcat
Change-Id: Ia581461ba7861784bff35cac6fbeca9bac92b8fa
|
|
We disallow legacy saturation matrix since this commit. For those do
have such a matrix, instead of applying it between sRGB->P3 conversion,
we apply it on P3. This means P3 and HDR tone mapped to P3 are also
saturated.
Bug: 110840428
Test: See red/orange scene through Camera ViewFinder, take a picture,
check the picture in Photos App, the red/orange should have
similar saturation.
Change-Id: I335b39888a76c7e411d9e03d9ad71448cbd7c05f
Merged-In: I335b39888a76c7e411d9e03d9ad71448cbd7c05f
|
|
Change-Id: Iec0c12912bca34aa0e91fbf2c1068ff7b9bdb2e4
|
|
HAL." into pi-dev
|
|
GPU composition is slow with FP16 wide color gamut. In this patch, we try to
mitigate this issue by boosting the GPU to higher frequency when SurfaceFlinger
is going to switch to Display P3 color mode by sending the new
PowerHint::EXPENSIVE_RENDERING to PowerManager.
BUG: 110112323
Test: adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/cur_freq to verify GPU
frequency with/without WCG content. GPU frequency should be high with
WCG content, and should be reset without WCG content.
Change-Id: I3758bcf9940e71d4b6d122d8916b7ad7f10f5397
Merged-In: I3758bcf9940e71d4b6d122d8916b7ad7f10f5397
|
|
|
|
|
|
Adds a pool of GL texture names.
Prior to this change, Layer creation was forced to run on the SF main
thread because it would need to call into RenderEngine to generate a new
texture name.
By creating a pool of pre-generated texture names, this operation no
longer needs to run on the main thread, which unblocks the rest of the
system during operations such as fingerprint unlock.
Bug: 110477323
Test: SurfaceFlinger_test + manual: examine systrace and observe that
layer creation no longer blocks on access to the main thread
Change-Id: I9d68874d6c6f704c8884676454e84d916cd86507
Merged-In: I9d68874d6c6f704c8884676454e84d916cd86507
|
|
Change-Id: Ie278ffc7f3135beff4f0bde08fdb09874a2f7ffb
|
|
|
|
SurfaceFlinger's renderer is not prepared to handle cropping in the face of
arbitrary rotation. To see the problem observe that if we have a square parent,
and a child of the same size, then we rotate the child 45 degrees around it's
center, the child must now be cropped to a non rectangular 8 sided region.
We can fix this problem in the future (b/109894387), but for now we are lucky.
SurfaceControl is private API, and the WindowManager only uses rotation in one
case, which is on a top level layer in which cropping need not be an issue
(this case is the screen rotation animation, where all the windows are rotated
together).
However given that the abuse of rotation matrices could lead to surfaces
extending outside of theire intended crop, we need to prevent non root-clients
without permission ACCESS_SURFACE_FLINGER (a.k.a. everyone except WindowManager
and tests) from setting non rectangle preserving transformations.
Our sad story continues, with the implementation of computeBounds. Notice the
intersection with the parent window is done in screen space by applying
and then inverting the transformation. However since the transformation doesn't
preserve rectangles, we get a different, in-correct, and larger result
from applying and inverting the transformation.
We don't need to be performing this computation in screen space, it's enough to
apply the local transform relative to the parent and then intersect with the
parent's computed bounds in the parent space. When we write the logic this way
it means we will only produce incorrect results for children who rotate outside
of their visible region. In the case of the WindowManager rotation animation
it rotates top level layers which do not have parents, and so we will
not produce incorrect results. We lock down other cases and clients
as described above.
Unfortunately our story continues, since our implementation of final crop was relying
on transforming Layers up to screen-space, this will no longer work with the
new implementation of compute bounds. We have to change setFinalCrop to crop
in parent-space rather than the final screen space. This is a semantic change, but
luckily there is only one user of setFinalCrop and it is on a layer whose parent
(The WM animation Layer) is already in screen space, so it's not a semantic change
for any actual clients.
Test: Manual.
Bug: 69913240
Bug: 109894387
Change-Id: I522e258cee03ac8e3609a40f53461119b7c45532
|
|
A recently introduced optimization reduces the service polling
interval to 100ms during boot. For this it uses the boot completed
system property. However, vendor code isn't allowed to access
system properties. This change keeps the behavior as it was,
while not accessing the system prop. We can investigate later
if we can do something similar for vendor code.
Bug: 80153956
Test: builds, sailfish boots
Change-Id: Ic52039516ae3e912ff2ec7c8dced4951696678df
|
|
Change-Id: I615c162863cf7f9ad89b1b351a14325347a60200
|
|
AOSP builds have different product & brand values than the ones flashed
onto the device's Keymaster in the factory.
As a result, Device ID attestation will not work on them correctly
because there is a mismatch between the values sent to Keymaster by the
platform and the values Keymaster is expecting to attest to.
Mark AOSP builds as not having this feature since it would affect all
AOSP builds on all devices.
Bug: 110361822
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Change-Id: I55e7c68b3e082af465c19cf18aeeeecffc4eb356
|
|
The issue with just one single sf early offset is that this may be
too early in case of steady rendering, i.e. when a
Wide-Color-Gamut window is on screen. Instead, we allow for
separate offsets in case we are in GL comp but the transaction
wasn't marked as early, and when the transaction is marked as
early.
In addition to that, we also allow the app-vsync to be adjusted
in these scenarios.
Bug: 110112323
Change-Id: I26d73b88b4e9e609ceedb604e8338452d9a89093
Merged-In: I26d73b88b4e9e609ceedb604e8338452d9a89093
|
|
Change-Id: I04ab55a479af30ed377f709a731cea213ebe1a04
|
|
|
|
|
|
Bug: 74942037
Merged-In: I2b4bffd685ddcb8899fb427b14c8a0ab937725c3
Change-Id: I2b4bffd685ddcb8899fb427b14c8a0ab937725c3
|
|
Change-Id: I32fe7101bedab0e4b52f25004a5c991ba9f77994
|
|
|
|
|
