SDK / exoplayer

- Remove ability to encrypt content index for SQLite storage
- Remove hack for specifying arbitrary database location

PiperOrigin-RevId: 232863763

PiperOrigin-RevId: 232835218

PiperOrigin-RevId: 232676346

They may prepare immediately and let pendingMediaPeriods become empty before
all other periods are even created.

PiperOrigin-RevId: 232675283

PiperOrigin-RevId: 232670039

Also removed STOP_FLAG_DOWNLOAD_MANAGER_NOT_READY.

PiperOrigin-RevId: 232669463

When SimpleCache uses a CacheFileMetadataIndex, it will be able to avoid
querying file.length() and renaming files, both of which are expensive
operations on some file systems.

PiperOrigin-RevId: 232664255

Issue: #4253
PiperOrigin-RevId: 232659869

PiperOrigin-RevId: 232651944

Now we're reusing the builder, it's necessary to set maxProgress
back to 0 to avoid the progress bar appearing for end state
notifications.

PiperOrigin-RevId: 232520007

PiperOrigin-RevId: 232507469

After this change, multiple HlsSampleStreamWrappers may contain an apdaptive
track group.

PiperOrigin-RevId: 232507292

onContinueLoadingRequested can occur during preparation, so
MediaPreparer needs to handle it.

PiperOrigin-RevId: 232507267

Issue: #5476
PiperOrigin-RevId: 232503736

On KitKat you need to reuse the same notification builder when
generating a notification that's intended to replace a previous
one. See:

https://stackoverflow.com/questions/6406730/updating-an-ongoing-notification-quietly

PiperOrigin-RevId: 232503682

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