Snap for 5135467 from 4c3137a9d3fe39d09aed664c0405bb219591cc90 to pi-qpr2-release

Change-Id: I062951f9308b3ddc7de447378371b5d3cbfe6d2e

Snap for 5130385 from 256bb66d02e3cae7a439594a16228d6f462ff9a1 to pi-qpr2-release

Change-Id: I75ea8ba160a7f2be3421b3a388f7ad6e4ea07ea5

Do not use raw coordinates in VelocityTracker

In P, we switched VelocityTracker to use raw coordinates when
calculating the velocity. While that helped solve the issues with views
being moved while touched, this has broken some other assumptions in the
view hierarchy. Currently during dispatch, MotionEvent coordinates are
getting adjusted as events are passed to the child views.

One example is a rotated ListView. When setRotation is called on a
ListView, ListView continues to use getYVelocity to determine the fling
speed. However, after the view is rotated, its action is in the
horizontal direction. This causes flings on ListView to not work
properly.

Further analysing the View system api, it appears that the problem could
also occur in such cases as scale, where the view gets increased in
size, and MotionEvents are adjusted accordingly.

This issue could have been solved in the view hierarchy by changing the
assumptions and reworking the VelocityTracker usage. However, that is
deemed infeasible.

The switch to raw coordinates was to resolve the issue when a moving
view is trying to calculate the velocity of the fling. Since that no
longer is possible, we will have to use work-arounds for those use
cases. One such example is the SystemUI use case, in PanelView.java.

Bug: 117921784
Bug: 117475766
Test: Sample app from bug 117475766, flings in the horizontal direction
work properly

Change-Id: If4cd6ace0bbef52521e1bbab8d58d649b295e2b7

Snap for 5115288 from 60454ab1ccaaa5c508c8a88a2426affb5c21b603 to pi-qpr2-release

Change-Id: I4ee475bdf70d36212352b2dc00d5d2407829ae37

SF: Fix DisplayTransactionTest

SetupNewDisplayDeviceInternalTest.createHwcVirtualDisplay was failing
after presubmit unit tests were enabled on pi-dev-plus-aosp.

It turned out somehow the test had gotten out of sync with the
implementation, and the expectations did not match for one of the cases
tested.

This patch simply fixes the test to use the correct expectations for
what calls are made for a HWC supported virtual display when one is
created.

Bug: 118887786
Test: Presubmit passes

Change-Id: I366e51d81ae3cb048e7a287e4f859ac92c55a20f

exclude broken test from presubmit

Bug: 111454530
Bug: 118754178
Test: runng this change via forrest
Change-Id: I7c1b2ae81feba7d9798cf7dcb999499b5a2cb27f
Merged-In: I7c1b2ae81feba7d9798cf7dcb999499b5a2cb27f
(cherry picked from commit 2e702c31452b27b757632544d0c479beee81b21b)

Snap for 5066295 from e23933651a4ff6995d01b2b29cadfa4733106573 to pi-qpr2-release

Change-Id: I1e886e3c861aba799f66c8eaef967fa2f9180e2e

libui: add boundary check to GraphicBuffer::unflatten am: bf8d7210c4
am: 11ed3dccbd

Change-Id: I29e41b7825be1d65aade78e8c536908183112b01

libui: add boundary check to GraphicBuffer::unflatten
am: bf8d7210c4

Change-Id: Ia2ccc52e854e324cebd978ca648de438c23ae660

libui: add boundary check to GraphicBuffer::unflatten

Commit cb496acbe593326e8d5d563847067d02b2df40ec removed the boundary
check by accident.

Bug: 114223584
Test: manual
Change-Id: I057bc02d5807e438530d1a5327c2e02b9d154151

Snap for 5044688 from 738966bf16e72ca15d5cd8fcc8a6ba1533082020 to pi-qpr2-release

Change-Id: I8be683c29516465a0c30b742f6da13577f2c4a29

SF: Enforce a size limitation on SurfaceTracing

SurfaceTracing records operations of each frame update. It can exhaust
more than 2GB on memory heap in 5 mins if display keeps updating.
Enforce a size limitation on it and stop automatically to prevent memory
and storage from exhausting.

Note: Merge changes Iadbc1894, I3a3e499a

Bug: 115434782
Test: Trigger SurfaceTracing on/off repeatedly for thread-safe
Test: Enable SurfeaceTracing and let it disabled automatically

