SDK / exoplayer

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199758072

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199683216

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199650794

When switching from Stack to ArrayDeque, calls to add() need to be replaced by
calls to push() because ArrayDeque treats the first element in the list as the
top of the stack.

String.split() has counterintuitive default behavior; see
https://github.com/google/error-prone/blob/master/docs/bugpattern/StringSplitter.md.
I've switched usages to pass limit = -1 argument, which means empty elements are
no longer removed from the end of the returned array.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199472592

Issue: #4292

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199478946

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199453125

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199448766

Issue: #4315

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199266768

If a MediaPeriod uses a Loadable, then there are typically
reference chains of the form:

LoadingThread[GCroot]->Loadable->MediaPeriod->Player

Where the player is the MediaPeriod callback. When the
player is released, this reference chain prevents the
player from being GC'd until Loadable cancellation
completes, which may not always be fast. This in turn
will typically prevent the application's activity from
being GC'd, since it'll normally be registered as a
listener on the player (directly or indirectly via
something like a view).

This change mitigates the issue by removing references
that the MediaPeriod holds back to the player. The
MediaPeriod will still not be eligible for GC, but the
player and application activity will be, which in most
cases will be most of the leak (in terms of size).

Issue: #4249

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199143646

This happens when the device screen is locked.

This fixes a previous attempt to fix the problem.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199130325

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199120421

This helps to use the AnalyticsCollector without SimpleExoPlayer. Currently,
that may be problematic, if the contructor needs the player, but in order to
create the player, one already needs the AnalyticsCollector as a listener for
the renderers.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199105012

This happens when the device screen is locked.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198875192

This simplifies Loadable implementations, and also removes the
possibility of an incorrect Loadable implementation causing the
wrong Loader.Callback method being called (perviously, for the
correct method to be called, we relied on isLoadCanceled being
implemented correctly).

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198871133

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198860680

There is the small (but unlikely) chance that the uids clash because the
Objects have the same hash code.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198855724

The bug here was that we'd create a VideoFrameReleaseTimeHelper
using whatever context DefaultRenderersFactory has, and it would
then hold a reference to that context via DisplayManager. A leak
could then occur if the player outlived the life of the context
used to create it (which would be strange/unusual, but not
impossible).

Issue: #4249

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198747599

As highlighted by the ref'd issue, we can end up with
memory leaks if Loadable.load implementations take a long
time to return upon cancelation. This change cuts off one
of the two problematic reference chains.

This doesn't do much about the ref'd issue, since there's
a second reference chain that's much harder to deal with:
Thread->LoadTask->loadable. But since it's easy just to
cut this one off, I figure it makes sense to do so.

Issue: #4249

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198735386

This makes the requirement that all calls are made on one thread more
explicit and also mentions this in the Getting Started guide.

Issue:#4278

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198694579

Issue: #4297

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198536888

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198536438

Manifestless streams.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198445216

I think it was just wrong that it was package private before, since
it resulted in our public API referencing something that's not part
of the public API:

https://google.github.io/ExoPlayer/doc/reference/com/google/android/exoplayer2/source/chunk/BaseMediaChunk.html#init-com.google.android.exoplayer2.source.chunk.BaseMediaChunkOutput-

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198396555

Set content length and redirect uri in a single transaction.

New: Fixed the code where DataSpec.uri is set to null in []

Automated g4 rollback of changelist 196765970.

*** Reason for rollback ***

Fixed the code where DataSpec.uri is set to null in []

*** Original change description ***

Automated g4 rollback of changelist 194932235.

*** Reason for rollback ***

This CL breaks the playability of Mango's offlined progressive videos.

*** Original change description ***

Set content length and redirect uri in a single transaction

NORELNOTES=true
NO_BUG

***

***

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198370211

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198062017

When the player state is changed from an event listener callback, we may
get recursive listener notifications. These recursions can produce a wrong
order, skip or duplicate updates, and send different notifications to
different listeners.

This change serializes listener notifications by clustering all update data
in a helper data class and adding the updates to a queue which can be handled
in a loop on the outer layer of the recursion.

As playWhenReady updates also reference the current playbackInfo, we need to
redirect the listener notifcations for setPlayWhenReady to the same queue.

Issue:#4276

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198031431

r2.8.1

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=197535443

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=197531839

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=197531723

Saving current subtitle cues on SimpleExoPlayer

[extension-ffmpeg] repeatable build instructions

Currently, the sample queues are lazily enabled when they are first read from.
This causes problems when the player tries to discard buffer and the
HlsSampleStreamWrapper assumes the sample queue is disabled even though it's
actually enabled but hasn't been read from.

This change moves setting the sample queue index of the sample stream back into
HlsSampleStreamWrapper. It enables the sample queues at track selection if the
queues are already built, or immediately after they have been built for
chunkless preparation.

Issue:#4241

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=197415741