SDK / exoplayer

ExoPlayer needs a codec to decide among WEBVTT and TTML decoder mimeType.
Apple describes IMSC1 in MP4 in
[RFC-8216 Section 3.6](https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-04#section-3.6).

The DASH manifest specifies the SMPTE-TT captions in the codecs in the manifest
(from W3C [TTML Profiles for Internet Media Subtitles and Captions 1.1](https://www.w3.org/TR/ttml-imsc1.1/#general-0).
DASH just doesn't require the rendition linking, but HLS does.

Apple implies the CODECS attribute of the variant needs to be do this.  That is
with SHOULD and MAY language to imply the codec to use for it in the
[Authoring Guidelines](https://developer.apple.com/documentation/http_live_streaming/hls_authoring_specification_for_apple_devices)

This change defaults to WebVTT if no codec is specifed (same as current behavior) otherwise it picks it from the variants
referencing the media.

PiperOrigin-RevId: 303937576

This is used to generate the initialization vector for encrypting the
cache contents.

Startblock:
   <unknown commit> is submitted
   and then
   3w have passed
PiperOrigin-RevId: 303932151

This was messed up by me in https://github.com/google/ExoPlayer/commit/a035c2e20a4ce25bd86774a870b5960bcfa6f0df

PiperOrigin-RevId: 303930392

PiperOrigin-RevId: 303829900

PiperOrigin-RevId: 303776645

PiperOrigin-RevId: 303764399

These are about 5% flaky, so for now they are excluded from
continuous testing.

PiperOrigin-RevId: 303760340

PiperOrigin-RevId: 303757995

PiperOrigin-RevId: 303753642

issue:#7160
PiperOrigin-RevId: 303747338

CharSequence is used by Notification builders and allows to set Spannable text.
It's the base interface of the String class, so apps wouldn't be break after
the update.

PiperOrigin-RevId: 303731890

PiperOrigin-RevId: 303719911

PiperOrigin-RevId: 303717642

This is required to align google3's stub (currently marked non-null) with Checker Framework's.

More information: go/matcher-nullness-lsc

Tested:
    TAP train for global presubmit queue
    http://test/OCL:303344687:BASE:303326748:1585344475427:29edc250
PiperOrigin-RevId: 303709053

PiperOrigin-RevId: 303655497

PiperOrigin-RevId: 303447837

Issue: #6671
PiperOrigin-RevId: 303364788

Issue: #7046
PiperOrigin-RevId: 303354941

- They are always listed with their canonical names
- Considering aliases means that blacklisting a decoder can end up
  not actually blacklisting it, since it may still be accessible
  via an alias. It also means that our decoder fallback logic can
  end up falling back to a decoder that we've already tried!

PiperOrigin-RevId: 303348297

Issue: #7141
PiperOrigin-RevId: 303334072

PiperOrigin-RevId: 303319078

This is just for consistency with our other renderers

PiperOrigin-RevId: 303317443

PiperOrigin-RevId: 303316976

This callback will be deprecated, so moving all usages to better callbacks.
Some usages are still remaining that are less straight-forward to update.

PiperOrigin-RevId: 303298834

PiperOrigin-RevId: 303298804

OnSeekProcessed is documented to be called as soon as all neccessary state changes
as a result of the seek have been made. As we now mask the state changes directly
when calling seekTo, we can also call this callback immediately without changing
the semantics of the method.

Our tests often use this callback as a way to wait for the internal player
to receive all pending commands and then report back. This is a special test
requirement for cases where we want to make sure no further updates happen as
a result of the player handling commands. To facilitate that, a new action is
added with a more descriptive name that achieves the same goal.

PiperOrigin-RevId: 303296210

PiperOrigin-RevId: 303286872

PiperOrigin-RevId: 303283147

PiperOrigin-RevId: 303217607

PiperOrigin-RevId: 303170259

issue:#7122
PiperOrigin-RevId: 303154493

Also document FrameworkMediaDrm overrides as dependent on API level.

These two methods call through to equivalent methods on MediaDrm that
were added in 23:
https://developer.android.com/reference/android/media/MediaDrm#setOnExpirationUpdateListener(java.util.concurrent.Executor,%20android.media.MediaDrm.OnExpirationUpdateListener)

PiperOrigin-RevId: 303102370

It looks like the video path will use a separate FfmpegVideoDecoder

Issue: #2159
PiperOrigin-RevId: 303068617

Defines a new no_native_gvr build rule in ExoPlayerV2 that doesn't depend on the shared object in the VR sdk.

PiperOrigin-RevId: 302945930

This moves the playlist API methods to the Player interface. Implementation is moved from ExoPlayerImpl to BasePlayer where possible.

Further the CastPlayer is changed to implement the Player interface. Proper migration of the Playermanager to not use the ConcatenatingMediaSource anymore follows in a separate, future CL.

PiperOrigin-RevId: 302937779

Most of these are no longer needed since https://github.com/google/ExoPlayer/commit/aa9eb5abc9b2b121db52d436215f40805928599c

Cleanup change automatically generated by error-prone refactoring
//java/com/google/devtools/staticanalysis/errorprone:UnnecessaryJavacSuppressWarnings_refactoring on targets third_party/java_src/android_libs/exoplayer/v2/... java/com/google/android/libraries/exoplayer/v2/...

PiperOrigin-RevId: 302916092

Add some mitigation about why this is probably on OK limitation.

PiperOrigin-RevId: 302907940

This is less confusing than having audio processing functionality (e.g., playback
speed adjustment) just "not work" for some pieces of media.

If this change is merged, I will update #6749 to also track making DefaultAudioSink
intelligently enable/disable float output depending on how the audio processors are
configured.

Issue: #7134
PiperOrigin-RevId: 302871568