SDK / exoplayer

We previously only checked whether the reason for the timeline change is
RESET which indicates an empty timeline. Change this to an explicit check
for empty timelines to also ignore empty media or intermittent timeline
changes to an empty timeline which are not marked as RESET.

Issue:#5831
PiperOrigin-RevId: 248499118

Issue: #5891
PiperOrigin-RevId: 248369509

PiperOrigin-RevId: 248367983

PiperOrigin-RevId: 248350557

PiperOrigin-RevId: 248221982

Issue: #5876
PiperOrigin-RevId: 248119726

Issue: #5862
PiperOrigin-RevId: 248112524

Issue:#5568
PiperOrigin-RevId: 247973411

Accessing task providers (like javaCompileProvider) at sync time is not
possible. That's why the source sets of all generateJavadoc tasks is empty.

The set of source directories can also be accessed directly through the static
sourceSets field. Combining these allows to statically provide the relevant
source files to the javadoc task without needing to access the run-time task
provider.

PiperOrigin-RevId: 247938176

Issue: #5876
PiperOrigin-RevId: 247935822

Issue: #5782
PiperOrigin-RevId: 247934223

The update to Gradle 5.1.1 decreased the default heap size to 512MB and our
build runs into Out-of-Memory errors.

Setting the gradle flags to higher values instead.

See https://developer.android.com/studio/releases/gradle-plugin#3-4-0

PiperOrigin-RevId: 247908526

PiperOrigin-RevId: 247902405

PiperOrigin-RevId: 247630389

Issue:#5821
PiperOrigin-RevId: 247621164

Issue:#5868
PiperOrigin-RevId: 247613811

PiperOrigin-RevId: 247499141

In preparation for reference counting in DrmSession

PiperOrigin-RevId: 247428114

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

1. A content session after an ad has been played was not re-marked as active,
   leading to new ad session being marked as active too early.
2. Switching from content to post-roll ended the content session because
   the return value of getAdGroupTimeUs of C.TIME_END_OF_SOURCE was not
   handled. Using the nextAdGroupIndex instead.

PiperOrigin-RevId: 246977327

PiperOrigin-RevId: 246733842

PiperOrigin-RevId: 246729123

PiperOrigin-RevId: 246728418

PiperOrigin-RevId: 246727723

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

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

PiperOrigin-RevId: 245956915

PiperOrigin-RevId: 245925254

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