SDK / exoplayer

BasePlayer simplifies implementations by handling all the various
seek methods and forwarding to a single method that can then be
implemented by subclasses. However, this loses the information about
the concrete entry point used for seeking, which is relevant when
the subclass wants to verify or filter by Player.Command. This
can be improved by adding the command as a new parameter. Since
we have to change the method anyway, we can also incorporate the
boolean flag about whether the current item is repeated to avoid
the separate method.

PiperOrigin-RevId: 494948094
(cherry picked from commit ab6fc6a0)

Some Player methods like getting the Looper and adding listeners
were always allowed to be called from any thread, but this is
undocumented. This change makes the threading rules of these
methods more explicit.

Removing listeners was never meant to be called from another thread
and we also don't support it safely because final callbacks may
be triggered from the wrong thread. To find potential issues, we
can assert the correct thread when releasing listeners.

Finally, there is a potential race condition when calling addListener
from a different thread at the same time as release, which may lead to
a registered listener that could receive callbacks after the player is
released.

PiperOrigin-RevId: 493843981
(cherry picked from commit 927b2d6a)

It looks like this was added accidentally in <unknown commit>.

PiperOrigin-RevId: 493834134
(cherry picked from commit 533f5288)

The folder type has a mix of information about the item. It shows
whether the item is browsable (type != FOLDER_TYPE_NONE) and
which Bluetooth folder type to set for legacy session information.

It's a lot clearer to split this into a boolean isBrowsable and
use the existing mediaType to map back to the bluetooth folder type
where required.

folderType is not marked as deprecated yet as this would be an API
change, which will be done later.

PiperOrigin-RevId: 493544589
(cherry picked from commit ae8000ae)

This adds support for the release handling. To align with the
established behavior in ExoPlayer, the player can only call
listeners from within the release methods (and not afterwards)
and automatically enforces an IDLE state (without listener call)
in case getters of the player are used after release.

PiperOrigin-RevId: 493543958
(cherry picked from commit 4895bc42)

Fix some other link titles and destinations spotted along the way.

#minor-release

PiperOrigin-RevId: 493276172
(cherry picked from commit 636a4a85)

The callback is currently triggered on the ExoPlayer playback thread
instead of the app thread that added the listener.

PiperOrigin-RevId: 492474405
(cherry picked from commit 634c6161)

This inconsistency was exposed by an upcoming change to deprecate
`POSITION_UNSET` in favour of `INDEX_UNSET` because position is an
ambiguous term between 'byte offset' and 'media position', as shown
here.

PiperOrigin-RevId: 492470241
(cherry picked from commit 2650654d)

Discovered while investigating Issue: google/ExoPlayer#10823

Example stack trace with the previous code (I added the index value for
debugging):

```
playerFailed [eventTime=44.07, mediaPos=44.01, window=0, period=0, errorCode=ERROR_CODE_FAILED_RUNTIME_CHECK
  androidx.media3.exoplayer.ExoPlaybackException: Unexpected runtime error
      at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:635)
      at android.os.Handler.dispatchMessage(Handler.java:102)
      at android.os.Looper.loopOnce(Looper.java:202)
      at android.os.Looper.loop(Looper.java:291)
      at android.os.HandlerThread.run(HandlerThread.java:67)
  Caused by: java.lang.IllegalArgumentException: index=-1
      at androidx.media3.common.util.Assertions.checkArgument(Assertions.java:55)
      at androidx.media3.extractor.text.webvtt.WebvttSubtitle.getEventTime(WebvttSubtitle.java:62)
      at androidx.media3.extractor.text.SubtitleOutputBuffer.getEventTime(SubtitleOutputBuffer.java:56)
      at androidx.media3.exoplayer.text.TextRenderer.getCurrentEventTimeUs(TextRenderer.java:435)
      at androidx.media3.exoplayer.text.TextRenderer.render(TextRenderer.java:268)
      at androidx.media3.exoplayer.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:1008)
      at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:509)
      at android.os.Handler.dispatchMessage(Handler.java:102)
      at android.os.Looper.loopOnce(Looper.java:202)
      at android.os.Looper.loop(Looper.java:291)
      at android.os.HandlerThread.run(HandlerThread.java:67)
]
```

#minor-release

PiperOrigin-RevId: 492464180
(cherry picked from commit 33bbb951)

PiperOrigin-RevId: 492443147
(cherry picked from commit 2fd38e39)

