Adds HDR bitmap support to the image playback pipeline

[SathyaTadepalli]

Bug is https://partnerissuetracker.corp.google.com/issues/531143289

• HardwareBufferFrameReader derives ColorInfo from the bitmap's ColorSpace (BT2020 HLG/PQ) instead of always emitting SRGB_BT709_FULL.
  • BitmapToHardwareBufferProcessor derives the HardwareBuffer pixel format from Bitmap.Config (RGBA_1010102 → RGBA_1010102, RGBA_F16 → RGBA_FP16, else RGBA_8888) so bit depth is preserved independently of
    color space.
  • Prefers the Bitmap.copy(Config.HARDWARE) fast path for all configs. Falls back to CPU/JNI copy only when the HARDWARE path is unavailable or silently downgrades an HDR bitmap's bit depth.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[shahdDaghash]

Thanks for creating this PR!

While I start taking a look at the code, could you please ensure you've completed the Pull Request checklist in CONTRIBUTING.md? Please verify that you have signed the Google CLA, as we're unable to merge the PR without it. Let us know once that's sorted!

[SathyaTadepalli]

I have done the CLA, not sure why the check is still failing

[shahdDaghash]

Config.RGBA_1010102 was added in API 33. Since this class is @RequiresApi(26), accessing this directly on older APIs will crash. Let's add an API check here: if (SDK_INT >= 33 && config == Config.RGBA_1010102) { ... }

[shahdDaghash]

I did the code review and the change looks good. I've left a comment about a potential crash that can happen. Once this is addressed, I'll go ahead and pull the PR in for internal review and add the necessary Robolectric tests so you don't have to worry about them.

Regarding the CLA check: Thanks for signing the CLA! I can see your signature went through, but the check is still failing because of the second commit, 99fdad2.

It looks like there's a Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> line in the commit message. The CLA bot automatically checks all authors and co-authors, and since an AI can't sign a CLA, it's blocking the PR. You can see the exact error details in the CLA check logs

To get this check to pass, can you see what we can do about it? Maybe remove the co-author if possible? Let me know what happens!

[SathyaTadepalli]

I can create a new branch and create a new PR to avoid the claude. I will also implement your review comments

[shahdDaghash]

I don't think there is a need to create a new branch and PR just for this. You can try simply editing the commit description using the interactive rebase instead.

Here are the steps:

1. Run the following command in your terminal for the commit in question:

git rebase --interactive --committer-date-is-author-date 99fdad23cfcad21d2e7d776079f9495ec7b7da19^

2. In the list that appears, select r (for reword) for the commit and close the text editor.
3. The commit message will then open. Delete the Co-Authored-By: Claude Opus 4.7 line from the description and close the editor.
4. Force push the changes to your branch (e.g., git push -f).

This will update the existing PR and hopefully clear up the CLA check failure!

[SathyaTadepalli]

Created the new PR #3354
Closing this one