Change-Id: I52d945f86a7bc501590b7c311f63a6273b9192fd
Merged-In: I52d945f86a7bc501590b7c311f63a6273b9192fd

Add batterystats -c data to telephony bugreports

Telephony bugreports currently capture 'dumpsys batterystats' output,
but only in its human-friendly format.  While humans may enjoy that
format, Historian does not, and fails to properly load telephony
bugreports (including those triggered by LowPowerMonitor) as a result.
This makes it essentially impossible to use Historian when triaging/
analyzing telephony-style bugreports.

To enable Historian processing of telephony bugreports, this change adds
the 'checkin' format ("dumpsys batterystats -c") data along with the
existing entries.

ABT (Android Bug Tool) still doesn't properly list dumpsys sections in
its UI even with this change, but I think nothing short of a full,
comprehensive dumpsys run will make ABT happy.  And that's okay, because
all of the text content can still be navigated manually.

Bug: 111763716
Test: Triggered telephony bugreports with and without the change on an
appropriate device, manually verified that the checkin format data was
present with the code change in place, and loaded the bugreport into
Historian successfully.

Change-Id: Iba434bfd219c627cd3c058e549a627947d9ce501

Snap for 4972147 from cf39b7bcad8c4d099b29ad42c6d524837fe3b2ea to pi-qpr1-release

Change-Id: Ib136e79d83908bb78ebcd3372d1ffdab1d492646

DO NOT MERGE Apply scissor in render engine for main display

Bug: b/113041377
Test: manually
Change-Id: I651357d456f13ff67961b75d3630aca91aa512ac

Merge "Get screencap working correctly in landscape mode" into pi-dev

Merge "Add getDisplayViewport for screenrecord tool" into pi-dev

Fix a typo when checking a touch is within the physical frame.

Bug: 112876936
Test: enable notchless simulation, try seascape apps, try swiping down
Change-Id: I8a155e16c19c474e605cb5a8d938e04461646027

Get screencap working correctly in landscape mode

Bug: b/112869712
Test: adb shell screencap in all screen rotations
Change-Id: I62b38775f8253bea85a1870ad63cd27715754656
Merged-In: I62b38775f8253bea85a1870ad63cd27715754656

Snap for 4969136 from 22f1e9cfb73cc53b0417d3a27b901cccb2b4b4bc to pi-qpr1-release

Change-Id: Idb5ca2d6a0f313ccc04fab1aeb42f78e7d55acfa

Add getDisplayViewport for screenrecord tool

Bug: b/112869712
Test: adb shell screenrecord
Change-Id: I9f3f99de1a5bafc5318b24484f1916d28dcdfaa7
Merged-In: I9f3f99de1a5bafc5318b24484f1916d28dcdfaa7

Merge "Make sure that touches are within the physical frame." into pi-dev

Make sure that touches are within the physical frame.

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

Get screenshot to exclude black cutout

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

Snap for 4963492 from 99b4619cfeb1e8ed899ca0a4c72154be6263a98c to pi-qpr1-release

Change-Id: I81bdfaf735a3fcfa8684edbf06534ce717965a08

surfaceflinger: silence misleading virtual display errors

Do not call HWComposer::

  getColorModes
  getRenderIntents
  getHdrCapabilities
  getSupportedPerFrameMetadata
  getLayerReleaseFence

when the display id is invalid.  This happens with virtual displays
when mUseHwcVirtualDisplays is false.

Bug: 112082244
Test: screenrecord
Change-Id: Ifd8a85fc15e1628744bf21277bd8fe3e2c322e46
Merged-In: Ifd8a85fc15e1628744bf21277bd8fe3e2c322e46

Snap for 4949382 from da1217f5fedc6e6ec9c4aed4f96be8b47ecf3ec4 to pi-qpr1-release

Change-Id: If166dae2e53450d79a0c0c5bf84a41e0e070c58b

[automerger skipped] Merge "AOSP builds do not support Device ID attestation" into pie-vts-dev
am: 78c0e32983  -s ours

Change-Id: I72a673a29f979ef87d789af4993a80c81bdb67d8

Merge "AOSP builds do not support Device ID attestation" into pie-vts-dev

