SDK / exoplayer

PiperOrigin-RevId: 472974903
(cherry picked from commit 260aabb6)

Test that HDR editing succeeds on devices supporting HDR editing, tone maps on
devices supporting tone mapping, and throws exceptions on all other devices.

Also, only restrict HDR editing and tone mapping support to API 31+ only when
transcoding, not for all transformations.

PiperOrigin-RevId: 472958965
(cherry picked from commit 0d8fd3d4)

PiperOrigin-RevId: 472949850
(cherry picked from commit 8b7638be)

PiperOrigin-RevId: 472745311
(cherry picked from commit 5e2823bb)

The exception fires when intent resolution fails to find a service which declares an appropriate intent-filter. The existing message is confusing; it's trying to say that the service couldn't be found but the double negative renders it incorrect.

#cleanup
#minor-release

PiperOrigin-RevId: 472736740
(cherry picked from commit 15d3d74e)

#minor-release

PiperOrigin-RevId: 472714732
(cherry picked from commit 70e82a29)

If the back buffer is using too much memory, there is a risk
playback could get stuck because LoadControl refuses to load
further data. This eventually results in a stuck-buffering
playback error.

We can detect this case, clear the back buffer and then ask
the LoadControl again to avoid failing playback in such a case.

PiperOrigin-RevId: 472679797
(cherry picked from commit 310e0fec)

PiperOrigin-RevId: 472522846
(cherry picked from commit c401fb97)

PiperOrigin-RevId: 472500789
(cherry picked from commit 9e1e0a10)

The stream offset is used to calculate the presentation time of
a metadata object when reading and later when playing, to calculate
the current presentation time to decide whether to send the metadata
to the output.

Accordingly, the presentation time of a pending metadata that has been
calculated with a given offset needs to be recalculated when the
stream offset changes.

#minor-release

PiperOrigin-RevId: 472499943
(cherry picked from commit 0896c4dd)

PiperOrigin-RevId: 472488921
(cherry picked from commit a18ab374)

PiperOrigin-RevId: 472475124
(cherry picked from commit cec6f045)

PiperOrigin-RevId: 472459423
(cherry picked from commit 3f6a59f0)

* Replace ImmutableLists to List interface for constructors

PiperOrigin-RevId: 472433434
(cherry picked from commit 5b556b3c)

PiperOrigin-RevId: 472405147
(cherry picked from commit 91e1209e)

PiperOrigin-RevId: 472325145
(cherry picked from commit 672405af)

