SDK / exoplayer

androidTest of core already has the dependency on its main. Without this
exclude, gradle complains about type duplication when merging dex saying
"Type X is defined multiple times".

PiperOrigin-RevId: 302641585

If the start time of the edit falls within a sample, start from that
sample rather than the next one. This ensures playback can start from
the correct point if the sample is a keyframe, rather than having to
start from the next one.

Issue: #7133
PiperOrigin-RevId: 302639115

PiperOrigin-RevId: 302619179

PiperOrigin-RevId: 302474924

Add a test for this case, and extend the existing tests to ensure the
hour is parsed when it's present.

issue:#7122
PiperOrigin-RevId: 302472213

PiperOrigin-RevId: 302446077

- Show renderers with no tracks in EventLogger track logging
- Log renderer names in EventLogger track logging
- Add useful message to ExoPlaybackException instances (including
  renderer name for renderer errors)

PiperOrigin-RevId: 302421616

Remove add/removeEventListener methods & associated listener plumbing.

Part of issue:#6765

PiperOrigin-RevId: 302411347

#exo-offload

PiperOrigin-RevId: 302403507

If MaskingMediaSource masks a multi-window media source, it may be that a period
is removed while we are using an initial unprepared masking MediaPeriod. That
means it's not guaranteed that a timeline update still contains our
unpreparedMaskingMediaPeriod and we should ignore timeline updates where the
period is no longer present because the it will be removed anyway.

PiperOrigin-RevId: 302383787

PiperOrigin-RevId: 302345647

Gradle produces build warnings without this dependency.

PiperOrigin-RevId: 302045675

- Make sure logging of UnknownHostException indicates the failure reason
- Indent stack traces inside event blocks in EventLogger
- Don't log media URLs

PiperOrigin-RevId: 302007601

These methods document themselves only by referencing the Android's
MediaDrm, which explicitly accepts null [1]. The implementation in
FrameworkMediaDrm also handles nulls.

[1] https://developer.android.com/reference/android/media/MediaDrm#setOnEventListener(android.media.MediaDrm.OnEventListener)

PiperOrigin-RevId: 302007441

PiperOrigin-RevId: 301996778

PiperOrigin-RevId: 301798563

This was missed in https://github.com/google/ExoPlayer/commit/f08eed4145613527c0a4907e035ba483db6df253

Part of issue:#6765

PiperOrigin-RevId: 301796232

Also add a couple of tests to enforce the documentation.

PiperOrigin-RevId: 301796102

Issue: #2159
PiperOrigin-RevId: 301705371

- This change also adds support for VideoFrameMetadataListener in the
  AV1 renderer
- This is a preliminary step prior to adding FfmpegVideoDecoder

Issue: #2159
PiperOrigin-RevId: 301702460

This is a necessary step for Decoder implementations to support
audio and video. MediaCodecRenderer.DecoderException is renamed
MediaCodecDecoderException and extends the new DecoderException

Issue: #2159
PiperOrigin-RevId: 301698238

We have two known scenarios where the app could create an OOM error and
we want to handle it gracefully:
 1. The app continues to allocate memory but doesn't make any progress
    in the buffered position. OOM should be prevented by the default
    load control and it should eventually throw an exception.
 2. An extractor tries to allocate a large amount of memory on the
    Loader thread based on information it read in faulty media files.
    In this case we should attempt to play remaining media and then
    throw an exception.

Both cases are already handled correctly, but we don't have any tests
ensuring that we don't introduce regressions.

PiperOrigin-RevId: 301585700

This removes a workaround that always continues buffering and instead
detects if the LoadControl returns false even though we don't have
any buffer. If enabled by a flag, this condition throws an exception.

PiperOrigin-RevId: 301584239

This allows to customize the DrmSessionManager, e.g. with a
LoadErrorHandlingPolicy.

Issue:issue:#7078
PiperOrigin-RevId: 301571783

Issue: #7097
PiperOrigin-RevId: 301456951

The restriction that these classes only work with SimpleDecoders
is unnecessary. An FfmpegVideoRenderer will not be able to use a
SimpleDecoder, because the SimpleDecoder assumption that each input
buffer can be decoded immediately into a corresponding output is
not true for all video codecs that Ffmpeg supports (e.g., H264 does
not have this property). Generalizing SimpleDecoderVideoRenderer to
DecoderVideoRenderer will allow FfmpegVideoRenderer to still use
the base class, without having to use a SimpleDecoder.

This is a preliminary change toward being able to merge a version
of https://github.com/google/ExoPlayer/pull/7079.

Issue: #2159
PiperOrigin-RevId: 301412344

PiperOrigin-RevId: 301406108

PiperOrigin-RevId: 301397420

The test is flkay (2/1000 runs) because the decoder initialization
before and after the seek are not perfectly deterministic. I couldn't
find a way to make them deterministic, so slightly chaning the test
setup instead. The test setup change doesn't affect the scenario being
tested.

PiperOrigin-RevId: 301390491

When no tracks are selected (or only tracks of unknown type), the
target buffer size is calculated to be 0. This means the player
won't request to buffer more data, nor can it start playback and
will be stuck forever.

PiperOrigin-RevId: 301374229

The FakeSampleStream is currently always ready even if it doesn't
have any samples to read. Fix that by checking for the conditions
under which read() will be successful.

PiperOrigin-RevId: 301371031

The assertion about the expected formats doesn't really belong in a
fake, the assertions should be closer to the test method.

This gets in the way when I try and write a new test in
AnalyticsCollectorTest that doesn't use the expected, constant Format
(because i want to specify drmInitData) - but changing the expected
Format is tricky because it's hard-coded into the FakeVideoRenderer
inner class.

I replaced the assertion in FakeRenderer with assertions in test
methods that used to assert on the format count.

PiperOrigin-RevId: 301353072

Follow-up to https://github.com/google/ExoPlayer/commit/42b8fe2681758b60f2d1e6df79d0727ce4a953d4

PiperOrigin-RevId: 301352557

PiperOrigin-RevId: 301352482

Issue: #2159
PiperOrigin-RevId: 301351495

Issue: #2159
PiperOrigin-RevId: 301345559

PiperOrigin-RevId: 301336818

PiperOrigin-RevId: 301224632

Previously calling removeListener would remove all instances of that
listener. Now it only removes a single instance.

This probably should have been part of introducing the Multiset:
https://github.com/google/ExoPlayer/commit/2bd4d61b9b8c838fb7dc81e7d6f513c4a4e00c76

PiperOrigin-RevId: 301191940

PiperOrigin-RevId: 301187369