AOSP builds do not support Device ID attestation

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
Merged-In: I55e7c68b3e082af465c19cf18aeeeecffc4eb356
Change-Id: I55e7c68b3e082af465c19cf18aeeeecffc4eb356
(cherry picked from commit 4260ee9282f9666821dbdb4e7dda6c65f605a6b2)

Snap for 4930082 from 56eb975447788a58b3a8f858655c964d35e0ba75 to pi-qpr1-release

Change-Id: Ib548805caedaf8afdb2f4d7a45fc67a62b0b89f5

SF: Layer children should call parents' onFirstRef

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

Snap for 4916303 from bde9db506f38bb8caa6df016ca25fef5410b88b4 to pi-qpr1-release

Change-Id: I6a6f14ff9f5c416859d174b0c05e622807ecbad9

Merge "SF: Add GL texture pool" into pi-dev

Do not block on allocating buffers

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

Add current frame and barrier layer info to protobuf.

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

Add SF proto dump to bugreport

Bug: 111062294
Test: adb bugreport
Change-Id: I40aa5f75d40b401b4f0eef5390106b3dac62ef43

Merge changes from topic "boot-splash" into pi-dev

* changes:
  surfaceflinger: default to DisplayColorSetting::ENHANCED
  surfaceflinger: signalRefresh after boot animation starts

Merge "atrace: make 'lowmemorykiller' directory optional for memreclaim" into pi-dev

surfaceflinger: default to DisplayColorSetting::ENHANCED

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

surfaceflinger: signalRefresh after boot animation starts

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

Merge "[SurfaceFlinger] Avoid querying Power HAL until switching color mode." into pi-dev

atrace: make 'lowmemorykiller' directory optional for memreclaim

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

[SurfaceFlinger] Avoid querying Power HAL until switching color mode.

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

[SurfaceFlinger] Apply legacy saturation matrix globally for Display P3.

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

Merge "Add new PowerAdvisor interface for SF to pass hints to the power HAL." into pi-dev

Add new PowerAdvisor interface for SF to pass hints to the power HAL.

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

Merge "AOSP builds do not support Device ID attestation" into pi-dev

Merge "Don't access system properties from vendor code." into pi-dev

SF: Add GL texture pool

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

Merge "SurfaceFlinger: Fixes around rotation and cropping." into pi-dev

SurfaceFlinger: Fixes around rotation and cropping.

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

Don't access system properties from vendor code.

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

AOSP builds do not support Device ID attestation

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

Allow for more flexible vsync-offsets

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

Merge "Camera: update tonemap curve images" into pi-dev

Merge "libbinder: fix using destroyed mutex warning." into pi-dev

Camera: update tonemap curve images

Bug: 74942037
Merged-In: I2b4bffd685ddcb8899fb427b14c8a0ab937725c3
Change-Id: I2b4bffd685ddcb8899fb427b14c8a0ab937725c3

Merge "surfaceflinger: prime shader cache for P3 conversion" into pi-dev

Merge "surfaceflinger: force client composition for Y410" into pi-dev

surfaceflinger: force client composition for Y410

When the pixel format is Y410 masquerading as RGBA_1010102, always
force client composition.

Bug: 80509363
Test: no effect on Pixel devices
Change-Id: I31996eeda1559b0557a5acb53d593fd4f395ccaf
Merged-In: I31996eeda1559b0557a5acb53d593fd4f395ccaf

Merge "[SurfaceFlinger] Respect HDR data space." into pi-dev

[SurfaceFlinger] Respect HDR data space.

Respect HDR data space when there is no legacy HDR support. Previously we only
cared about HDR data space when it is supported, however, on Pixel 2 there is
no HDR mode support. This patch makes sure that when HDR mode is not supported,
we fall back to Display P3 color mode correctly.

BUG: 80404330
Test: Build, flash and watch Youtube HDR
Change-Id: I7d27711fe4d33268e5ebbd14fce0975f9e642e84
Merged-In: I7d27711fe4d33268e5ebbd14fce0975f9e642e84

libbinder: fix using destroyed mutex warning.

Bug: 77473515
Test: run `pm list instrumentation` for several hours,
Test: and no warning appears.
Change-Id: I66a39ddd66731779fdc6e534f827ad524685b3ba

Merge "SF: Add workaround to release screenshot buffer" into pi-dev

surfaceflinger: prime shader cache for P3 conversion

