SDK / exoplayer

- Improve variable naming
- In the edge case that bytes are transferred in a sample that
  has 0 elapsed time, carry the bytes forward into the next
  sample. If we don't do this then the estimate will be calculated
  as though those bytes were never transferred. In practice I
  suspect this very rarely occurs.

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

Issue: #2826

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

Issue: #4954

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

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

Issue: #2826

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

Issue: #2826

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

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

Turn on flag to enable fast loop filtering. This improves
multi-threaded decode performance by starting loop filtering early
if there are free threads available to do so.

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

Makes it consistent with MediaItem.media.

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

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

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

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

There are multiple subtle issues with the current implementation:

1. setOperatingRate can cause a codec initialization even if the
   renderer is disabled. This is not supposed to happen.
2. If the codec is released whilst the renderer is disabled, the
   renderer can instantiate a new codec using the old format when
   it's enabled again, only to immediately have to reconfigure or
   release it if the actual format to be played is different.
3. Codec reuse does not take into account renderer configuration.
   The specific case where this is problematic is if the video
   renderer is re-enabled with a different tunneling session id.
   The reused codec is then not configured correctly.

Also moved availableCodecInfos reset into releaseCodec for sanity.

Issue: #2826

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

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

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

Mimics the ExoV1 behavior.

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

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

- Added ability to override the DefaultBandwidthMeter network type.
- These methods currently only work properly if called before the
  meter is used, but the plan is for them to be handled in the same
  way as internally detected network changes.

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

This method only ensured backward compatibility while the new version was not
public yet. Now ExoPlayer 2.9.0. is public, this workaround can be removed.

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

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

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

*** Reason for rollback ***

Photos regression is resolved by []

*** Original change description ***

Automated g4 rollback of changelist 217189082.

*** Reason for rollback ***

Broke photos (b/117818304)

*** Original change description ***

Add ExoPlayer.setForegroundMode

Issue: #2826

***

***

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

I don't think there's any particular reason for releasing
dummySurface when we release the codec. It seems to make
more sense to decouple the two, and treat a dummySurface as
a resource that should be released on reset.

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

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

Issue:#4960

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

setSurface only sets the output surface on the codec if the
renderer is enabled or started. This was fine in the past
because the codec was always null in other states, however
the recent codec reuse work means this is no longer the case.

The output surface should always be set if the codec is
non-null. If setting the surface requires releasing the codec
instance, we should only instantiate the new instance if
enabled or started. This is in line with what onDisabled does
if flushing requires releasing the codec

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

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

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

*** Reason for rollback ***

Broke photos (b/117818304)

*** Original change description ***

Add ExoPlayer.setForegroundMode

Issue: #2826

***

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

Renamed to stop collision between the ExoV1 and ExoV2 implementation.

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

Issue: #3241

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

Issue: #2826

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

1. Remove option to pass null context to Util.getNetworkType. IMO it's
   clearer for the caller to just not call the method in this case.
2. Stop using deprecated DefaultBandwidthMeter.Builder constructor in
   all but one place.

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

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

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

Issue: #2826

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

For decoder reuse, we want disable() to flush the decoder. However,
if the flush needs to release the decoder for some reason, it seems
non-ideal to immediately re-initialize it. Re-initialization can
also throw ExoPlaybackException, which we don't want for disabling.

This change allows a variant of flush that wont re-initialize the
decoder if it has to be released, which will be used from disable().

Issue: #2826

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