SDK / exoplayer

*** Original commit ***

Update Gradle version to 4.1.1

This was suggested by AndroidStudio.

***

PiperOrigin-RevId: 353887400

This was suggested by AndroidStudio.

PiperOrigin-RevId: 353879939

- The order of sample stream (and thus the order in which loads are
  triggered) currently depends on a Set and thus on the hash codes
  of the objects that change with every run. Changing to a List solves
  this problem.
- The FakeAdaptiveDataSet directly created a static Random (with random
  seed) to compute the variation of chunk sizes. Changing this to an
  injected Random object that can always be initialized with the same
  seed also removed this randomness from the tests.

PiperOrigin-RevId: 353878661

This is achieved by only triggering one message at a time. After
triggering a message we send another to ourselves to know when the
following message can be triggered.

Other required changes:
 - The messages need to be sorted correctly (by time and creation order)
 - To prevent deadlocks when one thread is waiting for another,
   we need to add new method to Clock to indicate that the current
   thread is about to wait. This then allows us to trigger messages
   from other threads in FakeClock.
 - AnalyticsCollectorTest needed some adjustments:
   - onTimelineChanged now deterministically arrives after the initial
     timline is already known, so some of the period information changes
     from window only to full period info.
   - The playlistOperations test suffers from a bug that the first frame
     is rendered too early and that's why we now get additional events.

PiperOrigin-RevId: 353877832

We currently only remove messages that have already been sent
to the actual Handler, not the pending ones that are only kept
in the FakeClock. Fix this by also removing matching messages
from the FakeClock list.

PiperOrigin-RevId: 353877049

Currently only delayed messages are handled. Change this to handling
all messages so that we have more control over their execution order.

This requires adding a new wrapper type for the Message to support
the obtainMessage + sendToTarget use case.

PiperOrigin-RevId: 353876557

This functionality isn't used and there is no point in supporting
it.

PiperOrigin-RevId: 353876038

- Fix comparison between a byte and 0xFF to avoid conversion of 0xFF to
  byte and to int again (due to numeric promotion).
- Fix addition of int and byte with most significant bit set. The byte
  was incorrectly promoted to an int negative value.

Issue:#8496
#minor-release
PiperOrigin-RevId: 353865751

PiperOrigin-RevId: 353864181

This is needed for the MediaFormat#getInteger calls in onConfigured().

The end-to-end playback tests this is used for have to run on API 29
anyway (because of ShadowMediaCodec and ShadowMediaCodecList
functionality).

#minor-release

PiperOrigin-RevId: 353858622

PiperOrigin-RevId: 353858581

#minor-release

PiperOrigin-RevId: 353856211

These changes are all in 2.12.3, they shouldn't be in the 2.13.0
section.

#minor-release

PiperOrigin-RevId: 353855677

PiperOrigin-RevId: 353655249

#minor-release

PiperOrigin-RevId: 353649545

They only require common. This allows their use for non-playback networking
without requiring the user to depend on the whole of core. I will also make
the same change for Cronet, although this needs a little more work.

PiperOrigin-RevId: 353649388

Issue: #7565
PiperOrigin-RevId: 353649187

This is the last CL to move Player in common.

#player-to-common

PiperOrigin-RevId: 353642347

`TrackSelection` had mutation methods which were to be called only
internally by ExoPlayer components but were exposed in the
public `Player` interface.

The mutation methods have been moved out of `TrackSelection`
to a new class `ExoTrackSelection`.

Current track related read-only method have also been moved out,
because they are actually something quite unclear.
Even for a single item playlist, it's the track being buffered rather
than the track being played, which is unclear.
But when you have a playlist it starts to get really confusing,
because if the next item is being buffered, then it's actually
the last track to be buffered in the currently playing item.
As a final aside, the implementations don't do proper thread synchronization
to ensure visibility of updated state by the calling thread.

Exposing those mutable methods in the public `Player` interface
was problematic because they leaking internal concepts of `ExoPlayer`.
This is also required to minimize the `Player` interface for long term
stability.

`ExoTrackSelection` is a subclass of `TrackSelection`.
This is not ideal as an `TrackSelection` implementation could
break the current immutability.
This was done in order for this refactor to be simpler.
A future patch will fully split the two classes.

