Change-Id: If20455e569194ae05609258a737cd8a069455e76

Some HAL implementations can't support setLayerBuffer multiple times to
clear the per-layer buffer caches. Therefore, default this behavior to
disabled, and allow HALs to explcitily enable this behavior to obtain
the necessary memory savings.

Test: play videos with both true and false on both HIDL and AIDL
Bug: 285561686
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:f70d9c4528888134e16003470b76dd1e81b8631d)
Merged-In: I928cef25e35cfc5337db4ceb8581bf5926b4fbe3
Change-Id: I928cef25e35cfc5337db4ceb8581bf5926b4fbe3

Change-Id: I456162e87dfe31eef76e335f0f52b47a94732f7f

ag/22764137 added support for HLG formats, but the spec change in
the Khronos gitlab hadn't landed yet. The enum I used had already been
used by an unpublished NVIDIA EXT, so I needed to choose a different
one. This change uses the new one which is the final correct enum found here:

https://github.com/KhronosGroup/EGL-Registry/commit/526f9a6471106090e44b8d6a123f78886d5d88fa

Bug: 277210442
Test: Manually ran new test in CL https://gerrit.khronos.org/c/vk-gl-cts/+/11608
Change-Id: I5c163b7ef2c3e6fa6f90ac8de6f75a7b7e67cf8c

Change-Id: Ibed4382e52f3abe54ebed7ca1740e28f8dca297f

Uncaptured touchpads (with DeviceMode::POINTER) still on the old stack
(i.e. the Sony DualShock 4 touchpad) were having touches ignored if they
started at coordinates that would be outside of the bounds of the
touchscreen. Since touchpads use relative motions and don't directly
relate raw touch locations to screen locations, this was incorrect, and
caused touches to be ignored with certain screen/touchpad dimension and
orientation combinations.

Bug: 280396539
Test: connect Sony DualShock 4 by USB, rotate screen to portrait, check
      touches starting in all areas of the pad are turned into pointer
      movements
Test: atest inputflinger_tests
Change-Id: I9a92ba79246ee8fc25418c2e248ae2c3839a0d58

Change-Id: Ib6ffe19372b4934bcd8681b5aec8af1de1018307

Change-Id: Id6244fcf1baebf6521d712456709d6cdbf03e554

This mount point is required for apexd, which uses libselinux to adjust
label of the compressed APEXes that are decompressed as part of the
postinstall hook.

Bug: 284277137
Test: m dist
Test: system/update_engine/scripts/update_device.py out/dist/ota.zip
Change-Id: Ia1a65a4e69b27351941a290210004a93470ae87f
Merged-In: Ia1a65a4e69b27351941a290210004a93470ae87f
(cherry picked from commit 56fd71b0)

The utility method to extract user_id and app_id from calling_uid
takes unsigned int_32. Changed the default value of calling_uid to
0 from -1 for the case when bug report is triggered by adb and calling_uid is not relevant.

Bug: 260989962
Test: tested manually by initiating a bug report through adb and
observing the BUGREPORT_STARTED broadcast in logcat.
Ignore-AOSP-First: will do it later with other headless changes.

Change-Id: I1c410853ef99c6292039382714394066a72318f7

Cap the max amount of HDR headroom beyond which the
layer is clipped. This avoids over-dimming the SDR content
range in the resulting SDR screenshot

Test: screenshot of silkfx
Bug: 286942637
Change-Id: I67df32d9c192da18df516972ed92e9bd64063186

Change-Id: I15162ace6165bf6c5d79e40337c9291106337e69

Change-Id: I33a57c02c86b15f2eb53b263d762697c24d3f170

SensorService::threadLoop() "continues" if there are no real sensor
events, which skips the handling of runtime sensor events.

Fix: 281452823
Test: m
Change-Id: I0fe9fe9a7baa19ce9c8cb32d36e736ac83d2fe52

Change-Id: Ifde8e181ac3f7e4d920e87044c72f60d25bd0f80

This updates metadata requirements for Version, GainMapMax, and
HDRCapacityMax to be required, and all others optional.

Also update the yuv-icc test image, since it seems this file was missed
on a previous CL, and the checked in version was 4:4:4 instad of 4:2:0,
which doesn't work with our decoder setup.

Bug: 286457050
Test: Added new tests, all tests pass
Change-Id: I1a6669f7bc6a8f254c4ce4ea4d359008e8e10f3e

* Correct luminance calculation for sRGB to utilize actual luminance
  coefficients for the gamut, rather than 601 luma coefficients.
* Correct YUV<->RGB conversion for sRGB to utilize Rec.709 coefficients
  rather than Rec.601 coefficients as it was previously.
* New P3 YUV<->RGB conversion, which uses Rec.601 coefficients.
* Also ICC Profile fixes to make things work; more below.
* Update things to correctly convert to and from Rec.601 YUV for jpeg
  encoding; more below.