* Non-standard parameter comment; prefer `/* paramName= */ arg`
  (see http://go/bugpattern/ParameterComment) (2 times)
* This catch block catches an exception and re-throws another, but swallows the caught exception rather than setting it as a cause. This can make debugging harder.
  (see http://go/bugpattern/UnusedException)
* This comment contains Javadoc or HTML tags, but isn't started with a double asterisk (/**); is it meant to be Javadoc?
  (see http://go/bugpattern/AlmostJavadoc)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content.
* File a bug under go/rosie-bug if there's an issue with how the CL was managed.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

Tested:
    Local presubmit tests passed.
PiperOrigin-RevId: 472255768
(cherry picked from commit 3a2e0d37)

* Non-standard parameter comment; prefer `/* paramName= */ arg`
  (see http://go/bugpattern/ParameterComment) (3 times)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content.
* File a bug under go/rosie-bug if there's an issue with how the CL was managed.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

Tested:
    Local presubmit tests passed.
PiperOrigin-RevId: 472254253
(cherry picked from commit 573ad66f)

* Non-standard parameter comment; prefer `/* paramName= */ arg`
  (see http://go/bugpattern/ParameterComment)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content.
* File a bug under go/rosie-bug if there's an issue with how the CL was managed.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

Tested:
    Local presubmit tests passed.
PiperOrigin-RevId: 472252461
(cherry picked from commit 83485bc5)

No functional changes.

PiperOrigin-RevId: 472245797
(cherry picked from commit fa1f09fc)

The assertion asserts against a `Period` and an `AdPlaybackState` which actually
asserts against a resolved ad which is what `ExoPlayerImplInternal` does later and
what gives us a `SEEK_ADJUSTMENT`. However, this assertion is not required at the
moment of masking, because we are sure that the resolved seek results in a content
period and never an ad period.

#minor-release
Issue: androidx/media#122
PiperOrigin-RevId: 471827072
(cherry picked from commit 73f86682)

PiperOrigin-RevId: 471782565
(cherry picked from commit 305ea205)

shouldPassthrough's internal checks seem to be check whether we should *not*
pass through, which seemed a bit like a confusing double-negative to me.

shouldTranscode is slightly more clear, by instead returning true when we do
want to transcode.

No functional changes intended.

PiperOrigin-RevId: 471753771
(cherry picked from commit 7085c2fa)

https://github.com/androidx/media/commit/3b0d2c15867b3698f130476736785d427b28b7bd made `shouldPassthrough` always return false for `enableHdrVideoEditing`:

>We force using `FrameEditor` (no passthrough) to avoid the need to select another edit operation, and use the new shaders. The `EGLContext` and `EGLSurface` also need to be set up differently for this path.

However, this was introduced before the `videoNeedsEncoding` setting was introduced in https://github.com/androidx/media/commit/3f615040c033a37f81b1d73605cd1f7d420b47b5. That setting should apply to HDR videos as much as SDR videos.

PiperOrigin-RevId: 471569853
(cherry picked from commit bc88f8be)

Replacing remaining usage of MoreExecutors.directExecutor. This allows the service to be switched to run in another process and the app still works the same as if it is running in the same process.

Issue: androidx/media#100
PiperOrigin-RevId: 471547177
(cherry picked from commit 9a674543)

`contentTitle` and `contentText` can now be overridden.

Issue: androidx/media#150
PiperOrigin-RevId: 471287701
(cherry picked from commit a45df2fd)

* Non-standard parameter comment; prefer `/* paramName= */ arg`
  (see http://go/bugpattern/ParameterComment) (3 times)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content.
* File a bug under go/rosie-bug if there's an issue with how the CL was managed.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

Tested:
    Local presubmit tests passed.
PiperOrigin-RevId: 471198016
(cherry picked from commit 6d3cc01d)

PiperOrigin-RevId: 471137219
(cherry picked from commit 1b389ebc)

In particular, make it a bit more clear that "rendering" and "releasing" frames are
related concepts, and how they differ from one another in conjunction with frame
dropping.

PiperOrigin-RevId: 471037733
(cherry picked from commit 69714e5f)

Separate MatrixTransformationProcessor constructors by color input and output.

PiperOrigin-RevId: 471034768
(cherry picked from commit 1b648296)

* Non-standard parameter comment; prefer `/* paramName= */ arg`
  (see http://go/bugpattern/ParameterComment) (19 times)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content.
* File a bug under go/rosie-bug if there's an issue with how the CL was managed.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

Tested:
    Local presubmit tests passed.
PiperOrigin-RevId: 471022923
(cherry picked from commit b48ca6e0)

PiperOrigin-RevId: 471017440
(cherry picked from commit 85950423)

PiperOrigin-RevId: 471008623
(cherry picked from commit 3ba8bb71)

#minor-release

PiperOrigin-RevId: 470999044
(cherry picked from commit 932f0d22)

* Non-standard parameter comment; prefer `/* paramName= */ arg`
  (see http://go/bugpattern/ParameterComment)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content.
* File a bug under go/rosie-bug if there's an issue with how the CL was managed.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

Tested:
    Local presubmit tests passed.
PiperOrigin-RevId: 470953422
(cherry picked from commit 52d32be8)

This should now expect transformation to succeed.

PiperOrigin-RevId: 470950411
(cherry picked from commit daf1e5e2)

PiperOrigin-RevId: 470354448
(cherry picked from commit dbe66775)

TL;DR: we should check if there are new frames available to queue to the
ExternalTextureProcessor before actually queueing a frame.

The overall flow on the external texture processor:

- `SurfaceTexture.onFrameAvailable` is called on `ExtTexMgr`, and
  - it calls `updateTexImage()`, and sets `frame`
  - it calls `maybeQueueFrameToExtTexProc()`
    - the frame is queued to `ExtTexProc` if `frame` is set

  - From `ExtTexProc.queueInputFrame()`:
    - notifies the `frameProcessorListener` of available frame
    - notifies the `inputListener` of `onReadyToAcceptInputFrame`
      - (`ExtTexMgr` is the listener), it calls `maybeQueueFrameToExtTexProc()`
       again

-- Parallelly --
- `ExtTexProc` calls `inputListener.onInputFrameProcessed`, when the frame is
released
  - (`ExtTexMgr` is the listener), sets `frame` to `null`

*Problem*

This logic relies on `frame` to be cleared at the right time.

In transformer, it's OK b/c `ExtTexProc` release the frame immediately in
`queueInputFrame()` and calls `onInputFrameProcessed` which also reset `frame`

But in previewing, the frame is not released for a while, up to 10 ms.
In this case, `frame` will not reset in this 10 ms, and
`maybeQueueFrameToExtTexProc()` is repeatedly queueing the same input frame.

PiperOrigin-RevId: 470211620
(cherry picked from commit 91709831)

Native multidex can only be used for binaries with minSdkVersion of 21 or higher, but minSdkVersion was specified to 16.

PiperOrigin-RevId: 470004102
(cherry picked from commit d260b0c2)

Native multidex can only be used for binaries with minSdkVersion of 21 or higher, but minSdkVersion was specified to 16.

PiperOrigin-RevId: 470003836
(cherry picked from commit 5b3f3202)