This annotation is only needed on public classes that are part of a
distributed library.

Switch to `@OptIn` for the one file where `@UnstableApi` was
suppressing lint errors.

PiperOrigin-RevId: 633858516

This annotation is only needed on public classes.

This change also removes the `/* package */` comment from some `public`
classes.

PiperOrigin-RevId: 633864544

Also make one class truly package-private and keep the comment instead.

This comment should only appear on elements with default (package-private) visibility.

PiperOrigin-RevId: 633911914

PiperOrigin-RevId: 633912487

PiperOrigin-RevId: 633917110

The test currently resets the time too far in the past and then has
to run through ~30000 additional iterations of doSomeWork to reach
the end, sometimes triggering the test timeout.

Fix it by resetting the time to the intended start position when
transitioning items.

PiperOrigin-RevId: 633918706

This class is not ready for production app usage yet, so it is still
marked `@RestrictTo(LIBRARY_GROUP)` for now. Apps can experiment with it
in a non-prod context by suppressing the associated lint error.

* Issue: #1014
* Issue: #1185
* Issue: #816

PiperOrigin-RevId: 633921353

https://developer.android.com/media/platform/supported-formats#image-formats was updated to include AVIF support in API 34+, so <unknown commit> updated our associated Util's to reflect this. After that change, ExoPlayer's BitmapFactoryImageDecoder will be able to decode AVIF, but the player won't be able to detect or extract it. Add this support for completeness, so that ExoPlayer can continue to say it supports all formats in https://developer.android.com/media/platform/supported-formats#image-formats.

PiperOrigin-RevId: 633956245

PiperOrigin-RevId: 633973723

To override this change, and go back to parsing during rendering,
apps must make two method calls:

1. `MediaSource.Factory.experimentalParseSubtitlesDuringExtraction(false)`
2. `TextRenderer.experimentalSetLegacyDecodingEnabled(true)`

PiperOrigin-RevId: 634262798

Fix "subtitles rendered with border and no fill color" problem:
moneytoo/Player#413

because '0' means it's an index to the palette table, not an RGBA value of 0

PiperOrigin-RevId: 634289663

ExoPlayer sometimes calls AudioSink.playToEndOfStream before configuring
the sink. Before this CL, the composition player was failing if this
happened.

PiperOrigin-RevId: 634306592

PiperOrigin-RevId: 634345071

Also Use `Iterables.toArray()` to void the confusing `List.toArray()` method call

PiperOrigin-RevId: 634351844

PiperOrigin-RevId: 634409758

This was accidentally introduced in 4fde35c

PiperOrigin-RevId: 634465380

PiperOrigin-RevId: 634474584

PiperOrigin-RevId: 634495944

Before this change, if a playback error is thrown the test fails with a
timeout and no additional info:

```
java.util.concurrent.TimeoutException
	at androidx.media3.exoplayer.e2etest.WebvttPlaybackTest.stallPlayerUntilCondition(WebvttPlaybackTest.java:361)
```

After this change, the test failure includes a much more useful stack
trace, e.g. from 0352db9:

```
Caused by: java.lang.IllegalStateException: Legacy decoding is disabled, can't handle text/vtt samples (expected application/x-media3-cues).
	at androidx.media3.common.util.Assertions.checkState(Assertions.java:100)
	at androidx.media3.exoplayer.text.TextRenderer.assertLegacyDecodingEnabledIfRequired(TextRenderer.java:587)
	at androidx.media3.exoplayer.text.TextRenderer.onStreamChanged(TextRenderer.java:210)
```

PiperOrigin-RevId: 634672138

The method is only allowed to be called on prepared items.
This check was currently missing and also causing the
corresponding test to be flaky in ExoPlayerTest.

PiperOrigin-RevId: 634694077

The two affected tests where playing until a specific
position to enable the player to read ahead. The method
pauses at exactly the target position, but then has
temporarily undetermined behavior because the playback
thread uses player.getClock().onThreadBlocked() that lets
the playback thread make progress in parallel to the test
thread. The tests were flaky because they sometimes made
so much progress that they ended playback before we could
query the updated renderer state.

This can be fixed by using
run(player).untilBackgroundThreadCondition instead, which
is guaranteed to be fully deterministic, but may not be able
to stop at exactly the desired position (which we don't
really need anyway for this test).

PiperOrigin-RevId: 634699752

