SDK / exoplayer

PiperOrigin-RevId: 360902971

Issue: #8664
#minor-release
PiperOrigin-RevId: 360877086

PiperOrigin-RevId: 360851146

PiperOrigin-RevId: 360810865

It's for consistency throughout libraries.

PiperOrigin-RevId: 360549525

PiperOrigin-RevId: 360440021

PiperOrigin-RevId: 360433358

PiperOrigin-RevId: 360404403

PiperOrigin-RevId: 360398175

#minor-release

PiperOrigin-RevId: 360384540

exp (ExoPlayer prepare)
ffr (First Frame Rendered)
psr (Player State Ready).

2) Modifies aci/acc vci/vcc to report timing from ExoPlayer Playback thread.

3) Fix to report pvri and pari for every playback.

and other minor bug fixes.

PiperOrigin-RevId: 360228206

Issue: #8646
#minor-release
PiperOrigin-RevId: 360184586

PiperOrigin-RevId: 360175031

Issue: #5246
PiperOrigin-RevId: 360132205

PiperOrigin-RevId: 359783527

PiperOrigin-RevId: 359743165

Includes fixes for the HTTP implementations, which previously
broke this contract specifically in the case when a server
responds to a range request with a HTTP 200 response. To fix
this case, skipping to the requested position is moved from
read() to open(). As a side effect, this nicely simplifies
CronetDataSource!

PiperOrigin-RevId: 359737301

PiperOrigin-RevId: 359734928

PiperOrigin-RevId: 359724874

Also fix a bug where BandaidHttpDataSource would pass -1 to
TransferListener.onBytesTransferred!

PiperOrigin-RevId: 359722821

The API is a lot more useful if apps can rely on the fact
that the gain is linear and applied to all channels.

This is already guaranty by AudioTrack and should be too
by any reasonable implementation.

PiperOrigin-RevId: 359706113

Use the api in YouTube code to update the operating rate.

PiperOrigin-RevId: 359572194

Suggested in a comment on PR Issue: #8615

PiperOrigin-RevId: 359522217

Given we're proposing to make reading from the end a non-error case,
it's important to check that we return the right thing from open(),
and that we read the right thing (i.e., nothing) once opened.

For now, this test allows quite a bit of permissiveness, in line
with other related tests. This will be tightened up in due course.

PiperOrigin-RevId: 359504075

PiperOrigin-RevId: 359486817

Latest LTS version is better than latest stable version because it will
be supported for longer.

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

Allow offload of gapless content even if gapless offload is not known to be supported by the device.

This is not exposed in the high level DefaultRendererFactory as most
users are expected to prefer fidelity to power savings.

PiperOrigin-RevId: 359336407

PiperOrigin-RevId: 359298960

The constant values are the same, so this is a no-op, but for
correctness, we should pass the defined constant that the API
documents itself to accept.

PiperOrigin-RevId: 359293471

The new name reflects that it also waits for previously-used renderers
to be disabled.

Also fix some broken javadoc. These methods changed signature in
https://github.com/google/ExoPlayer/commit/ea347a464a81e16a9afdae0dcb5c0cdfcc533dc5

PiperOrigin-RevId: 359253177

PiperOrigin-RevId: 359244236

The concept of Renderers is not needed in the
Player interface. Move it to ExoPlayer.

This should not break most users as they use SimpleExoPlayer.

PiperOrigin-RevId: 359220977

PiperOrigin-RevId: 359095093

Currently, this only asserts that *if* an exception is thrown, it
must be a position-out-of-range exception as determined by
DataSourceException.isCausedByPositionOutOfRange.

Issue: #7326
PiperOrigin-RevId: 359092124

- Ensure consistency between (Styled)PlayerControlView,
  PlayerNotificationManager, TimelineQueueNavigator and
  DefaultControlDispatcher.
- Handle the case where a live stream has ended when enabling previous
  and next actions (window.isLive() is true and window.isDynamic is
  false in that case)

#minor-release

PiperOrigin-RevId: 359063793

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