SDK / exoplayer

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

PiperOrigin-RevId: 243821394

We currently do manual position tracking while the player is in error mode.
This is to allow an initial seek to the new position when trying to re-prepare.

Instead, we can just use our player.retry method and remove the tracking code.

PiperOrigin-RevId: 243819580

The removed condition only applies when prepare fails and no timeline was or
is known. We should keep a pending seek position in such a case. The internal
player does the same thing already.

PiperOrigin-RevId: 243819466

Issue: #5767
PiperOrigin-RevId: 243811443

PiperOrigin-RevId: 243807109

PiperOrigin-RevId: 243806888

PiperOrigin-RevId: 243799572

PiperOrigin-RevId: 243781000

- It can work with any DownloadIndex
- Also simplify things to not require that it's registered
  as a DownloadManager listener by someone else

PiperOrigin-RevId: 243697352

- Expose constructors that take DatabaseProvider. Deprecate those
  that do not.
- Expose Cache.getUid. This will likely be used for naming of the
  tables accessed by DefaultDownloadIndex .

PiperOrigin-RevId: 243637786

PiperOrigin-RevId: 243636923

PiperOrigin-RevId: 243632134

- Allows enforcing immutability, which in a future CL will allow
  avoiding allocating a new array/list on every call.
- Also some left over doc cleanup from the DownloadState rename.

PiperOrigin-RevId: 243627352

PiperOrigin-RevId: 243624081

PiperOrigin-RevId: 243618907

ISSUE: #4563
PiperOrigin-RevId: 243616444

PiperOrigin-RevId: 243592790

The old domain automatically forwards to the new one. For consistency, change
all doc and code references regardless.

Also adds GitHub CNAME config file which configures our page for the custom
domain.

PiperOrigin-RevId: 243592110

handleSourceInfoRefreshed checks for various conditions which may trigger a
change in position. In all cases, we need to resolve the new position for ads,
and if the corresponding MediaPeriods already exist, perform the seek to the new
position.

This change simplified the code by
 1. Moving all conditions in a single if-else structure which just determines
    the new playback position. This makes it easier to read and to follow.
 2. Doing the subsequent seek and position update in one final step to remove
    duplicated code.

As a side effect, it also improves some edge cases. For example when skipping
an ad to an already prebuffered period, we now properly update the existing
prebuffered period.

PiperOrigin-RevId: 243588014

PiperOrigin-RevId: 243582468

- Make a best effort to avoid posting MSG_DOWNLOAD_THREAD_STOPPED
  if the internal thread has already quit. Doing so is harmless,
  but causes an error in Logcat. We used to generate this warning
  quite a bit in ExoPlayerImplInternal as well, and we got quite
  a few issues filed about it, so best to avoid it if possible.
- Null out the back reference DownloadThread holds to its manager
  on release. This avoids a potential issue where a download thread
  can prevent GC of its manager if it doesn't cancel quickly.
  There's similar logic (with a similar comment) in Loader.LoadTask.

PiperOrigin-RevId: 243365143

PiperOrigin-RevId: 243304549

- Rename getAllDownloads to getCurrentDownloads to make it clear
  that it doesn't include completed and failed downloads
- Change getDownloadCount to isWaitingForRequirements, which is
  what it's used for. Added TODO to make it returns the right thing

PiperOrigin-RevId: 243257856

If the returned retry delay is unset, we should use a DONT_RETRY_FATAL action
instead and dispatch the event with the "canceled" flag.

PiperOrigin-RevId: 243251554

Non-trivial download state transitions are currently split across
DownloadManager and Download. These transitions are part of the
same state machine, so it's clearer if they're all in the same place
(i.e. DownloadManager, since this is the component that transitions
downloads between states).

PiperOrigin-RevId: 243249915

The only state DownloadInternal holds is duplicate of state contained
in Download, but can confusingly be temporarily out of sync. This is
error prone because it's easy to use the wrong variable (e.g.
download.state vs state). DownloadInternals methods are called into
and call out into DownloadManager, which makes some code paths that
are quite hard to follow.

It's possible to simplify DownloadManager quite a lot by removing the
duplicated state in DownloadInternal, at which point DownloadInternal's
methods flatten into DownloadManager, which can just hold an internal
list of Downloads directly.

This is a first step, which makes it clear that DownloadThready only
needs its immutable DownloadAction + an isRemove flag.

PiperOrigin-RevId: 243245288

PiperOrigin-RevId: 243243975