For each item, AudioGraphInput now pads the input audio track with silence
to the duration given in onMediaItemChanged.

Possibly resolves Issue: #921 .

PiperOrigin-RevId: 634753721

PiperOrigin-RevId: 634817614

This case is most likely to happen when re-preparing a multi-period
live stream after an error. The live timeline can easily move on to
new periods in the meantime, creating this type of update.

The behavior before this change has two bugs:
 - The player resolves the new start position to a subsequent period
   that existed in the old timeline, or ends playback if that cannot
   be found. The more useful behavior is to restart playback in the
   same live item if it still exists.
-  MaskingMediaSource creates a pending MaskingMediaPeriod using the
   old timeline and then attempts to create the real period from the
   updated source. This fails because MediaSource.createPeriod is
   called with a periodUid that does no longer exist at this point.
   We already have logic to not override the start position and need
   to extend this to also not prepare the real source.

Issue: #1329
PiperOrigin-RevId: 634833030

This should be no-op overall and helps to disentangle the clock sync
update from the state of the manifest.

We currently check oldPeriodCount==0 to trigger the clock sync load,
which only works because the manifest happens to be null whenever
we need a new clock sync. We can decouple these concepts by directly
checking whether we have an existing elapsedRealtimeOffsetMs.

This also requires to set this value explicitly at the point where we
consider it set to the local device clock fallback when the timing
element load fails.

PiperOrigin-RevId: 634844921

This is a fix for the fix in 319854d. The original fix did
not reset the firstPeriodId to avoid any id clashes with future
updates. This however only works under the assumption that the
next manifest load at the next call to prepare() is exactly the
same as the current manifest. This is not true unless the call
happens very quickly (and may fail even then). Instead we should
keep the existing manifest directly as a reference so we can use
it to find the number of removed periods when we get a new manifest
at the next call to prepare().

Issue: #1329
PiperOrigin-RevId: 634853524

Queue image again after position reset, and reset timestamp iterator.

PiperOrigin-RevId: 635049953

…ameter

This class is a lower-level UI component that isn't directly needed if
apps are using `PlayerView` to handle their video output (it is used as
an implementation detail of `PlayerView`).

Removing its unecessary usages from this demo avoids developers copying
this as an example when building their own apps.

#cherrypick

PiperOrigin-RevId: 644972454
(cherry picked from commit cb8f87e)

Previously we assumed that `surfaceSyncGroupV34` was always non-null on
API 34, but this isn't true in edit mode. Instead we add an explicit
null-check before accessing it. We don't need to null-check it at the
other usage site because we are already null-checking `surfaceView` (via
`instanceof` check).

Issue: #1237

#cherrypick

PiperOrigin-RevId: 645008049
(cherry picked from commit 9980306)

