References to the service are kept from MediaSessionStub
and from a long-delayed Handler messages in ConnectionTimeoutHandler.
Remove strong references from these places by making the timeout
handler static and ensuring ConnectedControllersManager only keeps
a weak reference to the service (as it's part of MediaSessionStub).
Issue: androidx/media#346
PiperOrigin-RevId: 527543396
(cherry picked from commit 8c262d6c072304ed9f16feca64b70a18645cc908)
To reliably reject the System UI playback resumption notification on
all API levels (specifically API 30), the backward compatibility layer
needs to return `null` for the library root.
This is not possible in the Media3 implementation. This change allows
an app to return a `LibraryResult.ofError(RESULT_ERROR_NOT_SUPPORTED)`
that then is translated to return null by the backwards compatibility
layer.
Issue: androidx/media#355
Issue: androidx/media#167
Issue: androidx/media#27
See https://developer.android.com/guide/topics/media/media-controls#mediabrowserservice_implementation
PiperOrigin-RevId: 527276529
(cherry picked from commit 7938978b5165a9cbb63a6ee1fe5209934e996c6e)
`prepare()` now logs a warning if it's called before `setPlayer()`
because it's not possible to tell if it's being called on the wrong
thread (since 3480a27994).
This change finds all the places one is called immediately after the
other and flips the order to be more correct.
Issue: androidx/media#350
#minor-release
PiperOrigin-RevId: 526582294
(cherry picked from commit 6aacbc6bbb11a5a55ec812cc93e0bb1b6810749e)
And remove unnecessary check for isDone.
Issue: androidx/media#345
PiperOrigin-RevId: 525999615
(cherry picked from commit 186f3d5c7767e65cc823846b045282c05ed30da5)
This is a bug currently, where commands are created once but never
updated again if the actions in MediaSessionCompat are changed.
PiperOrigin-RevId: 525999084
(cherry picked from commit 79fab6783e07ea594410be347c8a3d6e1124707d)
If the limited number of input buffers causes reading of all samples except the last one conveying end of stream, then the last frame will not be rendered.
PiperOrigin-RevId: 525974445
(cherry picked from commit affbb7c57e73eb4f4f654f224c477fdd2e3ac9f2)
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 ffa3743069408cf794cd48e8608df749e09d719e)
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 e0bb23d4634421ede8827948a3ddae9c5d4a9089)
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 1c557e2fd18c77243474af2f8c99fa6ea061b38a)
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 e54a9343980c7f6c44ddf0edbb938dd5f6b11193)
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 baf1aa1cdbe626097c7fa310047edac7033f2ffe)
And also mention a few restrictions regarding legacy components
in Javadoc.
Issue: androidx/media#293
PiperOrigin-RevId: 522005562
(cherry picked from commit 502969a42b2ba07ada555a38841c7c65baeaa594)
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 219967c5a3ff8d8957a07e39c04ea27b657cab92)
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 e4cb583af2feb607ec5c2c201c22cbd661e454a8)
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 694d690bc03a34e112afc6cca58eb2761a25402a)
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 2e4f49fef741c21f47590d3a818b6ed43d94fc04)
`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 376bddef4720e07d18afeff0c591f03bf72149f7)
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 b9790e69d7649d3399b9b1f920aa417ba4cc38c1)
If RTSP Setup Request with UDP receives HTTP Error Status 461 UnsupportedTransport, then client will retry with TCP.
Issue: google/ExoPlayer#11069
PiperOrigin-RevId: 518807829
(cherry picked from commit ecf4d8b89193e8e3bb3ad3dbc9c7983fd26765ae)
Segment timelines are technically allowed to be empty, but not all places
add the necessary checks.
Issue: google/ExoPlayer#11014
PiperOrigin-RevId: 514722205
(cherry picked from commit 788132b9dc9f5dd9aa46f413b16f43433c9c7702)
The `@CallSuper` annotation should help catch cases where subclasses are
calling `delegate.addListener` instead of `super.addListener` but it
will also (unintentionally) prevent subclasses from either completely
no-opping the listener registration, or implementing it themselves in a
very custom way. I think that's probably OK, since these cases are
probably unusual, and they should be able to suppress the warning/error.
Issue: androidx/media#258
#minor-release
PiperOrigin-RevId: 513848402
(cherry picked from commit 5d23a92923324ecab338d14e865bcc26316aab00)
Also fixed the javadoc link in devsite and removed javadoc links from decoder extensions as it is not published yet on developer.android.com.
#minor-release
PiperOrigin-RevId: 520636868
(cherry picked from commit 6a928805d4b0f52f5f07b1f7cd75e2a7357e9397)
Custom commands from controller to session are blocked if they are
not listed in the available session command list. This isn't well
documented in the Javadoc currently.
#minor-release
PiperOrigin-RevId: 514733568
(cherry picked from commit 20669fca275554698c9176250005055b230485b3)
Dackka generates a warning if a method has at least one `@param` tag,
but not all of them are documented.
PiperOrigin-RevId: 513873453
(cherry picked from commit cb7d565fd47fc0b818ec0d5c7529e19df44022b5)
Once the value returned from AudioTimestampPoller advances, we
only need getPlaybackHeadPosition to sample sync params and
verify the returned timestamp. Both of these happen less often
and we can avoid calling getPlaybackHeadPosition if we don't
actually need it.
PiperOrigin-RevId: 512882170
(cherry picked from commit 408b4449ff75e29a9bda7adc1b530b993fc47814)
Playback parameter signalling can be quite complex because
(a) the renderer clock often has a delay before it realizes
that it doesn't support a previously set speed and
(b) the speed set on media clock sometimes intentionally
differs from the one surfaced to the user, e.g. during
live speed adjustment or when overriding ad playback
speed to 1.0f.
This change fixes two problems related to this signalling:
1. When resetting the media clock speed at a period transition,
we don't currently tell the renderers that this happened.
2. When a delayed speed change update from the media clock is
pending and the renderer for this media clock is disabled
before the change can be handled, the pending update becomes
stale but it still applied later and overrides any other valid
speed set in the meantime.
Both edge cases are also covered by extended or new player tests.
Issue: google/ExoPlayer#10882
PiperOrigin-RevId: 512658918
(cherry picked from commit e79b47ccff39363543c514937aef517a855994f0)