All `MediaPeriod` and `Sources` had to be updated to use the new
`TrackSelection` dynamic aspect class name.
An alternative would have been to break ExoPlayer's public API, keeping
`TrackSelection` as the dynamic aspect name, and calling the public static
aspect class `TrackSelectionState` or similar.
Nevertheless, while it would have impacted less files, it would have
many more small apps and casual users of ExoPlayer.

#player-to-common

PiperOrigin-RevId: 353637924

Issue: #7565
PiperOrigin-RevId: 353616594

PiperOrigin-RevId: 353615959

This change fixes a bug in CronetDataSource when it makes a Range
request but the server does not support Range requests and returns the
entire resource. Before the fix, the CronetDataSource would read more
bytes than the intended range.

PiperOrigin-RevId: 353614477

Issue: #7565
PiperOrigin-RevId: 353613493

We normally wouldn't do this kind of thing, given CronetDataSourceFactory is
deprecated, but it's needed to change the cronet --> core dependency to a
cronet --> common dependency.

PiperOrigin-RevId: 353609198

`ImaAdsLoader` only loads ad media URLs once playback of the preceding ad (if
any) has started, and this behavior is likely to be similar for other ad loader
implementations due to limits on how long before an ad plays it is meant to be
loaded. This is problematic for very short ads followed by an ad because the ad
will load to the end but load control may not allow playback to start due to
the total buffered duration being low.

Fix this by allowing playback to start regardless of load control if we are
waiting for an ad media period to prepare.

An alternative fix would be to fake the ad progress in the `ImaAdsLoader` to
trigger loading the next ad, but this would only allow one ad to load ahead (so
the problem would remain for two short ads in a row followed by another ad).

Issue: #8492
PiperOrigin-RevId: 353600088

Instead it uses a TrackSelection[].

#player-to-common

PiperOrigin-RevId: 353584567

This is necessary for the child cl that `TrackSelection`
in two distinct class. It avoids to split the array
version of such class too.

TrackSelectionArray exist to have an immutable array of TrackSelection.
Internal users are trusted to not mutate the array.

One drawback of this approach is that a `TrackSelectionArray`
has to be allocated on the boundary of the `Player` interface.
This should not be a performance issue as this only happens
on trackSelection changes, when the user calls
`Player.getCurrentTrackSelections` and on
`updateLoadControlTrackSelection`.

#player-to-common

PiperOrigin-RevId: 353582654

#minor-release

PiperOrigin-RevId: 353394376

PiperOrigin-RevId: 353290124

PiperOrigin-RevId: 353254249

Deprecate other DRM config methods.

Issue: #8466
PiperOrigin-RevId: 353251452

These are used by the cast extension, so will need moving eventually!

PiperOrigin-RevId: 353219703

PiperOrigin-RevId: 353212567

This field changed name during the code review, but these names and
references weren't updated to match.

Also use an ImmutableSet since the field is a Set.

PiperOrigin-RevId: 353021268

This is needed to ensure the Handler is goverened by the clock.

PiperOrigin-RevId: 353020654

This ensures the message devilery is governed by the clock.

Also replace setting a Handler with a Looper to facilititate this
change.

PiperOrigin-RevId: 353019729

Not checking it would force ExoPlayer to use the
global tmp dir which would expose it to
external file replacement attacks.

This is a theoretical vulnerability as this code is
only use in tests and cache dir always exist in the
AOSP android implementation.

PiperOrigin-RevId: 353013929

This ensures the Handler is governed by this clock.

PiperOrigin-RevId: 353011555

The IMA SDK currently notifies `CONTENT_RESUME_REQUESTED` then
`CONTENT_PAUSE_REQUESTED` quickly afterwards when playing an ad for an initial
seek. This triggered the logic to skip VPAID ads added for Issue: #7832,
causing the ad to be skipped.

This change reverts the fix for that issue and extends the ad preload timeout
logic to cover the case of an initial seek as well. Incompatible VPAID ads will
still be skipped but only after the preload delay (this seems fine given that
they are documented not to be supported, and we are just making the failure
mode less bad on a best-effort basis!).

Issue: #8428
Issue: #7832
PiperOrigin-RevId: 353011270

This is a dependency of TrackSelection and Player.

#player-to-common

PiperOrigin-RevId: 353004379