HttpEngineDataSource is the recommended HttpDataSource when it is available. It uses the [HttpEngine](https://developer.android.com/reference/android/net/http/HttpEngine).

#cherrypick

PiperOrigin-RevId: 646051562
(cherry picked from commit e591c37)

The test is flaky because the decoding process in the renderer
depends on some timing from MediaCodec beyond our control and
the new keyframe added in the test is sometimes 'dropped' when
it arrives too late.

We can fix this by controlling the test progress a bit more
tightly: first rendering with the same current time until the
key frame is processed and then start increasing the time
until we've reached the end.

#cherrypick

PiperOrigin-RevId: 646064352
(cherry picked from commit ada4dc9)

HttpEngine does not support cookie storage.

#cherrypick

PiperOrigin-RevId: 646084702
(cherry picked from commit bb568b5)

The two arrays need to have the same length and the selection
must match in their nullness (unless for TYPE_NONE
renderers). Clarify this more clearly in the docs and add
new asssertions for it. This avoids that the player is failing
in obscure ways much later.

Issue: #1473
#cherrypick
PiperOrigin-RevId: 646086833
(cherry picked from commit 71ef848)

PiperOrigin-RevId: 646121082
(cherry picked from commit b026271)

PiperOrigin-RevId: 646402268
(cherry picked from commit 0466728)

Extractors should not report additional tracks once they called
ExtractorOutput.endTracks. This causes thread safety issues in
ProgressiveMediaPeriod where the array of sample queues is
extended while the playback thread accesses the arrays.

Detecting this problem early is beneficial to avoid unexplained
exceptions later one. In most cases where this may happen (namely
TS extractors finding new tracks), it's better to ignore the new
tracks instead of failing completely. So this change adds a
warning log message and assigns a placeholder output.

Note: The same workaround already exists in HlsSampleStreamWrapper
and MediaExtractorCompat.

Issue: #1476
#cherrypick
PiperOrigin-RevId: 646427213
(cherry picked from commit 18e631f)

#cherrypick

PiperOrigin-RevId: 646434450
(cherry picked from commit 867410f)

ExoPlayer used to call `stop()` before `release()`. This was removed in
<unknown commit>.

A framework bug introduced in Android 11 (API 30) resulted in some
DRM -> clear transitions failing during `MediaCodec.configure()`. An
investigation in Issue: google/ExoPlayer#8696 and b/191966399 identified that this was
due to `release()` returning 'too early' and the subsequent
`configure()` call was then trying to re-use a `Surface` that hadn't
been fully detached from the previous codec. This was fixed in
Android 13 (API 33) with http://r.android.com/2094347.

ExoPlayer worked around the framework bug by adding an arbitrary 50ms
sleep after a failed codec initialization, followed by retrying. This
was enough to resolve the problem in the test scenario on a OnePlus
AC2003.

Issue: #1497 points out that 50ms might not be the appropriate delay
for all devices, so it's an incomplete fix. They suggested re-adding the
`MediaCodec.stop()` call instead. This also reliably resolves the issue
on the OnePlus AC2003 (with neither workaround in place, the problem
repros almost immediately).
PiperOrigin-RevId: 646461943

(cherry picked from commit 5fcc743)

Setting a `null` value doesn't remove the key as expected per the `MediaFormat` API documentation, using the `removeKey` method instead which is only available starting API level 29.

PiperOrigin-RevId: 646462402
(cherry picked from commit 12c4258)

PiperOrigin-RevId: 646917527
(cherry picked from commit 6244d86)

When handling a playback error that originates from a future item in
the playlist, we added support for jumping to that item first,
ensuring the errors 'happen' for the right 'current item'.
See 79b688e.

However, when we add this new position discontinuity to the
playback state, there may already be other position discontinuities
pending from other parts of the code that executed before the
error. As we can't control that in this case (because it's part
of a generic try/catch block), we need to send any pending
updates first before handling the new change.

Issue: #1483
PiperOrigin-RevId: 646968309
(cherry picked from commit 7276451)

Upon track transition of offloaded playback of gapless tracks, the framework will reset the audiotrack frame position. The `AudioTrackPositionTracker`'s `AudioTimestampPoller` must be made to expect the reset and cache accumulated sum of `AudioTimestamp.framePosition`.

#cherrypick

PiperOrigin-RevId: 647294360
(cherry picked from commit a58e77a)

PiperOrigin-RevId: 648282532
(cherry picked from commit 16ef63c)

#cherrypick

PiperOrigin-RevId: 648385733
(cherry picked from commit 6bf2461)

This change extends the error replication to a given set of
error codes (not only authentication error), but only
replicates an error if the caller of the service `Callback`
is a legacy controller. It also makes error replication
configurable so that apps can opt-out and report errors
manually instead, or define the error codes for which
replication is enabled.

The change also removes the restriction of `sendError` only
being available for Media3 controllers. Instead, sending an
error to a legacy controller updates the platform playback
state in the same way as sending the error to the media
notification controller.

#cherrypick

PiperOrigin-RevId: 648399237
(cherry picked from commit 70c0639)

Issue: #1516

#cherrypick

PiperOrigin-RevId: 648416119
(cherry picked from commit 711d18d)

#cherrypick

PiperOrigin-RevId: 648641357
(cherry picked from commit 0510370)

Lint somehow complains that the integer resulting from the bit-manipulation shouldn't be passed as an @IntDef parameter.

#cherrypick

PiperOrigin-RevId: 648687698
(cherry picked from commit afe3826)

PiperOrigin-RevId: 648745388
(cherry picked from commit 9277a34)

#cherrypick

PiperOrigin-RevId: 648982615
(cherry picked from commit b531d93)

#cherrypick

PiperOrigin-RevId: 653261278
(cherry picked from commit 68e8d9c)

#cherrypick

PiperOrigin-RevId: 653640574
(cherry picked from commit 1cbcd20)

PiperOrigin-RevId: 653654999
(cherry picked from commit 3c9332b)

#cherrypick

PiperOrigin-RevId: 655558346
(cherry picked from commit d70ff7e)