SDK / exoplayer

PiperOrigin-RevId: 245014381

The two behave identically, and containsAllOf is being removed.

More information:
  go/containsall-lsc

Tested:
    TAP --sample for global presubmit queue
    http://test/OCL:244737393:BASE:244782138:1555991083653:3080d7c7
PiperOrigin-RevId: 244886736

The two behave identically, and isNotSameAs is being removed.

More information:
  go/issameas-lsc

Tested:
    TAP --sample for global presubmit queue
    http://test/OCL:244736857:BASE:244751659:1555988098671:1e0f72c5
PiperOrigin-RevId: 244886651

PiperOrigin-RevId: 244864742

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

PiperOrigin-RevId: 244853127

The AndroidX bundled version (0.42) lags behind the most up-to-date public
release (0.44) making it more difficult to stay close to the actual head
revision which is used internally.

PiperOrigin-RevId: 244848568

PiperOrigin-RevId: 244838165

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

Also re-enable two of them, although note that the fix here is
not related to the flakiness that caused them to be disabled.
I'm re-enabling them since much has changed in DownloadManager,
and the hope is that these tests are no longer flaky.

PiperOrigin-RevId: 244826225

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

PiperOrigin-RevId: 244816212

Before this change we'd release the audio track and create a new one as soon
as audio processors had drained when reconfiguring.

Fix this behavior by stop()ing the AudioTrack to play out all written data.

Issue: #2446
PiperOrigin-RevId: 244812402

- 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: 244173887

PiperOrigin-RevId: 244170391

PiperOrigin-RevId: 244170179

PiperOrigin-RevId: 244168713

PiperOrigin-RevId: 244167456

PiperOrigin-RevId: 244139959

PiperOrigin-RevId: 244094942

PiperOrigin-RevId: 244056421

1. customCacheKey for DASH/HLS/SS is now asserted against
   in DownloadRequest
2. Merging of event delivery in DownloadManager is very
   tricky to get right and probably not a good idea

PiperOrigin-RevId: 244048392

PiperOrigin-RevId: 244009343

Currently SimpleCache will touch cache spans whenever it reads
from them. With legacy SimpleCache setups this involves a potentially
expensive file rename. With new SimpleCache setups it involves
a more efficient but still non-free database write.

For offline use cases, and more generally any use case where the
eviction policy doesn't use last access timestamps, touching is
not useful. This change allows the evictor to specify whether it
needs cache spans to be touched or not. SimpleCache will only touch
spans if the evictor requires it.

Note: There is a potential change in behavior in cases where a
cache uses an evictor that doesn't need cache spans to be touched,
but then later switches to an evictor that does. The new evictor
may temporarily make sub-optimal eviction decisions as a result.
I think this is a very fair trade-off, since this scenario is
unlikely to occur much, if at all, in practice, and even if it
does occur the result isn't that bad.
PiperOrigin-RevId: 244005682

PiperOrigin-RevId: 244003817

PiperOrigin-RevId: 243988105

Issue: #5772
PiperOrigin-RevId: 243987497

One goal we forgot about a little bit was to allow applications
to provide their own index implementation. This requires the
writable side to also be defined by an interface.

PiperOrigin-RevId: 243979660

ImaAdsLoader gets the player position after the app releases
the player to support resuming ads at their current position
if the same ads loader is reused.

PiperOrigin-RevId: 243969916

PiperOrigin-RevId: 243954989

ShadowLooper -> ShadowLegacyLooper
ShadowRealisticLooper -> ShadowPausedLooper
ShadowBaseLooper -> ShadowLooper

And all public methods from ShadowLegacyLooper get pushed up to ShadowLooper

Pull Request: https://github.com/robolectric/robolectric/pull/4868

Copybara: OK

Also adjust Google3 tests  using custom looper shadows where necessary.
Convert exoplayer to paused looper to eliminate reliance on custom shadows

PiperOrigin-RevId: 243839311