Bug: 77287550
Test: no shader compilation when WCG apps start
Change-Id: I45cdefc97c5e9060269060e33d79b40304cfdbbf

Merge "Use correct StateSet for LayerVector compare." into pi-dev

Use correct StateSet for LayerVector compare.

Currently LayerVector compare function was using the current StateSet.
This is incorect since the LayerVector may be created with the intention
of sorting the layers by drawing state. Instead, create the LayerVector
with a specified StateSet so the compare function always uses the
correct state.

This fixes an issue where the layers were getting added and sorted by
current state z order but the caller expected the order to be by drawing
state z order.

Change-Id: I7afef556fa72f687bcfeb0a642465488cc72f40b
Fixes: 80516823
Test: No longer flicker when IME closes. Logs show correct z order.
Merged-In: I7afef556fa72f687bcfeb0a642465488cc72f40b

Merge "Push existing pending state when deferring transaction" into pi-dev

SF: Add workaround to release screenshot buffer

Works around driver behavior to force the [E]GL driver to fully release
the screenshot buffer immediately after the screenshot is complete
rather than deferring until the next instance of client composition.

Bug: b/77935566
Test: Manual, inspect 'dumpsys SurfaceFlinger' after launching an app
      and then returning home (which causes a screenshot for overview)

Change-Id: I4f33d89f3ff3020707a9f556a1fcfe34bc9b7adb

