SDK / exoplayer

DefaultDownloadIndex is currently just forwarding all calls to its
inner class. getDownloadTable() handles initialization, but this
doesn't really seem different to having an initialization method. It
doesn't guarantee initialization happens, since a bad method
implementation could try and access downloadTable directly, just as
a bad method implementation could forget to call the initialization
method. Hence this change removes the indirection.

PiperOrigin-RevId: 232482228

PiperOrigin-RevId: 232481580

This method is needed by DownloadManager.

PiperOrigin-RevId: 232447145

Imported from GitHub PR https://github.com/google/ExoPlayer/pull/5462

Pull request for the following issue: #5421
Merge d9d88b079c4ca0533a836b2715a65b924babbb89 into a7381916

PiperOrigin-RevId: 232335113

This combines all the different listeners in ExoVideosPlayerV2 into one and
moves the PlaybackLogger class towards ExoPlayer's AnalyticsCollector with
the same purpose.

In the future this allows two things:
 1. Gradually move LogginClient implementations to AnalyticsListener to
    prevent custom event forwarding.
 2. Using ExoPlayer's QoE extension (which is also an AnalyticsListener).

PiperOrigin-RevId: 232321182

When calling releaseSource(), all pending messages will be removed. That means
that all action-on-completion callbacks which are somewhere in flight are
just dropped without being called. This change adds code to keep track of the
current state of each callback to allow all of them being called when the
source is released.

Issue:#5464
PiperOrigin-RevId: 232312528

The Util class already handles removeMessages calls but so far ignored calls
to removeCallbacksAndMessages.

PiperOrigin-RevId: 232312458

DownloadTracker will stop updating DownloadIndex when DownloadManager
starts using the same DownloadIndex.

PiperOrigin-RevId: 232306803

This change enables transitioning to/from different Storage
implementations, to allow experimentally enabling (and if
necessary, disabling) SQLiteStorage. All that's left to do
is the final wiring to turn it on

PiperOrigin-RevId: 232304458

Issue: #4519
PiperOrigin-RevId: 232299233

Now DownloadManager is responsible for starting and stopping DownloadThreads.

PiperOrigin-RevId: 232278072

PiperOrigin-RevId: 231801562

PiperOrigin-RevId: 231772920

PiperOrigin-RevId: 231764284

Issue: #4468
PiperOrigin-RevId: 231759438

PiperOrigin-RevId: 231744540

PiperOrigin-RevId: 231644908

Including ParametersBuilder and TrackSelectionOverride.

PiperOrigin-RevId: 231609249

PiperOrigin-RevId: 231600104

PiperOrigin-RevId: 231586206

PiperOrigin-RevId: 231578828

PiperOrigin-RevId: 231567138

PiperOrigin-RevId: 231425073

If there is data after the last samples in the container, we may request
continue loading after the last samples have been read but before the load has
completed. In this situation the buffered position is returned as
Long.MAX_VALUE, which prevents continuing loading, yet the media period is not
treated as fully buffered because its buffered position is not
C.TIME_END_OF_SOURCE.

PiperOrigin-RevId: 231406964

We can keep the reading media period and continue playing if we haven't read
beyond the new duration. Otherwise, we can keep the period, but need to reset
the renderers as we already read too far.

PiperOrigin-RevId: 231406252

PiperOrigin-RevId: 231396213

On older API levels it's also necessary to implement
openOrCreateDatabase, to be called by SQLiteOpenHelper.

PiperOrigin-RevId: 231387559

It better describes what the class does. More importantly, we've had
inconsistent class names since we added offline support, for which we
added ProgressiveDownloader ("ExtractorDownloader" doesn't make any
sense). We could really do with aligning the names for clarity.

(Sorry)

PiperOrigin-RevId: 231387268

Issue:#2867
PiperOrigin-RevId: 231385677

These methods take a list of languages to be downloaded and add selections for
each of the languages.

PiperOrigin-RevId: 231385632

The subclasses only call specific constructor combinations and can easily
replaced by static methods.

PiperOrigin-RevId: 231385606

This requires to prepare the media source and the periods in a small helper similar
to the metadata retriever. It also gets rid of the need to have abstract protected
methods to load the manifest, to extract the track groups and to convert to stream keys,
as this can now be handled by the media period.

PiperOrigin-RevId: 231385590

PiperOrigin-RevId: 231385563

Currently, we remove all variants if none of the stream keys contains any
variants. This causes HlsMediaPeriod to throw exceptions as it expects at least
one variant.

Change it to support master playlists without variants.

PiperOrigin-RevId: 231385547

PiperOrigin-RevId: 231385518

Converting a single track selection to stream keys is only possible if the output
is independent from other track selections being made.

This is not the case for DASH and HLS embedded track groups which should select the
already selected primary track if possible (and thus needs to know  whether a primary
track group is selected).

Also, update the test method to take a period index.

PiperOrigin-RevId: 231385490

This should be removed after releasing.

PiperOrigin-RevId: 231380393

The way it is currently, it's very unclear that an operation on the
version table will correctly belong to a transaction in code such as
this, taken from DefaultDownloadIndex:

writableDatabase.beginTransaction();
try {
  writableDatabase.execSQL(...);
  versionTable.setVersion(...);
  writableDatabase.setTransactionSuccessful();
} finally {
  writableDatabase.endTransaction();
}

This change explicitly passes the database, to make it obvious that
the operation will really go into the same transaction:

writableDatabase.beginTransaction();
try {
  writableDatabase.execSQL(....);
  VersionTable.setVersion(writableDatabase, ...);
  writableDatabase.setTransactionSuccessful();
} finally {
  writableDatabase.endTransaction();
}

PiperOrigin-RevId: 231374933

PiperOrigin-RevId: 231223201

Goal: reduce binary size.
PiperOrigin-RevId: 231198579