This setup for YUV<->RGB coefficients is chosen to match the
expectations of DataSpace when it comes to interpretting YUV encoding of
data. Generally, the interpretation is cued off of the color primaries,
since the specifications around color primaries generally also specify a
YUV interpretation.

Display-P3 is a bit of an outlier; the best specification of Display-P3
is in SMPTE EG 432-1, but EG 432-1 doesn't cover YUV interpretation. So,
since DataSpace interprets Display-P3 YUV data via the Rec.601
coefficients, we should do the same here.

ICC Profile fixes; ICC profiles we wrote were broken before this for a
variety of reasons:
* The endianness macro wasn't actually swapping endiannesas to provide
  the correct encoding in our output.
* We weren't writing out the identifier for the app segment, including
  the chunk count and ID.
* We were assuming input JPEGs have ICC data, which may not be the case.
* We also need to read in the ICC profile during decode to apply the map
  properly, and we didn't have any mechanism previously to read the ICC
  profile and determine the gamut of the encoded JPEGR file.
* Upon adding ICC reading code to our JPEG decoding, also remove some
  dead code from previous EXIF reading.
* Add a number of tests to verify all of this stuff stays fixed.

YUV interpretation and Rec.601:
* Previously, we were feeding YUV right into the JPEG encoder; this is
  problematic because JPEG encoders usually (and definitely in our
  specific case) expect Rec.601 YUV encoded input data, since this is by
  definition the format of JPEG YUV data according to ECMA TR/98.
* Now properly convert from Rec.709 or Rec.2100 YUV encoding to Rec.601
  (when necessary) prior to passing YUV data to the jpeg encoder.
* Also make sure we properly interpret decoded YUV output as Rec.601
  after decode.
* This involved added some new methods to facilitate these conversions.
* Added some new tests to verify these conversions.
* Note that to do these YUV conversions for subsampled 420 data, we take
  each set of 4 Y and 1 UV, and calculate the result against each
  combination. The new Y values each get the corresponding result, and
  the new UV value is equal to the average of the set.
* Note that none of this is a concern for gain map encoding/decoding via
  JPEG because gain maps are single channel.

Bug: 283143961
Test: added new tests, all tests pass
Change-Id: Ibc7b1779fc3a8244f85abb581c554963f57dc5a4

Bug: 284807752
Test: atest CtsDeqpTestCases -- --module-arg 'CtsDeqpTestCases:include-filter:dEQP-VK.wsi.android.maintenance1.release_images.*'
Change-Id: I36bd7a3dac8f8a3f6b913733fbd0ba140ee0b092

Change-Id: I7ec4a375f69f29336ff84c4dddcf3a44805dba11

If calls to encode/decode failed, release the allocated memory
before returning the control to caller

Bug: 285546217
Test: ./ultrahdr_dec_fuzzer
Test: ./ultrahdr_enc_fuzzer

Change-Id: I276c31cc56656aa41845a16f5d28783bc3adc772

Change-Id: I63d8e17ae5af16eda60c95054dd8677d7ff85284

Bug: 282640328
Test: ./ultrahdr_dec_fuzzer

Change-Id: I9bd2a314d05122fd3010889b661455a6cba364e6

The default value of hdr white nits is zero, making log content boost
to nan in certain scenarios. This can cause decode to fail on select
architectures

Bug: 285545078
Test: ./ultrahdr_enc_fuzzer

Change-Id: I72064d4f04c25d6f3c951f5c20b0b674e675d541

Change-Id: I34610c158b1f7d70c12a2d10ce5025a6eec52cc3

Bug: 282640328
Test: ./ultrahdr_enc_fuzzer

Change-Id: I0a547f63da570433dc54eb23fbd41021022aec4e

jpeg_write_raw_data() processes one MCU row per call, and thus one must
pass buffer of at least max_v_samp_factor * DCTSIZE scanlines. The
buffer must be large enough to hold the actual data plus padding
to DCT-block boundaries.

Bug: 284117683
Test: ./ultrahdr_enc_fuzzer

Change-Id: I993773817bf3805463bb21bb977624d6c2d45a0b

Currently, SF is using the wrong vsync value when calculating the
target for ADPF, causing it to send a binder every frame instead of
every vsync change. This patch fixes that to reduce the binder
frequency from SF, and also adds a debug option to disable reportActual
to reduce the amount of binders even more in certain cases.

Bug: 284357218
Test: manual
Change-Id: I8435b170016c5af8219d8ed8cc9ed65a0a2cb0e7

Bug: b/284056586
Test: manual
Change-Id: Ieb2ef32789237dc9e426a26a67f319feeb028548

Change-Id: I1c75802bc9aff17ba7d48012fedcac0251c0ccda