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 ca4c6efdb7fdb50cef116d26360b79ed75a6401e)
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 6a5ac19140253e7e78ea65745914b0746e527058)
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 f768ff970ca15483bcb02c1cf41746b67ec8c3ac)
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 e4fb663b23e38eb6e41b742681bf80b872baad24)
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 f007238745850791f8521e61f6adaf8ed2467c45)
This helps to denote what type of content or folder the metadata
describes.
PiperOrigin-RevId: 492123690
(cherry picked from commit 32fafefae81e0ab6d3769152e584981c1a62fc60)
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 69093db7f5889037a3b55e3d1a7242c31ce62f2f)
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 ff7fe222b83c55c93cc9ee1a3763a11473168ece)
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 f3e450e7833bbc62237c1f24f9a1f6c4eed21460)
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 d12afe0596b11c473b242d6389bc7c538a988238)
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 568fa1e1fa479fd1659abf1d83d71e01227ab9cf)
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 5292e408a6fd000c1a125519e22a7c18460eed59)
It's clearer if each test method follows the Arrange/Act/Assert pattern
PiperOrigin-RevId: 491299379
(cherry picked from commit fc5d17832f90f36eb30ee0058204d110e27adcc9)
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 8fcc06309323847b47ed8ab225cd861335448d36)
Remove self-links, and remove section that is documenting internal
ordering behaviour of
[`SimpleBasePlayer.getCombinedMediaMetadata`](bb270c62cf/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 a6703285d0d1bedd946a8477cb68c46b1a097b09)
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 6abc94a8b7180979c520fc581310b87bf297b1bb)
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 4066970ce7292642794f4a3954f8d0fde78dd310)
To avoid complicated bit shifting and masking. Also makes the code more readable.
PiperOrigin-RevId: 490749482
(cherry picked from commit 3d31e094a9e802354dce2f3dc5f33062f7624248)
*** Original commit ***
Rollback of 76df06a7a3
*** Original commit ***
Parse and set `peakBitrate` for Dolby TrueHD(AC-3) and (E-)AC-3
#minor-release
***
***
PiperOrigin-RevId: 490707234
(cherry picked from commit 82711630ed1afbe7417aad95244a91135e24c27f)
*** Original commit ***
Parse and set `peakBitrate` for Dolby TrueHD(AC-3) and (E-)AC-3
#minor-release
***
PiperOrigin-RevId: 490570517
(cherry picked from commit 427329175e87a7f3173791c59e6c2d4c4ed8dea4)
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 80927260fd46413b7d1efafed72360b10049af2a)
This change includes a change in the `IMediaController.aidl` file and needs
to provide backwards compatibility for when a client connects that is of an older or
newer version of the current service implementation.
This CL proposes to create a new AIDL method `onPlayerInfoChangedWithExtensions`
that is easier to extend in the future because it does use an `Bundle` rather than
primitives. A `Bundle` can be changed in a backward/forwards compatible way
in case we need further changes.
The compatibility handling is provided in `MediaSessionStub` and `MediaControllerStub`. The approach is not based on specific AIDL/Binder features but implemented fully in application code.
Issue: androidx/media#102
#minor-release
PiperOrigin-RevId: 490483068
(cherry picked from commit 3d8c52f28d5d3ef04c14868e15036563a9fc662d)
The direct executor is not the proper way to determine on what thread to run the
`Future.Listener` and the `MediaControllerCreationListener` because the listener
may call the controller passed as argument which must happen on the same thread
that built the controller. This change makes sure this is the case.
PiperOrigin-RevId: 490478587
(cherry picked from commit 68908be18d0a46478be05ad406a5027c15c38723)
This avoids that apps have to depend on the legacy compat support
library when they want to make this conversion.
Also add a version to both helper methods that takes a Looper to
give apps the option to use an existing Looper, which should be
much faster than spinning up a new thread for every method call.
Issue: androidx/media#171
PiperOrigin-RevId: 490441913
(cherry picked from commit 03f0b53cf823bb4878f884c055b550b52b9b57ab)
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 2f8cf947c71db6be9459492117fe95b1a8bc7178)
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 5f6fde4d2a90d78a8d58430c88d7dc12849fe163)
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 02fa8aa784b518f0ffad5c44da6eec1a94def4ee)
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 e598a17b3628e1179fa4219ca3212407fb3fdeb1)
This helps to denote what type of content or folder the metadata
describes.
PiperOrigin-RevId: 492123690
(cherry picked from commit 1ac72de551a07d37c3b80d96028463244407a5b4)
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 6c467590d0fdc27dd5afeefe479c3d4414483de5)
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 e219ac21ae604f182769d69f6f590191a92100d0)
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 4cf877b81428021c4eb2dfa1a743178f280aceb5)
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 043546a03475356764cf8b754bd0fff87a0c6e1a)
It's clearer if each test method follows the Arrange/Act/Assert pattern
PiperOrigin-RevId: 491299379
(cherry picked from commit bf77290fbe78aa25698c1a7082b2a18cd7f1b06c)
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 2977bef872d7f3a1611fd6e8a45931388ea21c9f)
