SDK / exoplayer

If EventDispatcher.removeListener is called to remove a listener,
and if the call is made from the same thread that said listener
handles events on, then it should be guaranteed that the listener
will not be subsequently invoked on that thread.

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

This seems to be more stable in case Bintray has issues updating the ExoPlayer
sources.

Issue:#4997

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

In ConcatenatingMediaSource, the source may be removed before it started
preparing (this may happen if lazyPreparation=true). In this case, we
shouldn't call releaseSource as the preparation didn't start.

Issue:#4986

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

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

This is a no-op change as the respective values are not used so far but
the change makes the current state cleaner and is less error-prone.

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

This removes the experimental bandwidth meter and uses it as the new default.

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

Issue:#4960

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

Just not doing it seems simplier and more obviously correct
than suppressing the warnings in our proguard file.

Issue: #4890

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

Issue: #3241

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

The assertion was so weak it probably wouldn't detect genuine
misuse of the DefaultAllocator API, so it seems fine just to
remove it.

We don't really know what happens when the player is allowed to
continue on the affected devices, but hopefully it either "just
works" or fails in a more graceful way.

Issue: #4532

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

Robustness fix to make sure we ignore tags with known names, but
which are nested inside of unknown tags. For example we don't want
to parse the third period in:

<Period>...</Period>
<Period>...</Period>
<CustomTag>
  <Period>...</Period>
</CustomTag>

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

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

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

- Always clip to period duration for the last chunk. We previously
  did this only when the last chunk explicitly exceeded the period
  end time. We now also do it when the chunk claims to end at the
  period boundary, but still contains samples that exceed it.
- If pendingResetPositionUs == chunk.startTimeUs == 0 but the
  chunk still contains samples with negative timestamps, we now
  clip them by setting the decode only flag. Previously we only
  clipped such samples if the first chunk explicitly preceeded the
  start of the period.

Issue: #4899

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

This makes the following changes to improve consistency among the PlaybackInfo
values:
 1. Update buffered position and total buffered duration after loading period
    is set as both values are affected by a loading period update.
 2. Add copyWithPosition to allow updating the position without resetting the
    loading period.
 3. Forward the total buffered duration to playing position updates
    as it may have changed with the new playing position.

Issue:#4899

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

#4306 - Extract tags from SubRip subtitles, add support for alignment

When SubtitlePainter positions the cues centred in the given box, it must add
the left offset of the box to get the correct position.

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

SubtitleView forwards the cue box position to SubtitlePainter. This should be
the position relative to the canvas of the SubtitleView. Currently, however,
we forward the position relative to the parent of SubtitleView. That causes
problems if SubtitleView has a non-zero offset position to its parent.

Issue:#4788

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

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

If we prepare a deferred media period before the actual timeline is available,
we either prepare with position zero (= the default) or with a non-zero
initial seek position.

So far, the zero (default) position got replaced by the actual default position
(including any potential non-zero window offset) when the timeline became known.

However, a non-zero initial seek position was not corrected by the non-zero
window offset. This is fixed by this change.

Related to that, we always assumed that the deferred media period will the
first period in the actual timeline. This is not true if we prepare with an
offset (either because of an initial seek position or because of a default
window position). So, we also determine the actual first period when the
timeline becomes known.

Issue:#4873

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

This makes the annotations appear in the generated JavaDoc.

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

This allows selectAudioTrack() to be overridden.

Fix markdown

Apps need to set the target compatibility to VERSION_1_8 to enable the
automatic desugaring if they haven't done so already.

Issue:#4907

r2.9.0

If a source is removed from the playlist, the player may still call createPeriod
for a period of the removed source as long as the new timeline hasn't been handled
by the player. These events are stale and can be ignored by using a dummy media
source. The stale media period will be released when the player handles the updated
timeline.

Issue:#4871

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

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

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

Issue: #4834

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

Issue: #4857

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

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

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

This method needs to be called whenever the track selection of the current
loading period changes, but also when the loading period itself (and thus
the "loading track selection") changes. These are the same situations in which
we update the loading media period id and thus we can move both updates in
a common helper method.

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

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

From API 23 this uses the timed format queue. Before API 23 the
format is notified as soon as the buffer is queued.

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

Before this change we would reset the start trim to zero after initial
configuration (at the start of playback) and after seeking to any position. The
fact that no trimming was applied at the start of playback meant that after the
first period transition we'd see a mismatch between the next buffer timestamp
(equal to the duration of the period taking into account edits) and the duration
of audio submitted to the sink.

This change modifies the behavior so that we reset the start trim to zero only
if some audio was queued since configuration. This is incorrect in the case of
starting playback at a non-zero position, but fixes the common case of starting
at zero. As before, a later seek to any position is handled via a flush and
resets the trim as required.

Transitions from one period to the next are unaffected by this change.

One way to implement start trimming correctly would be to provide the input
buffer timestamp to the audio processors and only trim when handling audio from
the start of the stream, but that is a larger change so left for later.

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