SDK / exoplayer

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

By passing false, users can disable the preemptive 608 track.

Issue:#5736
PiperOrigin-RevId: 242476274

PiperOrigin-RevId: 242465135

PiperOrigin-RevId: 242460786

HashMap.values does not guarantee a stable order, but our tests
assert that the order is stable. It's probably a nice property
that the order is the same as that in which downloads are added,
so this change makes the order stable, with that order.

A future change will likely improve the way this works, by
changing the internal thread "downloads" variable to have type
ArrayList<Download>, at which point the internal thread can just
pass a read-only copy of its list to the main thread whenever a
state changes.

PiperOrigin-RevId: 242460725

ISSUE: #5734
PiperOrigin-RevId: 242459668

- Fix ID being dropped when DownloadAction is serialized and
  de-serialized as it's passed to DownloadService
- Properly set DownloadAction.id when building an action from
  a DownloadState
- Make ID a required constructor argument. Else it's too easy
  to not propagate it by accident.

PiperOrigin-RevId: 242457831

Remove MediaCodecSelector.DEFAULT_WITH_FALLBACK, as codec selectors
will need to be able to return a list of decoder infos even when not
using fallback in a later change. Instead signal that fallback should
be used via a renderer constructor.

Fallback is always disabled for audio.

PiperOrigin-RevId: 242454172

Issue: #5616
PiperOrigin-RevId: 242452686

PiperOrigin-RevId: 242449883

Adding a protected method for that allows to supply a customized
TrackOutputProvider to the ExtractorWrapper used by the ContainerMediaChunk
(e.g. for logging purposes).

The alternative would be to provide a  TrackOutputProvider through the
ChunkSampleStream constructor, but the extra initialization taking place
in the ChunkSampleStream constructor would need to move somewhere else and
some methods of BaseMediaChunkOutput would need to move to the
TrackOutputProvider interface. This seems too much effort for niche
customization case.

PiperOrigin-RevId: 242448776

The position should be subtracted from the total content length
retrieved from the cache in this case, both for iteration and for
filling out counters.contentLength (for the latter, note not
doing it this way is inconsistent with what happens when dataSpec
length is set to a known value).

PiperOrigin-RevId: 242445034

It's a transient state whose only use is when passing a removed
download to onDownloadStateChanged. It's a bit strange to have it
as a proper state, since we end up asserting that it's an invalid
value in other places.

This change adds an explicit onDownloadRemoved, which allows
removal of the transient STATE_REMOVED, related assertions, and
uncertainty when dealing with an @State variable whether it's
necessary to handle it being STATE_REMOVED.

PiperOrigin-RevId: 242444128

PiperOrigin-RevId: 242439330

This is the last cl of a series of cls that will convert DownloadManager
threading model as public methods post actions on an internal thread
which then do the work.

PiperOrigin-RevId: 242437229

This is part of the public API and the underscored versions
weren't intended to be used outside the library.

Also updating the external instructions to checkout the version
of libvpx that supports this macro for this particular constant.

#codehealth

PiperOrigin-RevId: 242170926

Broken in https://github.com/google/ExoPlayer/commit/399aa706a7e570e8ed7ca93b54beaae6ee3dac91

PiperOrigin-RevId: 242112068

The priority task manager only needs to listen to loading state changes and
is independent of the rest of DefaultLoadControl. This also fixes problems
where the player stops loading without consultin the LoadControl.

PiperOrigin-RevId: 242098374

PiperOrigin-RevId: 242094027

PiperOrigin-RevId: 241811732

This is the second cl of a series of cls that will convert DownloadManager
threading model as public methods post actions on an internal thread
which then do the work.

PiperOrigin-RevId: 241773765

Broken by https://github.com/google/ExoPlayer/commit/399aa706a7e570e8ed7ca93b54beaae6ee3dac91.

PiperOrigin-RevId: 241770676