SDK / exoplayer

PiperOrigin-RevId: 343467276

The demo app has two states for downloads, as per DownloadTracker.isDownloaded.
It's either "downloaded or downloading" (isDownloaded returns true, and the UI
shows a blue tick) or it's "not downloaded or failed (isDownloaded returns
false, and the UI does not show a blue tick).

toggleDownload is out of sync in that it treates "failed" as belonging to the
first state rather than the second. This means tapping on the grey tick in the
UI in this case appears to be a no-op (tapping it again will make something
happen).

This change aligns things by making toggleDownload re-download in the case a
previous download failed. In the future we could consider having three states,
so failed downloads could be disambiguated properly. Unclear whether it's a
good complexity/benefit trade-off for the demo app though!

#minor-release

PiperOrigin-RevId: 343464364

When a stream has duplicate timestamps we currently discard to
the last sample with the specified discardTo timestamp, but
it should be the first one to adhere to the method doc and the
intended usage.

#minor-release

PiperOrigin-RevId: 343458870

PiperOrigin-RevId: 343438203

PiperOrigin-RevId: 343437513

PiperOrigin-RevId: 343432873

Background:

1. When the player has multiple audio renderers, by default they share a
   single AudioSink.
2. When any new renderer is enabled, all disabled renderers are reset
   prior to the new renderer being enabled. This is to give them a chance
   to free up resources in case the renderer being enabled needs them. These
   reset calls are expected to be no-ops for renderers that have never been
   enabled.

The issue:

The problematic case arises when there are two audio renderers and a third
renderer (e.g., text) is being enabled. In this case, the disabled audio
renderer's reset call ends up resetting the AudioSink that's shared with the
enabled audio renderer. The enabled audio renderer is then unable to make
progress, causing playback to freeze.

This is a minimal fix that directly prevents the mentioned issue. There are
multiple follow-ups that would probably make sense:

1. Having ExoPlayerImplInternal track which renderers need to be reset, and
   only resetting those renderers rather than all that are disabled. This
   seems like a good thing to do regardless, rather than relying on those
   calls being no-ops.
2. If we want to continue sharing AudioSink, we need to formalize this much
   better and make sure we have good test coverage. Messages like
   MSG_SET_VOLUME are also delivered to the AudioSink multiple times via
   each of the renderers, which works currently because DefaultAudioSink
   no-ops all but the first call in each case. This is pretty fragile though!

Issue: #8203
#minor-release
PiperOrigin-RevId: 343296081

Issue: #5011
PiperOrigin-RevId: 343277357

This isn't used any more, the last usage was removed in
<unknown commit>

PiperOrigin-RevId: 343266553

This is inline with other show-toast-on-error cases in this method, and avoids
leaving the user on a completely black screen.

Note that the maybeRequestReadExternalStoragePermission is an exception because
it's not actually an error case.

#minor-release

PiperOrigin-RevId: 343264869

Real apps probably aren't going to be allowing playback speed to be
set to anything other than the options listed in their UI, and so
this is not worth the complexity.

It also violates the idea that the UI should look the same regardless
of when the player is set on the view, since if it's set and then the
playback speed is changed to a listed option then the custom speed
remains, where-as if the speed is changed to a listed option and then
it's set, the custom speed will not be shown.

PiperOrigin-RevId: 343260450

PiperOrigin-RevId: 343253445

*** Original commit ***

Suppress warnings in preparation for Checker Framework 3.7.1 upgrade.

LSC: go/checker-lsc

Tested:
    tap_presubmit: http://test/OCL:342788975:BASE:342885903:1605667635149:7731b723
    Some tests failed; test failures are believed to be unrelated to this CL

***

PiperOrigin-RevId: 343251530

#minor-release
Issue: #7898
PiperOrigin-RevId: 343251455

LSC: go/checker-lsc

Tested:
    tap_presubmit: http://test/OCL:342788975:BASE:342885903:1605667635149:7731b723
    Some tests failed; test failures are believed to be unrelated to this CL
PiperOrigin-RevId: 343129490

*** Original commit ***

Keep download in completed state if only metadata is updated

Issue: #8116

***

PiperOrigin-RevId: 343102068

*** Original commit ***

Suppress warnings in preparation for Checker Framework 3.7.1 upgrade.

***

PiperOrigin-RevId: 343100646

PiperOrigin-RevId: 343096974

*** Original commit ***

Suppress warnings in preparation for Checker Framework 3.7.1 upgrade.

***

PiperOrigin-RevId: 343086403

*** Original commit ***

Suppress warnings in preparation for Checker Framework 3.7.1 upgrade.

***

PiperOrigin-RevId: 343085407

ExoPlayer's traditional HLS preparation works by loading a chunk from each track
group, and then tries to use the sample information plus the master playlist
information to generate the preparation's resulting TrackGroups.

There are 3 possible scenarios:
- Supported case: Each variant has a single codec string per track type. We can
  assign each track the codec string which matches the loaded sample's type.
- Supported case: Each variant has more than one codec string, but each track
  group has a single track. This is the case when different languages use
  different codecs. In this case, we can assign whichever codec matches the
  loaded sample's mime type.
- Unsupported case: Each variant has more than one codec string, and track
  groups contain more than one track. We are not able to safely map tracks to
  codec strings because that would require loading a chunk from each track
  (which would considerably delay preparation).

Broken in:
https://github.com/google/ExoPlayer/commit/4783c329cc545da4269a9401a4975a41e75f2f43

PiperOrigin-RevId: 343072201

PiperOrigin-RevId: 343003559

PiperOrigin-RevId: 342999709

PiperOrigin-RevId: 342999390

Allows to set a timeout for the setForegroundMode(false) call, different than releaseTimeoutMs.

PiperOrigin-RevId: 342980350

PiperOrigin-RevId: 342952746

Right now we also notify while we are paused although this doesn't classify as a rebuffer.

PiperOrigin-RevId: 342892667

This only has a couple of simple tests for now. We'll add more tests
after we've written some concrete sub-class tests for various
DataSource implementations.

I've included a concrete FileDataSourceContractTest as a demonstration.

PiperOrigin-RevId: 342851187

Determine whether a rebuffer occurred and if the playback is paused or resumed.

PiperOrigin-RevId: 342849010

Issue:#8219
PiperOrigin-RevId: 342843964

PiperOrigin-RevId: 342672124

PiperOrigin-RevId: 342660971

Make the public loadPlaylist method not take an argument again.

PiperOrigin-RevId: 342646259

PiperOrigin-RevId: 342642410

Issue: #8090
#minor-release
PiperOrigin-RevId: 342638922

PiperOrigin-RevId: 342618706

This ensures the buffer is not full when the `DefaultLoadControl` determines
whether we should continue loading and thus prevents a false warning about
not having enough memory left.

PiperOrigin-RevId: 342616623

This should be inherited from Player#getPlaybackError, but lint still
complains and this seems like the easiest fix.

PiperOrigin-RevId: 342598368

This change also introduces gravity attribute to DefaultTimeBar.

PiperOrigin-RevId: 342573167

PiperOrigin-RevId: 342512836