SDK / exoplayer

PiperOrigin-RevId: 333051018

We have a workaround for uneven sample stream durarions in playlists that
assumes a renderer allows playback if it's reading ahead or waiting for
the next stream.

https://github.com/google/ExoPlayer/commit/652c2f9c188bf9d9d6e323ff5333e5026454a082 changed this logic to no longer require to
wait until the next stream is prepared due to a change in how we advance
media periods in the queue. However, the code falsely still requires the
next stream to exist (even if it's not prepared). This can cause a stuck
buffering state when the difference in the duration of the streams is more
than what we buffer ahead because we never create the next stream in such
a case.

Note: DefaultMediaClock.shouldUseStandaloneClock has roughly the same logic
and also doesn't require the next stream to be present.

Also fix a test that seemed to rely on this stuck buffering case to test
stuck buffering detection. Changed the test to not read the end of stream
to ensure it runs into the desired stuck buffering case.

Issue:#7943
PiperOrigin-RevId: 333050285

PiperOrigin-RevId: 333031399

PiperOrigin-RevId: 333031301

PiperOrigin-RevId: 333029935

PiperOrigin-RevId: 333023580

We're not using regex so there's no need to use replaceAll()

PiperOrigin-RevId: 332865724

Without this patch, playback would be frozen indefinitely
until the user manually pauses and unpauses it.

This has the side effect of disabling offload until
the next stop due to the workaround of
disabling offload when it encounters a failure.

As an audio server crash is considered very
infrequent, especially in stable conditions like
an audio only playback, it is unlikely that disabling
offload is an issue.

PiperOrigin-RevId: 332857094

PiperOrigin-RevId: 332814223

PiperOrigin-RevId: 332254072

I didn't copy-paste the whole of
https://github.com/google/guava/wiki/UsingProGuardWithGuava because
this line seems relevant based on our current usage.

Lots of that file seems to relate to classes that are strongly
discouraged on Android:
https://github.com/google/guava/wiki/Android#specifics

I've only added this to the `common` module, since everyone that uses
ExoPlayer must depend on that. This avoids duplicating this line into
every module that has a Guava dependency.

Also remove some other warning suppressions that are defined in both
`core` and `common`.

Issue: #7904
PiperOrigin-RevId: 332203086

PiperOrigin-RevId: 332014290

Issue: #7866
PiperOrigin-RevId: 330736774

PiperOrigin-RevId: 331591005

PiperOrigin-RevId: 332940209

Issue: #7939
PiperOrigin-RevId: 332838586

PiperOrigin-RevId: 332015471

PiperOrigin-RevId: 332012857

Since gradle 4.0, CMake imported libraries are bundled in the APK, so
manually bundling them causes a duplication which breaks the build.

Issue: #7906
PiperOrigin-RevId: 332012375

PiperOrigin-RevId: 331955966

Issue: #7906
PiperOrigin-RevId: 331775990

Issue: #7902
PiperOrigin-RevId: 331771187

This test is intended to check that DefaultLoadControl will cause
playback to fail as "stuck buffering" rather than OOM-ing, in the
case that its target buffer size is reached and playback still
hasn't started.

Unfortunately, the target buffer size is ~130MB, and when running
on some setups an OOM actually ends up happening before this much
memory is allocated.

This change makes the target buffer size much smaller to avoid the
problem.

PiperOrigin-RevId: 331748208

PiperOrigin-RevId: 331539036

PiperOrigin-RevId: 331354102

r2.12.0

There's no option to enable them. This is probably a copy/paste error
from DefaultHttpDataSourceFactory.

PiperOrigin-RevId: 331334263

PiperOrigin-RevId: 331211708

PiperOrigin-RevId: 331162350

PiperOrigin-RevId: 331155539

Issue: #7889
PiperOrigin-RevId: 331149688

PiperOrigin-RevId: 331148067

Setting to 2x BATCH_SIZE_BYTES

PiperOrigin-RevId: 331124129

Throwing Error forces a test to catch Throwable (e.g.
DashWidevineOfflineTest#widevineOfflineReleasedV22), which will also
catch AssertionError meaning the fail() call at the end of the try block
won't work.

The DashWidevineOfflineTest have been broken since
https://github.com/google/ExoPlayer/commit/91185500a1242b99b86b18bc9f3449d3dac1fa01

PiperOrigin-RevId: 331120894

PiperOrigin-RevId: 331027732

PiperOrigin-RevId: 331025924

This may remove available memory from other tests running in the same
process. Instead, create the huge buffer when needed so it can be GCed
immediately.

PiperOrigin-RevId: 330960844

Not releasing the player means the playback thread keeps running
and also keeps its entire allocated playback buffer.

PiperOrigin-RevId: 330958821