Otadexopt: removing bootdevice from /dev/block/bootdevice/by-name/*

We should switch to use /dev/block/by-name/<partition> because there is
no requirement to have a single 'bootdevice' for Android. The symlink is
created in the following change:

  https://android-review.googlesource.com/c/platform/system/core/+/674989

Bug: 80466341
Bug: 78613232
Test: m -j otapreopt_chroot
Test: Successful go/manual_ab_ota on walleye

Change-Id: I26fbf67e72cc2ee93909e95b0254ba1602e6ae8e
Merged-In: I26fbf67e72cc2ee93909e95b0254ba1602e6ae8e
(cherry picked from commit 19d2d08bfbc3840a93762011d6a2763bd37be05a)

Merge "Keep early vsync-offsets for at least two frames after transaction" into pi-dev

Push existing pending state when deferring transaction

Otherwise the information from another transaction that happened
before deferring the transaction could have been deferred as well.
To fix that, we push the currently pending state if the
transaction is deferred.

Furthermore, we need to modify the behavior how flags are applied.
Imagine the following sequence of events
- Surface is hidden flags=hidden
- t1 doesn't modify the flags (0/0) but sets some other properties.
flags=hidden mask=0. mCurrentState gets pushed onto mPendingState
before t2 sets (0/hidden) (flags/mask) flags=0 mask=hidden, to
show the surface. Furthemore, we defer this transaction.
mCurrentState gets pushed onto mPendingState.
- At this point, mCurrentState.flags = 0 (shown), but
mDrawingState.flags = hidden
- doTransaction happens. c (the state to promote to drawing state)
= mCurrentState => c.flags = 0 (shown)
Since t1 isn't deferred, the 0th element of mPendingState gets
popped and applied to c. Since mask=0, c.flags = 0 still.
- c gets promoted to mDrawingState and BOOM the
surface was shown even though the barrier of the transaction
showing hasn't opened yet.

Looking closer at the logic it makes sense to just apply the mask
when modifying the current state, and then just pushing it like
all other attributes.

Test: go/wm-smoke
Bug: 78611607
Change-Id: Ia100532189ef7f59f8939c59db9b6292b41e8e77

Merge "surfaceflinger: RenderIntent::COLORIMETRIC is no longer mandatory" into pi-dev

surfaceflinger: RenderIntent::COLORIMETRIC is no longer mandatory

RenderIntent::COLORIMETRIC is mandatory only for SDR color modes.
For HDR color modes, RenderIntent::TONE_MAP_COLORIMETRIC is
mandatory.

Bug: 80030364
Test: HDR videos
Change-Id: I70d96ac66d069218d789dded330169284a61bde1

Fix cleanup of swapchain images in the shared case

Previously we'd fail to call DestroyImage for images in the shared
swapchain. We only need to skip cancelBuffer.

Bug: b/78779994
Test: dEQP-VK.wsi.android.*
Change-Id: Ic95887fb76a8ab5d01e6e3aaa3f63dddc697ea4c

Merge "surfaceflinger: fix race condition" into pi-dev

Merge "[RenderEngine] Add inverse tone mapper." into pi-dev

surfaceflinger: fix race condition

surfaceflinger only has one thread.

main thread is:
a). startHidlServices
b). do a getService
c). getService receives notification on binder thread and returns
d). binder ServiceManager register SF service

Then, started by a).
hwbinder thread is (DisplayService's, when it receives a transaction):
e). binder ServiceManager get SF service ( (d) must happen first! )

Normally, (e) never happens because nothing calls into DisplayService
until later. However, on a particular QCOM device (b/80061790),
surfaceflinger restarts at just the right time that this sequence happens:
(a) (b) (e)

then (c) is blocked since (e) is on a binder thread).

Test: QCOM device no longer enters this deadlock
Test: boot up on Pixel device
Test: (sanity) check to make sure surface flinger has one hwbinder thread
Test: (sanity) make sure Pixel device surface flinger doesn't register an
    allocator when it isn't supposed to.

As a follow-up, the return values from these various services will be
checked.

Bug: 80061790
Change-Id: I254d70951ee9508790c940240bcd1da5af746dd3

[RenderEngine] Add inverse tone mapper.

This patch inverse the tone mapping process from hardware composer to make sure
we have minimum brightness change when HDR video is being played.

BUG: 73825729
Test: Build, flash, watch Youtube HDR
Change-Id: I6dd73d520d316e2ae4a890211b7282053d9b8568

Keep early vsync-offsets for at least two frames after transaction

Imagine the following sequence, in which vsync-sf is usually 4ms
behind vsync-app.
- Vsync-app fires. The app sends a transaction with early wakeup.
- Vsync-sf fires immediately after early wakeup is received,
before the regular 4ms delay.
- Vsync-sf resets itself to vsync-app+4ms as the transaction was
handled.
- Repeat 1, but now the app was a bit delayed and sends the early
wakeup late, such that the time used to do GL comp isn't enough to
avoid jank.

To fix this, we apply a low pass filter for transaction-caused
early wake and keep it early for at least 2 frames.

Test: Open/close apps, inspect systraces and verify wake-up times
Bug: 78611607
Change-Id: I74b0d88a4d95ca5b6d24950e14e3d6a9379f2714

Disable dex2oatd for release background compiles

Use dex2oat rather than dex2oatd for release versions of
userdebug builds to get more soak time.

Bug: 73769503
Test: adb shell cmd package bg-dexopt-job
Change-Id: Id66777e8e49885cf4579d41364d10808df49b63e

Merge "Log Binder Proxy Limit reached only once" into pi-dev

Merge "Adding a file to use for excluding features from aosp" into pi-dev

Merge "Need GSI to support landscape LCM" into pi-dev

Log Binder Proxy Limit reached only once

Bug: 79578081
Test: bit FrameworksCoreTests:android.os.BinderProxyCountingTest
Change-Id: Ia0d4148d5d9d5b57fe69b86b280fbeb7e68dca2a

Adding a file to use for excluding features from aosp

android.hardware.location.network is incorrectly getting included in
aosp targets without a valid location provider. Adding this xml to
include in aosp target configurations.

Test: lunch aosp_taimen-userdebug; build and flash
Then
atest android.app.cts.SystemFeaturesTest

Bug: 33380753
Change-Id: I4f4d189bd605b8d4798dbd7640ac56cbec28c618

Merge changes from topic "color-vendor-intents" into pi-dev

* changes:
  surfaceflinger: allow unknown render intents
  surfaceflinger: display color setting is a hint
  surfaceflinger: compute color mode mappings on hotplug

Need GSI to support landscape LCM

When device uses landscape LCM, the nature of the screen shows that
the device is a portrait device. After we flash with GSI, there is
vendor solution for landscape LCM used at portrait device. As the
result, the screen displays landscape layout and orientation while
device is at portrait orientation. In addition, the sensor coordinate
system mismatches with android coordinate system.

We suggest Google can add config to handle the case "portrait device
uses landscape LCM or landscape device uses portrait LCM".

Bug: 69691076

Test: We verified following test cases for this patch on Android O-MR1.
    1. Make sure homescreen is normal
    2. Rotate device and make sure screen is normal
    3. Grab screen shot and check if screen shot is normal
    4. Connect to Wi-Fi display and make sure WFD screen is normal
Test: Tested 1, 2 and 3 on Pixel 2.

Test: artifially setup 90 degree rotation on Pixel and make sure that
    screenshots are aligned to the screen.

Change-Id: Ib42c9a216e8a6fe465139d6eece152fb1765b422

surfaceflinger: allow unknown render intents

Allow render intents that are unknown to SurfaceFlinger.

Bug: 79843697
Bug: 75981986
Test: manual
Change-Id: Ia81436747b1d2fe9f44e749b93a9c1a5a7f1f6cb

surfaceflinger: display color setting is a hint

Display color setting is merely a hint.  Check the active render
intent before applying the legacy sRGB color matrix.

Bug: 79843697
Test: manual
Change-Id: I73b45cbf2274a56037ce0439470f1baafffa8914

surfaceflinger: compute color mode mappings on hotplug

Populuate DisplayDevice::mColorModes when a DisplayDevice is
created.

DisplayDevice::mColorModes is a map from any possible
Dataspace/RenderIntent to supported
Dataspace/ColorMode/RenderIntent.  This makes sure we never ask the
composer to use an unsupported Dataspace/ColorMode/RenderIntent
combination.

The map is populated on hotplug because we don't want to compute the
mapping on the fly at each frame.

Bug: 79843697
Bug: 75981986
Test: manual under sRGB, P3, HDR
Change-Id: I967d09b1e8d31ea631b202db1799a7a2a0c5ee3f
Merged-In: I967d09b1e8d31ea631b202db1799a7a2a0c5ee3f

Merge "Atrace: Add the debug.atrace.user_initiated property." into pi-dev

Merge "surfaceflinger: layer dataspace is not a state" into pi-dev

Atrace: Add the debug.atrace.user_initiated property.

This will ensure that, when we're tracing, the
debug.atrace.user_initiated tracing property will be set to 1.
We can then reliably use that property to determine whether an atrace
trace is in progress. Previously, we were using the
debug.atrace.tags.enableflags property, which is only set to a value
when a userspace tracepoint is being traced.

Bug: 79998861
Test: Took traces of only the 'sync' tag and verified with logging
that Traceur was representing the trace state correctly when entering
and exiting the app.
Test: Took a trace using the default category list and saw other
userspace tracepoints in the output (such as activityStart).

Change-Id: Iaf807f14ee65dc14e85d3d8d2ba489fcf742e3cc

Merge "surfaceflinger: initialize DisplayDevice data members" into pi-dev

Merge "Create temp refs on proxies." into pi-dev

surfaceflinger: initialize DisplayDevice data members

Initialize mActiveRenderIntent and mCompositionDataSpace.

Bug: 80170891
Test: libsurfaceflinger_unittest
Change-Id: I7af510679f94332509b39a7ee54f68ff767c3da7

surfaceflinger: layer dataspace is not a state

Like current crop or transform, layer dataspace is latched with the
buffer.  It is not a layer state, and should take effect
immediately.

Bug: 80139629
Test: manual
Change-Id: I52342ca345f174e647550b45defa977484db95a1
Merged-In: I52342ca345f174e647550b45defa977484db95a1

Create temp refs on proxies.

Fixes the following scenario:
1) Thread T1 receives a binder proxy and adds a local strong/weak ref
2) Thread T1 queues BC_ACQUIRE/BC_INCREFS (but does not flush)
3) Thread T1 hands the binder proxy off to another thread T2, which
   adds another strong ref
4) Thread T1 now drops its own ref to the proxy, but it doesn't get
   destructed because T2 has its own ref to it
6) Thread T2 runs and drops its own ref to the proxy, which causes a
   BC_RELEASE/BC_DECREFS to be queued to the driver.

Now, if T1 writes its command queue to the driver first, everything
is fine, because a BC_ACQUIRE/BC_INCREFS will be followed by a
BC_RELEASE/BC_DECREFS. However if T2 writes its command queue first,
BC_RELEASE/BC_DECREFS will be sent first, and the driver will delete
the reference prematurely.

Fix this by temporarily holding a weak/strong ref until the initial
BC_ACUIRE/BC_INCREFS is flushed to the driver.

Bug: 78437964
Test: sailfish builds, boots, no invalid ref messages on dumpsys
Change-Id: Ica5efaf9fa2785423c37abb1456575d97f1cd85f