SDK / exoplayer

PiperOrigin-RevId: 369671127

Also consolidate the threading warning info with the same info on the
hello world page and update the version that the
setThrowsWhenUsingWrongThread() method will be removed in.

PiperOrigin-RevId: 369657759

Remove spurious blank lines introduced in https://github.com/google/ExoPlayer/commit/dafea4e40fb5eba91597cf16cab06140ebaaaff4

PiperOrigin-RevId: 369648457

PiperOrigin-RevId: 369642047

PiperOrigin-RevId: 369635363

A subsequent change will make the UI module access
SphericalGLSurfaceView and VideoDecoderGLSurfaceView
using reflection, now we're at the point where we only
need to reflect the constructors.

PiperOrigin-RevId: 369630102

PiperOrigin-RevId: 369626542

PiperOrigin-RevId: 369615413

PiperOrigin-RevId: 369609585

*** Original commit ***

Rollback of https://github.com/google/ExoPlayer/commit/e60609e34447553474cdfc86b2dee5462316b10c

*** Original commit ***

Prevent creation of new sessions if the Timeline is empty.

We currently create sessions based on the placeholder window
index. This shouldn't be needed as we now set a non-empty
timeline as soon as the first MediaItem...

***

PiperOrigin-RevId: 369609523

See go/media-apis-codebase-google3.

PiperOrigin-RevId: 369603286

Issue: #8804
PiperOrigin-RevId: 369484117

The protected visibility causes problems in Kotlin (Issue: #8830) and
also prevents a subclass of AdaptiveTrackSelection.Factory that isn't
nested inside a subclass of AdaptiveTrackSelection (in both Java and
Kotlin).

#minor-release

PiperOrigin-RevId: 369468841

*** Original commit ***

Prevent creation of new sessions if the Timeline is empty.

We currently create sessions based on the placeholder window
index. This shouldn't be needed as we now set a non-empty
timeline as soon as the first MediaItem is added to the playlist.

Once this check is part of the session manager, we can also remove
the equivalent workarounds from the various code integrations.

***

PiperOrigin-RevId: 369452067

PiperOrigin-RevId: 369444747

PiperOrigin-RevId: 369443204

PiperOrigin-RevId: 369442687

This method shouldn't be used anymore since the thread enforcement
is the default already. We still keep it for now to ease the transition
for apps that use ExoPlayer on multiple threads and want to temporarily
disable the enforcement while the threading problems are fixed.

PiperOrigin-RevId: 369440789

PiperOrigin-RevId: 369433627

We currently create sessions based on the placeholder window
index. This shouldn't be needed as we now set a non-empty
timeline as soon as the first MediaItem is added to the playlist.

Once this check is part of the session manager, we can also remove
the equivalent workarounds from the various code integrations.

PiperOrigin-RevId: 369432853

See go/media-apis-codebase-google3.

PiperOrigin-RevId: 369425137

PiperOrigin-RevId: 369425007

The original cl has been fixed by not implementing
VideoListener but Player.Listener in
StyledPlayerView.

VideoFrameMetadataListener and CameraMotionListener are still part
of the Player interface as a good way to break the UI dependency
on them has not yet been finalised.

PiperOrigin-RevId: 369417682

PlayerView is not affected.

PiperOrigin-RevId: 369401563

PiperOrigin-RevId: 369315524

This change moves the responsibility of creating, configuring and starting the MediaCodec from the MediaCodecRender to the MediaCodecAdapter.Factory.

This move allows ExoPlayer's client to decide how and when codecs are created and/or reused.

To allow the move, this CL replaces MediaCodecRenderer.ConfigureCodec with MediaCodecRenderer.getCodecConfiguration

PiperOrigin-RevId: 369273887

PiperOrigin-RevId: 369215083

This was likely an oversight when first importing #4930.

PiperOrigin-RevId: 369199775

*** Original commit ***

Move VideoComponent in ExoPlayer

VideoFrameMetadataListener and CameraMotionListener are still part
of the Player interface as a good way to break the UI dependency
on them has not yet been finalised.

***

PiperOrigin-RevId: 369194309

* Prefer instanceof to getClass when implementing Object#equals.
  (see http://go/bugpattern/EqualsGetClass)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneFragileCode if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/exoplayer/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/exoplayer/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

PiperOrigin-RevId: 369180513

VideoFrameMetadataListener and CameraMotionListener are still part
of the Player interface as a good way to break the UI dependency
on them has not yet been finalised.

PiperOrigin-RevId: 368863829

Other tests in this file already use `Executors.newSingleThreadExecutor` so do the same for the ones that currently use `mockExecutor`.

PiperOrigin-RevId: 368859470

PiperOrigin-RevId: 368851903

PiperOrigin-RevId: 368822503

PiperOrigin-RevId: 368818853

Before this change:
- SimpleExoPlayer.prepare(mediaSource) ended up calling
  ExoPlayerImpl.setMediaSourcesInternal() with startWindowIndex=0 and
  resetToDefaultPosition=false.
- ExoPlayerImpl.prepare(mediaSource) ended up calling
  ExoPlayerImpl.setMediaSourcesInternal() with
  startWindowIndex=C.INDEX_UNSET and resetToDefaultPosition=true.

This was functionaly equivalent but a bit confusing.

#minor-release

PiperOrigin-RevId: 368818143

Even when fixed to the US locale (and thus avoiding surprising behaviour
in e.g. Turkish locale with "i" and "I") there are unexpected behaviours
when upper and lower casing non-ASCII characters.

For example it's sometimes not symmetric, e.g.:
"ẞ".toLowerCase() -> "ß"
"ß".toUpperCase() -> "SS"

In all the ExoPlayer usages we are either dealing with known-ASCII
strings (e.g. MIME types) or comparing against ASCII constant strings
anyway, so it seems easier to just use Guava's ASCII-only class in these
cases.

Util.toUpperInvariant() is null-tolerant, while Ascii.toLowercase() is
not. Most usages in this change are clearly non-null. The BandwidthMeter
usages aren't annotated @Nullable, but the current code *would* work if
countryCode was null in both cases. These methods will now throw NPE if
they're passed null.

PiperOrigin-RevId: 368816287

PiperOrigin-RevId: 368803206