SDK / exoplayer

PiperOrigin-RevId: 525467798

PiperOrigin-RevId: 525434071

PiperOrigin-RevId: 525430439

1.0.1

PiperOrigin-RevId: 525415067
(cherry picked from commit 3788172a)

PiperOrigin-RevId: 525415067

PiperOrigin-RevId: 525176828
(cherry picked from commit 07ff3eee)

PiperOrigin-RevId: 525177113

PiperOrigin-RevId: 525176828

Removes glObjectsProvider from `VideoFrameProcessor` and `Effects`. Apps will set the glObjectsProvider on the DefaultVideoFrameProcessor.Factory.Builder when providing a custom DefaultVideoFrameProcessor.Factory, rather than in `Effects`.

PiperOrigin-RevId: 525169059

A new texture manager will be created for input by texture ID so this texture manager won't be the only one to handle internal (i.e. non-external) textures.

PiperOrigin-RevId: 525116460

Issue: androidx/media#327
PiperOrigin-RevId: 525103046

`findDecoder/EncoderForFormat` seem to be more restrictive than querying
`MediaCodecList` as done for playback, and it's not clear that the cases where
no codec is found correspond to actual cases that would fail given that it
seems this returns an empty string for many cases in production.

Switch to using `MediaCodecUtil` and `EncoderUtil` for querying codecs instead.

PiperOrigin-RevId: 525078321

PiperOrigin-RevId: 525064269

Child: <unknown commit>

PiperOrigin-RevId: 524876651

The sessions may have different application threads for their players,
and the service with its notification provider runs on the main thread.
To ensure everything runs on the correct thread, this change labels
methods where needed and fixes thread access in some places.

Issue: androidx/media#318
PiperOrigin-RevId: 524849598
(cherry picked from commit ffa37430)

This check was a leftover from when the metadata was generated from
the MediaItem only. Since we moved to the actual MediaMetadata fields,
the check is completely unnecessary and prevents accessing metadata
when the GET_CURRENT_MEDIA_ITEM command is not available.

PiperOrigin-RevId: 524837587
(cherry picked from commit e0bb23d4)

Prompted by discussion on this commit: https://github.com/google/ExoPlayer/commit/e8117496e0e8bb0761a4d3f387786be9a23c3002

#minor-release

PiperOrigin-RevId: 524795901
(cherry picked from commit f799766d)

Dackka doesn't support `@value`

PiperOrigin-RevId: 524309695
(cherry picked from commit b834e49f)

The overrides specified by a MediaController may not use the exact
same TrackGroup instances as known to the Player because the groups
have been bundled to and from the controller. This bundling may
alter the instance slightly depending on the version used on each
side of the communication and the fields set (e.g. Format.metadata
is not supported for bundling).

This issue can be solved by creating unique track group ids for
each group on the session side before bundling. On the way back,
the groups in the track selection parameters can be mapped backed
to their original instances based on this id.

Issue: androidx/media#296
PiperOrigin-RevId: 523986626
(cherry picked from commit 1c557e2f)

#minor-release

PiperOrigin-RevId: 523983688
(cherry picked from commit 596a7c70)

#minor-release

PiperOrigin-RevId: 523959161
(cherry picked from commit e033dbac)

#minor-release

PiperOrigin-RevId: 523708424
(cherry picked from commit 81fd9d28)

This change selects the best suited media button receiver
component and pending intent when creating the legacy
session. This is important to ensure that a service can
be started with a media button event from BT headsets
after the app has been terminated.

The `MediaSessionLegacyStub` selects the best suited
receiver to be passed to the `MediaSessionCompat`
constructor.

1. When the app has declared a broadcast receiver for
 `ACTION_MEDIA_BUTTON` in the manifest, this broadcast
 receiver is used.
2. When the session is housed in a service, the service
 component is used as a fallback.
3. As a last resort a receiver is created at runtime.

