SDK / exoplayer

Assert that an exception is not thrown from DataSource.open
if the DataSpec's start position is valid but its end position
extends beyond the end of the data.

HTTP based DataSource implementations have no good way of
knowing when this is the case, so it makes sense to make this
the required behaviour, rather than requiring an exception to
be thrown or allowing both.

There are also use cases where the caller may want to use the
end position as an upper bound, without knowing for sure how
long the content is. An example of this use case is wanting to
pre-cache the first N bytes of a stream. This implies that any
exception should be thrown after reading to the end of the
data, rather than preemptively in open.

Issue: #7326
PiperOrigin-RevId: 359063721

The configuration to publish to Maven seems to be incompatible with the
configuration for bintray, so only enable one at once. Once the GMaven
publishing flow is completely set up we can remove the exoplayerPublishEnabled
constant and the first branch entirely.

Issue: #5246
PiperOrigin-RevId: 359056610

#minor-release

PiperOrigin-RevId: 359041513

- If DataSource.close fails then it's unknown whether the underlying file was
  written to the cache. We should assume that it has not been.
- Always re-query cachedBytes at the start of CacheWriter.cache, since its
  current value may be incorrect if a previous failure was the result of a
  file not being written to the cache.

PiperOrigin-RevId: 359039109

PiperOrigin-RevId: 359021944

PiperOrigin-RevId: 359001281

PiperOrigin-RevId: 359000734

#minor-release

PiperOrigin-RevId: 358998449

- Make it a property of the DataSource, not of the resource.
- Apply it only when a contract test reads using an
  unbounded DataSpec.

PiperOrigin-RevId: 358997735

#minor-release

PiperOrigin-RevId: 358847933

PiperOrigin-RevId: 358823166

This is a key use-case for copy-on-write collections.

PiperOrigin-RevId: 358807866

When we add DRM pre-acquire support to SampleQueue, we'll dispatch
twice the number of acquire and release events. This is slightly
confusing, since there's the same number of
DrmSessionManager#acquireSession() calls.

We can mitigate this by only dispatching each acquire and release
event to at most one EventDispatcher.

This also changes the events fired when playing a stream with both audio
and video encrypted with the same keys (even without pre-acquisition).

Before: The EventDispatcher would see 2 aquires, 1 key load and 2
release events.

After: The EventDispatcher will see 1 acquire, 1 key load and 1 release.
PiperOrigin-RevId: 358804502

PiperOrigin-RevId: 358799813

From media2 1.1.0, it supports API level 16 and above.

PiperOrigin-RevId: 358797986

This is a no-op assuming the class is always used correctly.
When release causes referenceCount to reach zero there can be at most
one EventDispatcher still connected (which is the one that must be
passed to that final release() call), so we can always pass the event
directly to the EventDispatcher passed in to release().

PiperOrigin-RevId: 358794004

Method override parameter nullness should contravariant.

PiperOrigin-RevId: 358772798

There are two different patterns we use at the moment:
 1. Call both deprecated and non-deprecated method from call site with
    no default method implementation body.
 2. Use default method of non-deprecated method to call deprecated
    method.

Pattern 1 is easier to reason about as it makes the calls more explicit,
so changing all usages of pattern 2 to pattern 1.

PiperOrigin-RevId: 358769803

PiperOrigin-RevId: 358384778

This adds an optional DrmSessionManager#preacquireSession() method
and implements it on DefaultDrmSessionManager.

The manager doesn't promise to keep the preacquired sessions alive, and
will proactively release them if a ResourceBusyException suggests the
device is running out of available sessions in the underlying framework.

In a future change, SampleQueue will preacquire sessions on the loading
thread and keep track of preacquired 'references', releasing them
when seeking or clearing the queue.

Issue: #4133
PiperOrigin-RevId: 358381616

PiperOrigin-RevId: 358379167

Starting with Android 12 all components of an app that have an intent filter need to have an explicit attribute android:export that is set to either true or false. If a component filters for the MAIN or a VIEW action it needs the attribute explicitly set to true. Prior to Android 12 these were exported implicitly.

See https://medium.com/androiddevelopers/lets-be-explicit-about-our-intent-filters-c5dbe2dbdce0

PiperOrigin-RevId: 358368785

The published Timeline contains one window only with all periods of
the child sources.

Issue: #4868
PiperOrigin-RevId: 358150276

The release AAR and Android sources are included for each published artifact.

Issue: #5246
Issue: #8353

#minor-release

PiperOrigin-RevId: 358146555

We already report these errors through callbacks to interested listeners.
However, to ease debugging with bugreports and local error detection,
it's helpful to also log these non-fatal execptions to logcat. Otherwise
nothing in logcat indicates that the player recovered from an exception.

Issue: #6384
PiperOrigin-RevId: 357923899

This is preferable to just logging to LogCat so that listeners can
report this to analytics systems if required.

Issue: #6384
PiperOrigin-RevId: 357906079

PiperOrigin-RevId: 357845774

The SampleStream.readData contract is that when reading a sample
with a flags-only buffer, the buffer timestamp and flags should
be set and the read position should not be advanced.

#minor-release

PiperOrigin-RevId: 357842130

PiperOrigin-RevId: 357734165

PiperOrigin-RevId: 357732695

`ImaAdsLoader` will preload the first ad of a subsequent media item, but the
preloaded ad might not actually play because the user could seek to a non-zero
position in that media item (which could trigger playback of a midroll, not the
preroll). In this case, playback would get stuck because the midroll ad
expected to play after the seek would never load, because the IMA SDK expected
the preroll to play first.

Fix this behavior by discarding the preloaded ad break. If there isn't a seek,
the transition to the next media item is still seamless.

#minor-release

PiperOrigin-RevId: 357682510

PiperOrigin-RevId: 357656504

PiperOrigin-RevId: 357587767

PiperOrigin-RevId: 357587009

This type is different to the selection reason, which is
dynamic (i.e., corresponds to the individual selected track,
which can change during playback). The static type is
exposed via TrackSelection, where-as the selection reason
will be internal to the core (i.e., player) module.

PiperOrigin-RevId: 357578201

Previously it was safe to query the first period in the timeline, but
now we support using the ads loader in concatenations we need to use
the current period index instead.

#minor-release

PiperOrigin-RevId: 357578003

These have limited value, and are confusing because they're only
actually used if the override only selects a single track (if the
override is an adaptive selection then the values are never used).
The simpliest path forward is to remove them.

PiperOrigin-RevId: 357573186

#minor-release
Issue:#8581
PiperOrigin-RevId: 357563419

Issue: #8585
#minor-release
PiperOrigin-RevId: 357553237

PiperOrigin-RevId: 357549002