SDK / exoplayer

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

-------------
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

Allows DrmInitData to carry a license server URL when the media declares one.

Issue:#3393

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

This reports video and audio format selections.
See [] for spec details.

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

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

This allows to detect changes in the surface size. SimpleExoPlayer already
has the necessary listeners to report size changes for all surfaces whose
lifecycle are managed by SimpleExoPlayer.

In a subsequent change, AnalyticsCollector can be registered as a
VideoListener to automatically notify of surface size changes.

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

Using new Handler(this) in a constructor potentially leaks an uninitialized
object. This is mostly not a problem because we don't use the Handler within
the constructor. Added a Util method to keep the warning suppression local.

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

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

Issue: #4292

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

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

Currently, we are using 2 copy steps for PixelCopySurfaceCapturerV24:
- Copy from the source surface to a similarly sized bitmap (using PixelCopy API).
- Copy from the bitmap to a scaled bitmap, based on the given output size, using scaledBitmap API.
This CL merges the 2 steps and uses PixelCopy API to perform copy directly from
the source surface to the bitmap of the given output size.
However, since our test uses scaledBitmap API to create reference bitmap from original image, due to various Bitmap copy optimizations (filtering, antialiasing etc...) that are different between PixelCopy API and scaledBitmap API implementations, the result images cannot be the same. We can perform the our tests by asserting that their PSNR value is very high, which means they are very similar.

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

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

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

Blacklist Moto C from setOutputSurface

close initDataSource after reading

This enabled the player to specify the bandwidth meter after the track
selector and the track selection factory have been created.

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

The implementation keeps track of QoE sessions and forwards events to the
field reporters of the relevant sessions.

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

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

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

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

This will allow the player to obtain the transfer listener used by the
bandwidth meter in order to pass it automatically to the relevant data
sources.

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

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

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

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

A CacheKeyFactory can be passed to the CacheDataSource constructor, allowing clients to dynamically generate a custom cache key for any given upstream uri.

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

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

This adds an optional parameter to ConcatenatingMediaSource to prepare
child sources only lazily when are needed. This is helpful for long playlists
of media sources with manifests to prevent a lot of simultaneous manifest
loads.

Issue:#3972

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

This allows injection of custom implementations and configuration of
DefaultHlsPlaylistTracker without modifying the HlsMediaSource interface.

Issue:#2844

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

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 enables compiler support for Java 8 features.

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

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