SDK / exoplayer

PiperOrigin-RevId: 247630389

Issue:#5821
PiperOrigin-RevId: 247621164

Issue:#5868
PiperOrigin-RevId: 247613811

PiperOrigin-RevId: 247418601

If a PlayerMessage throws an exception, it is currently not deleted from the
list of pending messages. This may be problematic as the list of pending
messages is kept when the player is retried without reset and the message is
sent again in such a case.

PiperOrigin-RevId: 247414494

PiperOrigin-RevId: 247348352

Adding an explicit option to clear all downloads prevents repeated database
access in a loop when trying to delete all downloads.

However, we still create an arbitrary number of parallel Task threads for this
and seperate callbacks for each download.

PiperOrigin-RevId: 247234181

PiperOrigin-RevId: 245243488

PiperOrigin-RevId: 246733842

PiperOrigin-RevId: 246733842

PiperOrigin-RevId: 246729123

PiperOrigin-RevId: 246727723

PiperOrigin-RevId: 246729123

PiperOrigin-RevId: 246728418

PiperOrigin-RevId: 246727723

PiperOrigin-RevId: 246491511

PiperOrigin-RevId: 246333281

PiperOrigin-RevId: 246491511

PiperOrigin-RevId: 246333281

NOTE: Streams are working on ExoPlayer but querying them from
other platforms yields "bad request".

The new links:
+ Match Microsoft's test server.
+ Allow querying from clients other than ExoPlayer, like curl.

PiperOrigin-RevId: 246289755

Post-submit fixes for https://github.com/google/ExoPlayer/commit/eed5d957d87d44cb9c716f1a4c80f39ad2a6a442.

One wrong return value, a useless assignment, unusual visibility of private
class fields and some nullability issues.

PiperOrigin-RevId: 246282995

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

NOTE: Streams are working on ExoPlayer but querying them from
other platforms yields "bad request".

The new links:
+ Match Microsoft's test server.
+ Allow querying from clients other than ExoPlayer, like curl.

PiperOrigin-RevId: 246289755

Post-submit fixes for https://github.com/google/ExoPlayer/commit/eed5d957d87d44cb9c716f1a4c80f39ad2a6a442.

One wrong return value, a useless assignment, unusual visibility of private
class fields and some nullability issues.

PiperOrigin-RevId: 246282995

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

PiperOrigin-RevId: 246132620

They behave identically, and the old names are being removed.

Open-source note: The new methods are available in Truth as of version 0.44.

END_PUBLIC

More information:
  go/issameas-lsc

Tested:
    TAP --sample ran all affected tests and none failed
    http://test/OCL:246024032:BASE:246042619:1556672975894:513e7746
PiperOrigin-RevId: 246101315

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