SDK / exoplayer

As justification for why we should not have this type of logging,
it would scale up to about 13K LOC, 1800 Strings, and 36K (after
pro-guarding - in the case of the demo app) if we did it through
the whole code base*. It makes the code messier to read, and in
most cases doesn't add significant value.

Note: I left the Scheduler logging because it logs interactions
with some awkward library components outside of ExoPlayer, so is
perhaps a bit more justified.

* This is a bit unfair since realistically we wouldn't ever add
  lots of logging into trivial classes. But I think it is fair
  to say that the deltas would be non-negligible.

PiperOrigin-RevId: 246181421

PiperOrigin-RevId: 246173972

- Removed DownloadInternal and its sometimes-out-of-sync
  duplicate state
- Fixed downloads being in STOPPED rather than QUEUED state
  when the manager is paused
- Fixed setMaxParallelDownloads to start/stop downloads if
  necessary when the value changes
- Fixed isWaitingForRequirements

PiperOrigin-RevId: 246164845

Can happen if the load position falls behind in every playlist and
when we try to load the next segment, the adaptive selection logic
decides to change variant.

Issue:#5816
PiperOrigin-RevId: 245923006

- Do requirements TODO
- Add useful helper method to retrieve not met requirements
- Fix WritableDownloadIndex Javadoc

PiperOrigin-RevId: 245922903

This resolves some naming confusion that previously existed
as a result of DownloadThread also being used for removals.
Some related variables (e.g. activeDownloadCount) would refer
to both download and removal tasks, whilst others
(e.g. maxParallelDownloads) would refer only to downloads.
This change renames those that refer to both to use "task"
terminology.

This change also includes minor test edits.

PiperOrigin-RevId: 245913671

Issue: #5810
PiperOrigin-RevId: 245745646

PiperOrigin-RevId: 245397736

PiperOrigin-RevId: 245443109

Experiments show this is beneficial for rebuffers with only minor impact
on battery usage.

Configurations which explicitly set a minimum buffer duration are unaffected.

Issue:#2083
PiperOrigin-RevId: 244823642

Issue: #5788
PiperOrigin-RevId: 245440858

PiperOrigin-RevId: 245411528

There are no logic changes here. It's just moving code around and removing
the "internal" part of names where no longer required.

PiperOrigin-RevId: 245407238

PiperOrigin-RevId: 245405316

PiperOrigin-RevId: 245401274

PiperOrigin-RevId: 245397736

PiperOrigin-RevId: 245388082

PiperOrigin-RevId: 245218900

This also removes the build warning about the experimental flag.

PiperOrigin-RevId: 245218251

PiperOrigin-RevId: 245014381

PiperOrigin-RevId: 244864742

Disabling stack trackes currently logs messages twice, once with and once
without stack trace.

PiperOrigin-RevId: 244853127

This ensures we keep the loading period in sync with the the playing period in
PlybackInfo, when the latter changes to something new.

PiperOrigin-RevId: 244838123

- We had buildAddRequest and sendNewDownload. Converged to
  buildAddDownload and sendAddDownload.
- Also fixed a few more inconsistencies, and brought the
  action constants into line as well.

PiperOrigin-RevId: 244274041

PiperOrigin-RevId: 244268855

PiperOrigin-RevId: 244267255

- Listener based reporting of progress allows the content length
  to be persisted into the download index (and notified via a
  download state change) as soon as it's available.
- Moved contentLength back into Download proper. It should only
  ever change once, so I'm not sure it belongs in the mutable part
  of Download.
- Made a DownloadProgress class, for naming sanity.

PiperOrigin-RevId: 244242487

PiperOrigin-RevId: 244226680

PiperOrigin-RevId: 244223870

PiperOrigin-RevId: 244216620

PiperOrigin-RevId: 244210737

PiperOrigin-RevId: 244196081

Assuming there is no text language preference.

PiperOrigin-RevId: 244176667

PiperOrigin-RevId: 244170179