SDK / exoplayer

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

Include information to facilitate adaptive track selection in HLS.

PiperOrigin-RevId: 243238232

PiperOrigin-RevId: 243237265

Issue: #3100
Issue: #5547
PiperOrigin-RevId: 243181217

PiperOrigin-RevId: 243085292

Put methods into a more sensible order (the same order as
in the switch statement, which is a more natural order with
e.g. initialize coming first and release coming last).

PiperOrigin-RevId: 242891742

- Changed startDownloads/stopDownloads back to their previous behavior
  of starting and stopping all downloads at the manager level.
- Made setManualStopReason methods for the new case of setting a manual
  stop reason or some or all downloads.
- Added plumbing to specify an initial manual stop reason when adding a
  new download, without also overwriting the manual stop reasons of all
  other preexisting downloads. Using the value is left as a TODO pending
  a bit of further cleanup that'll make it easier.

PiperOrigin-RevId: 242891688

- Remove completed downloads from progress notification.
- Treat restarting as a downloading, When there are both
remove and download tasks ongoing, we prefer to show a
download notification to a remove one. A restarting task
encapsulates is basically a (remove+download) task. Given
our preference, we should treat it as a download rather
than as a removal.

PiperOrigin-RevId: 242867228

Both manifest loads currently use the default retry delay although a
LoadErrorHandlingPolicy is provided to the MediaSource.

PiperOrigin-RevId: 242852672

PiperOrigin-RevId: 242851294

PiperOrigin-RevId: 242839480

We have new strings for track role types.

PiperOrigin-RevId: 242829944

- Remove NETWORK_TYPE_NOT_ROAMING and NETWORK_TYPE_METERED
  because JobScheduler doesn't support them, and they're
  probably not useful to many people (data when roaming is
  normally enabled/disabled at the OS level, and restricting
  to *only* metered networks seems niche)
- Convert network requirements proper flags
- Stop persisting requirements in DownloadIndex. The direction
  we're headed to solve the manager start/stop problem is
  going to involve state in DownloadManager determining whether
  downloads actually start, and if we're doing that then it's
  no worse to do it for this as well

PiperOrigin-RevId: 242713196

We usually avoid linking to the same page. Replacing all {@link DataSpec}
with just "data spec" accordingly.

PiperOrigin-RevId: 242689537

PiperOrigin-RevId: 242686312

Implement Parcelable instead, which is a more intented way of
passing structured data via Intents.

PiperOrigin-RevId: 242646441

Robolectric calls messages posted to the main thread immediately inline. This
will change in the upcoming release and will break tests implicitly relying
on that behavior.

Update ConcatenatingMediaSourceTest to actually wait for the posted message.

PiperOrigin-RevId: 242631531

This makes sense now that DownloadAction is only for downloading,
and not also for removal.

PiperOrigin-RevId: 242561575