When the `MediaSessionLegacyStub` is released, the media
button receiver is removed unless the app has provided a
media button receiver in the manifest. In this case we
assume the app supports resuming when the BT play intent
arrives at `MediaSessionService.onStartCommand`.

Issue: androidx/media#167
Issue: androidx/media#27
Issue: androidx/media#314
PiperOrigin-RevId: 523638051
(cherry picked from commit e54a9343)

PiperOrigin-RevId: 523633865
(cherry picked from commit ae875648)

Change what format is logged from MediaCodecAudioRenderer when
AudioSink throws InitializationException. We printed the
AudioSink's format, which most of the times is audio/raw (PCM)
and not the renderer's format. With this change both formats are
logged.

#minor-release

Issue: google/ExoPlayer#11066
PiperOrigin-RevId: 523456840
(cherry picked from commit baf1aa1c)

PiperOrigin-RevId: 523361561
(cherry picked from commit be85684d)

The button gets only updated after an onTracksChanged callback but
isn't set to the initial state similar to other changes triggered
by callbacks (e.g. updateRepeatSwitchUI)

PiperOrigin-RevId: 522274800
(cherry picked from commit 14ba173d)

And also mention a few restrictions regarding legacy components
in Javadoc.

Issue: androidx/media#293
PiperOrigin-RevId: 522005562
(cherry picked from commit 502969a4)

MediaItems are not meant to be unique in a playlist. If a legacy
session publishes multiple items that get converted to equal MediaItems,
the current code fails because we look up queue ids in a Map (that
doesn't allow duplicate entries).

Fix this by storing a simple list of items with additional data.

Issue: androidx/media#290
PiperOrigin-RevId: 521993802
(cherry picked from commit 219967c5)

As most classes are used via interface only and people depending on it locally can always find the Javadoc in Android Studio directly, we don't plan to add Javadocs for these extensions module in developer.android.com.

PiperOrigin-RevId: 521993756
(cherry picked from commit e4cb583a)

The check currently relies on the default value of 0 returned if the
Bundle doesn't define a pid. But in some cases, like Robolectric unit tests,
0 is a possible pid. The check can be improved by directly asserting that
the value is defined.

PiperOrigin-RevId: 521414649
(cherry picked from commit 694d690b)

Issue: google/ExoPlayer#11008
PiperOrigin-RevId: 520864579
(cherry picked from commit 7ca96684)

PiperOrigin-RevId: 520709134
(cherry picked from commit 5af28a98)

The media3-hosted versions of these SVGs were removed due to a change in
the way the reference docs are generated. While work on getting them
hosted on developer.android.com, this change simply links to the
(identical) exoplayer2 versions in order to fix the media3 docs.

#minor-release

PiperOrigin-RevId: 520647905
(cherry picked from commit 2e4f49fe)

PiperOrigin-RevId: 520314781
(cherry picked from commit 6952771e)

`DefaultDrmSession(Manager)` expect most of their methods to be called
on the 'playback thread'. There isn't a playback thread in the case of
`OfflineLicenseHelper`, but in that case it's the thread backing
`DefaultDrmSessionManager.playbackLooper`, which is `OfflineLicenseHelper.handlerThread`.

PiperOrigin-RevId: 520053006
(cherry picked from commit 376bddef)

When MediaCodecRenderer is given an empty sample stream, it puts
its output format change tracking in a bad state where we never
process future stream changes because we are waiting for a sample
that doesn't exist.

We can fix this by:
 - Looping the pending output stream changes to see if we processed
   more than one change at once (this fixes the tracking for empty
   sample streams that are not the first in the queue).
 - Checking if none of the previous streams queued any samples in
   onStreamChanged to handle this in the same way as the case
   where we already output all samples (this fixes the problem when
   the empty sample stream comes first in the queue).
 - Also calling onProcessedStreamChange for the case above, which
   was missing previously.

#minor-release

PiperOrigin-RevId: 519226637
(cherry picked from commit b9790e69)

PiperOrigin-RevId: 518953648
(cherry picked from commit dc3481fc)