SDK / exoplayer

Most of the super-interfaces are deprecated, but the intention is that
only the types are deprecated and the methods themselves shouldn't be.
In order to reflect this in javadoc we override all the methods in
`Player.Listener` in order to 'cancel' the deprecation.

This change deliberately doesn't override methods that are explicitly
deprecated with documented replacements (like
`Player.EventListener#onPlayerStateChanged`) - these should contine to
be marked as deprecated in javadoc.

PiperOrigin-RevId: 384253725

Android doc:https://developer.android.com/reference/android/app/Notification.Builder#setOnlyAlertOnce(boolean)

PiperOrigin-RevId: 384227580

#minor-release
Issue:#9158
PiperOrigin-RevId: 383660258

Issue: #9005
PiperOrigin-RevId: 382765045

MediaItem.mediaId used to default to the content URI, but this changed:
https://github.com/google/ExoPlayer/commit/cc26a92e070db8963738beed423bb4699762877f

Before the mediaId change linked above, a playlist of different content
all with the same ad URI would play the ads for every item. After the
change the ad would only play once (because mediaId == "" for every
item, so they're all the same). This change restores roughly the
original behaviour by always considering both mediaId and the content
URI.

Issue: #9106
PiperOrigin-RevId: 382763618

PiperOrigin-RevId: 382763308

The serialization scheme used here is custom, it doesn't need
to be compatible with emsg-v0 or emsg-v1 (since
https://github.com/google/ExoPlayer/commit/97183ef55866170807910cd626264d82d41d46d4).

This means that C.TIME_UNSET will propagate correctly through the
serialization.

Issue: #9123
PiperOrigin-RevId: 382762873

Without this annotation it seems that `SimpleExoPlayer` effectively
'un-deprecates' the method, specifically:
* A usage of these methods isn't flagged by Android Studio if the
  declared type is `SimpleExoPlayer` (up-casting to e.g.
  `ExoPlayer.VideoComponent` results in the warning showing up).
* The `SimpleExoPlayer` javadoc doesn't mention this method is
  deprecated:
  https://exoplayer.dev/doc/reference/com/google/android/exoplayer2/SimpleExoPlayer.html#addVideoListener(com.google.android.exoplayer2.video.VideoListener)
* The Metalava API output for `SimpleExoPlayer` doesn't show these
  methods as deprecated.

PiperOrigin-RevId: 382756174

PiperOrigin-RevId: 382139109

Issue:#7608
PiperOrigin-RevId: 382081687

PiperOrigin-RevId: 381852972

PiperOrigin-RevId: 381833313

Previously, a SocketTimeourException is used to signal the end of the stream
that is caused by "no RTP packets received for a while". However, such
signaling is inappropriate under TransferRtpDataChannel, or FakeRtpDataChannel
in RtspPlaybackTests.

Hence, the signaling of end of stream is changed to use RESULT_END_OF_INPUT.
The RtpDataChannel implementations will Still block until a set timeout, but
will return a C.RESULT_END_OF_INPUT should a timeout occur, instead of
throwing a nested SocketTimeoutException.

This also allowed customization of the timeout amount, in
RtspMediaSource.Factory

PiperOrigin-RevId: 380981534

Amend release note for https://github.com/google/ExoPlayer/commit/46bc49a4f6e8194ddb28e7b17eb775157c3e241d.

PiperOrigin-RevId: 380766548

Issue: #9086
PiperOrigin-RevId: 380756562

The problem occurs when the primary media playlist URL switches
from one whose latest snapshot has not yet got the ended tag, to
one whose latest snapshot already has the ended tag. In this case:

- We trigger a redundant load of the ended playlist.
- When the redundant load completes,
  MediaPlaylistBundle.processLoadedPlaylist detects that the
  playlist is unchanged from the one it already has, and so
  doesn't call onPlaylistUpdated.
- PrimaryPlaylistListener.onPrimaryPlaylistRefreshed is never
  called with the new primary. Hence the externally visible primary
  is still the one that hasn't ended. HlsMediaSource therefore thinks
  the event hasn't ended, which in turn prevents the player from
  transitioning to the ended state.

This commit detects when the new primary already has the ended tag.
In this case, we call onPrimaryPlaylistRefreshed directly and remove
the unnecessary playlist load.

Issue: #9067
#minor-release
PiperOrigin-RevId: 380680532

The glitches were introduced in:
https://github.com/google/ExoPlayer/commit/6c31e34528

The problem is that Listener.onEvents is called in a later looper iteration
than the listener methods that were previously used. This created a gap on
the main thread between the UI component dispatching a seek operation to the
player, and onEvents being called to update the progress bar's position.

At the start of this gap the progress bar is rendering the new position,
but its position member variable is still set to the old position. If the
progress bar is re-drawn by another message on the main thread within the
gap, it will briefly show the old position until onEvents is called.

There are multiple possible fixes to this, and the best one is probably to
modify ListenerSet to remove the gap. That's high risk though, so for now we
fix the flicker by always updating the progress immediately after the seek
is dispatched, in addition to when onEvents is called.

Issue: #9049
PiperOrigin-RevId: 380678388

#minor-release

PiperOrigin-RevId: 380655806

Issue: #9061
PiperOrigin-RevId: 380640601

This softens the language around suppressing individual test methods.
There are some legitimate cases where this is needed, e.g.
ByteArrayDataSourceContractTest has to suppress all the tests related
to non-existent resources because it's not possible to simulate that
case.

#minor-release

PiperOrigin-RevId: 380570017

Some server will wrongly insert duplicated attributes. We used to treat this as
a unrecoverable error, but it is better to treat the duplicated attributes in
an "over-writable" fashion like HashMaps.

Issue: #9080,
Issue: #9014
PiperOrigin-RevId: 380547079

#minor-release

PiperOrigin-RevId: 380531272

Also change to explicitly track the provisioning session, which makes
the code easier to reason about than always using the zero'th element
of the list.

PiperOrigin-RevId: 380181453

PiperOrigin-RevId: 379935363

Issue: #8960

PiperOrigin-RevId: 379922704

#minor-release

PiperOrigin-RevId: 379913814

Issue: #9004
PiperOrigin-RevId: 379516815

Note that this removes a workaround for malformed content, in which the
track_ID is set incorrectly. It's unclear there was sufficient reason to
implement that workaround, and so it's preferable to remove it, rather
than implementing the concept of unrecognized tracks, which would be
needed to keep it and to also fix this issue.

Issue: #9056
PiperOrigin-RevId: 379506261

The Widevine H264 samples in the demo app now log this from the EventLogger:
```
[X] Track:0, id=1, mimeType=video/avc, bitrate=772315, codecs=avc1.42c01e, drm=[widevine,cenc], res=320x142, fps=24.0, supported=YES
```

And the VP9 ones log:
```
[X] Track:0, id=1, mimeType=video/x-vnd.on2.vp9, bitrate=588256, codecs=vp9, drm=[widevine], res=320x142, fps=23.809525, supported=YES
```

#minor-release

PiperOrigin-RevId: 379498332

PiperOrigin-RevId: 379440699

PiperOrigin-RevId: 378895355

Issue: #8246
PiperOrigin-RevId: 378606475

Issue: #9032
PiperOrigin-RevId: 378605169

It is the current public stable version and it brings in @DoNotInline.

PiperOrigin-RevId: 378119413

In Android 12 mutability flags have to be set on PendingIntents. If they
are not, and the app targets Android 12, then the app will be crashed by
the system.

PiperOrigin-RevId: 373427591

r2.14.1

#minor-release

PiperOrigin-RevId: 378844770

#minor-release

PiperOrigin-RevId: 373351014

PiperOrigin-RevId: 378665771