When app is deployed with device's screen being off, MainActivity's onStart is called swiftly by its onStop. The onStop method cancels the browserFuture task which in turn "completes" the task. Upon task "completion", pushRoot() runs and then throws error as it calls get() a cancelled task.

PiperOrigin-RevId: 492416445
(cherry picked from commit 64603cba)

This allows legacy media controllers and browsers to access this
information and legacy sessions and browser services to set this
information.

PiperOrigin-RevId: 492414716
(cherry picked from commit ca4c6efd)

If the service ever has been started but is not in the foreground, the
service would be terminated without calling onDestroy(). This is because
when onStartCommand returns START_STICKY [1], the app takes the
responsibility to stop the service.

Note that this change interrupts the user journey when paused, because the
notification is removed. Apps can implement playback resumption [2] to give
the user an option to resume playback after the service has been terminated.

[1] https://developer.android.com/reference/android/app/Service#START_STICKY
[2] https://developer.android.com/guide/topics/media/media-controls#supporting_playback_resumption

Issue: androidx/media#175
#minor-release
PiperOrigin-RevId: 492192690
(cherry picked from commit 6a5ac191)

Do not log the exception stack traces raised by the BitmapLoader when a
bitmap fails to load, e.g. when the artwork's URI scheme is not
supported by the SimpleBitmapLoader. The logs are kept in place but only
a single line is printed.

#minor-release

PiperOrigin-RevId: 492191461
(cherry picked from commit f768ff97)

In some cases we split a test method, and in other cases we just add
line breaks to make the separation between arrange/act/assert more
clear.

PiperOrigin-RevId: 492182769
(cherry picked from commit e4fb663b)

PiperOrigin-RevId: 492164739
(cherry picked from commit a9191418)

This adds the forwarding logic for most setters in SimpleExoPlayer
in the same style as the existing logic for setPlayWhenReady.

This change doesn't implement the setters for modifying media items,
seeking and releasing yet as they require additional handling that
goes beyond the repeated implementation pattern in this change.

PiperOrigin-RevId: 492124399
(cherry picked from commit f0072387)

This helps to denote what type of content or folder the metadata
describes.

PiperOrigin-RevId: 492123690
(cherry picked from commit 32fafefa)

PiperOrigin-RevId: 492003800
(cherry picked from commit c7aa54cb)

This CL makes it possible to create a media3 ControllerInfo in test code, which is needed to test several aspects of a media3-based media app. It does this by exposing a test-only static factory method. This is a hacky low-effort approach; a better solution could be to split ControllerInfo up into a public interface that was exposed to client logic, and that they could extend, and a package-private implementation with internal fields like the callback. That's a much bigger change, however.

PiperOrigin-RevId: 491978830
(cherry picked from commit 69093db7)

This better matches the terminology we use elsewhere in the Player
interface, where items inside the playlist are referred to as
"media item" and only the entire list is called "playlist".

PiperOrigin-RevId: 491882849
(cherry picked from commit ff7fe222)

The Bluetooth AVRCP service expects the metadata of the item currently
being played to be in sync with the corresponding media description in
the active item of the queue. The comparison expects the metadata values
of `METADATA_KEY_TITLE` and `METADATA_KEY_ARTIST` [1] to be equal to the
`title` and `subtitle` field of the `MediaDescription` [2] of the
corresponding queue item.

Hence we need to populate the media description accordingly to avoid the
BT service to delay the update for two seconds and log an exception.

[1] https://cs.android.com/android/platform/superproject/+/master:packages/modules/Bluetooth/android/app/src/com/android/bluetooth/audio_util/helpers/Metadata.java;l=120
[2] https://cs.android.com/android/platform/superproject/+/master:packages/modules/Bluetooth/android/app/src/com/android/bluetooth/audio_util/MediaPlayerWrapper.java;l=258

Issue: androidx/media#148
PiperOrigin-RevId: 491877806
(cherry picked from commit 2a07a0b4)

Issue: androidx/media#213

Without a public constructor, it is not possible to extend this class and override its method.

PiperOrigin-RevId: 491673111
(cherry picked from commit f3e450e7)

Use the bitrate of the audio format (when available) in
DefaultAudioSink.AudioTrackBufferSizeProvider.getBufferSizeInBytes() to
calculate accurate buffer sizes for direct (passthrough) playbacks.

#minor-release

PiperOrigin-RevId: 491628530
(cherry picked from commit d12afe05)

To support OPUS offload, we need to provide a few configuration values
that are currently not set due to the lack of devices supporting
OPUS offload.

