SDK / exoplayer

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

We had these specified directly in AndroidManifest.xml due to
our internal build setup. This change makes our internal build
re-write AndroidManifest.xml to dynamically insert the required
values, meaning they no longer need specifying in each manifest.

Bonus 1: Internally built demo apps now include the CL number at
which they're built in the version name :).

Bonus 2: Removes lint warning that complains min/target SDK
values in the manifest are redundant.

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

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

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

- Change 'compile' configuration (deprecared) to using 'implementation'
and 'api' configurations instead.

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

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

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

Also remove logic for tracking the next output buffer in LibvpxVideoRenderer, as
this allowed many consecutive frames to be rendered that were actually late
after dropping to keyframe. It looks better to show frames at a consistent
100 ms rate.

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

To support Google Assistant media apps need to support the action
ACTION_SET_RATING. Before this change developers have to use a QueueEditor for
this which does not have any other mandatory actions required for Assistant.
With this change developers can implement the rating action with the
PlaybackPreparer which they need to implement anyway to support Assistant.

https://developer.android.com/guide/topics/media-apps/interacting-with-assistant.html#transport_controls

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

The playback state in ExoPlayerImpl and ExoPlayerImplInternal is usually kept
in sync. Only the timeline was so far not updated in the same way with the
internal player using a null timeline while ExoPlayerImpl keeps the previous
timeline.

This change removes the need to keep a null timeline which allows to update
the internal timeline in the same way as the external one. This fixes problems
when retrying a failed playback multiple times.

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

The start position was set to the old start position instead of the current
playback position. We need to set the start position to the current playback
position to ensure a repreperation with the same media starts from the last
playback position.

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

Issue: #3926

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

This restores functionality that was lost when we added
support for general timed message delivery.

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

Before this change, HlsMediaSource timelines had a period starting at the epoch.
For VOD streams the window position in the period was the program date time.

This change makes period and initial window positions match. For live streams
the window position advances as segments are removed, so its position in the
period is the difference between the initial program date time and the program
date time of the latest playlist.

This also makes it possible to insert ads in VOD HLS content with program date
time, as the period and window are now aligned.

Issue: #3865

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

AdsMediaSource must be top-level. Currently the (deprecated) ImaAdsMediaSource
can't be used because it prepares its contained AdsMediaSource as a child
source.

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

r2.7.0

Allow the position to jump on receiving the first presentable input buffer,
if and only if the buffer timestamp differs significantly from what was
expected. This prevents a stuck buffering case for streams that are thought
to start at t=0, but actually start at t=large_value.

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

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

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

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

Occasionally the player could transition from playing content to playing an ad
after IMA called playAd. The discontinuity triggered faking the content
position, and the fake position was passed to IMA when content resumed causing
the wrong ad group to be loaded. Fix this by only faking the position if the
player transitions before playAd.

Also fix the calculation of the expected ad group index for a postroll ad, and
wait for the player to transition back from ad to content before passing a
content progress update.

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

If an exception is thrown in an IMA callback it crashes the process with lots of
logging from WebView (including several stack traces, etc.). This change wraps
ImaAdsLoader code that might throw, skips any remaining ads (as the errors are
not recoverable, in general) and notifies a new load error callback so that the
application can implement its own handling. The intention is to make the loader
robust to unexpected requests from IMA and avoid crashes.

Also handle IMA loading an ad in an ad group that has no available ads. In rare
cases IMA will try to load an ad for which an error was previously notified, so
this drops those load requests allowing playback of the content to continue.

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

Issue:#3340

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

All media periods are part of a queue of windows buffered and played by
ExoPlayer. When repeating windows, the current MediaPeriodId is insufficient
to distinguish between the repetitions of the same period. This makes it hard
to see to which media period load events belong to, and it is also difficult to
determine whether two media periods belong to the same logical window or
whether they are part of different repetitions of the same window.

Therefore this change adds a unique sequence number to each window in the
sequence of windows and this sequence number is saved as part of the
MediaPeriodId.

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

If there was no preroll and the pending content position was set before the
first midroll, the pending content position was never cleared so loading the ad
was never triggered.

Only set a pending content position if we know that we need to trigger playing
an ad for the current position and IMA will poll for an ad (because there is a
midroll ad group). Clearing the pending content position happens when IMA pauses
content to play the ad.

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

IMA sometimes delivers an ad group load error just after the time of the ad
group, which is problematic now that we set the expected ad group index based on
the last returned content progress.

Only update the expected ad group index once we are within a fixed preloading
threshold of the next ad.

Also fix updating the ad group to use the new ad count, and check for ad group
load errors when we have no expected ad group defensively.

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

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

Content progress is only polled if there are midroll ad groups. If the ad tag
had only preroll/postroll ads, the pending content position was not provided to
IMA, which meant that the postroll ad could never play.

Only set the pending content position if there are midroll ads.

Issue: #3715

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

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

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

Issue: #3782

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