PiperOrigin-RevId: 491613716
(cherry picked from commit 568fa1e1)

The fix for b/171657375 (internal) has been shipped with 21.1.0 already
(see https://developers.google.com/cast/docs/release-notes#august-8,-2022).

PiperOrigin-RevId: 491583727
(cherry picked from commit 835d3c89)

PiperOrigin-RevId: 491336828
(cherry picked from commit 3581ccde)

The list of charsets is already hard-coded, and using `Charset` types
ensures they will all be present at run-time, hence we will never
encounter an 'unsupported' charset.

PiperOrigin-RevId: 491324466
(cherry picked from commit 5292e408)

It's clearer if each test method follows the Arrange/Act/Assert pattern

PiperOrigin-RevId: 491299379
(cherry picked from commit fc5d1783)

PiperOrigin-RevId: 491289028
(cherry picked from commit b81d5f30)

FakeClock keeps an internal list of messages to be executed to
ensure deterministic serialization. The next message from the list
is triggered by a separate helper message sent to the real Handler.
However, if the target HandlerThread is no longer alive (e.g. when
it quit itself during the message execution), this helper
message is never executed and the entire message execution chain
is stuck forever.

This can be solved by checking the return values of Hander.post or
Handler.sendMessage, which are false if the message won't be
delivered. If the messages are not delivered, we can unblock the
chain by marking the message as complete and triggering the next
one.

PiperOrigin-RevId: 491275031
(cherry picked from commit 8fcc0630)

Remove self-links, and remove section that is documenting internal
ordering behaviour of
[`SimpleBasePlayer.getCombinedMediaMetadata`](https://github.com/google/ExoPlayer/blob/bb270c62cf2f7a1570fe22f87bb348a2d5e94dcf/library/common/src/main/java/com/google/android/exoplayer2/SimpleBasePlayer.java#L1770)
rather than anything specifically about this method.

#minor-release

PiperOrigin-RevId: 490923719
(cherry picked from commit a6703285)

Our FakeClock generally makes sure that playback tests are fully
deterministic. However, this fails if the test uses blocking waits
with clock.onThreadBlocked and where relevant Handlers are created
without using the clock.

To fix the flakiness, we can make the following adjustments:
 - Use TestExoPlayerBuilder instead of legacy ExoPlayerTestRunner
   to avoid onThreadBlocked calls. This also makes the tests more
   readable.
 - Use clock to create Handler for FakeVideoRenderer and
   FakeAudioRenderer. Ideally, this should be passed through
   RenderersFactory, but it's too disruptive given this is a
   public API.
 - Use clock for MediaSourceList and MediaPeriodQueue update
   handler.

PiperOrigin-RevId: 490907495
(cherry picked from commit 6abc94a8)

Format expects the values of `averageBitrate` and `peakBitrate` in bps and the value fetched from AC3SpecificBox and EC3SpecificBox is in kbps.

PiperOrigin-RevId: 490756581
(cherry picked from commit 4066970c)

To avoid complicated bit shifting and masking. Also makes the code more readable.

PiperOrigin-RevId: 490749482
(cherry picked from commit 3d31e094)

*** Original commit ***

Rollback of https://github.com/androidx/media/commit/76df06a7a364c580dfe07d9f069237cd77c5174c

*** Original commit ***

Parse and set `peakBitrate` for Dolby TrueHD(AC-3) and (E-)AC-3

#minor-release

***

***

PiperOrigin-RevId: 490707234
(cherry picked from commit 82711630)

*** Original commit ***

Parse and set `peakBitrate` for Dolby TrueHD(AC-3) and (E-)AC-3

#minor-release

***

PiperOrigin-RevId: 490570517
(cherry picked from commit 42732917)

#minor-release

PiperOrigin-RevId: 490527831
(cherry picked from commit 76df06a7)

Before this change, the bitmap loading result with mainHandler, in which we set the metadata to `MediaSessionCompat`. However, the `MediaSessionCompat` is not thread safe, all calls should be made from the same thread. In the other calls to `MediaSessionCompat`, we ensure that they are on the application thread (which may be or may not be main thread), so we should do the same for `setMetadata` when bitmap arrives.

Also removes a comment in `DefaultMediaNotificationProvider` as bitmap request caching is already moved to CacheBitmapLoader.

PiperOrigin-RevId: 490524209
(cherry picked from commit 80927260)

Issue: androidx/media#209

#minor-release

PiperOrigin-RevId: 490492223
(cherry picked from commit 2424ee77)