getCurrentTrackGroups and getCurrentTrackSelections are
retained for now, but moved from Player to ExoPlayer, to
ease the transition for some application code that currently
uses these methods.
PiperOrigin-RevId: 430036355
The track type is derived solely from the content. It does
not depend on any runtime properties such as the player's
capabilities of user track selection. Hence it belongs in
TrackGroup rather than TrackGroupInfo.
Note that this avoids TrackSelectionOverride from having to
re-derive the track type internally.
PiperOrigin-RevId: 429303312
We need TracksInfo.hasTracksOfType to determine which tabs to
display in TrackSelectionDialog.
We need TrackGroupInfo.isAdaptiveSupported to determine whether
to allow multiple selection (check boxes) or not (radio buttons).
PiperOrigin-RevId: 428793739
Currently only a single instance of ImaServerSideAdInsertionMediaSource is
supported at the same time in a playlist. This change makes sure that an
attempt to add multiple instances is prevented by throwing a an exception.
#minor-release
PiperOrigin-RevId: 428743140
This prevents a stack trace that is shown in the logs when the stream manager is
released after the activity was stopped. In this case the call to
`streamManager.destroy()` coming from `releaseSourceInternal()` of the media
source is too late and produces an error saying `Application attempted to call on
a destroyed WebView`. The error has no effect but it's nice to not have this
stack trace in the logs.
PiperOrigin-RevId: 428574231
The timeline used to map ad groups to periods needs to report the original content period duration without subtracting the serverside inserted ad duration. When marking played ads in onPositionDiscontinuity, the public timeline has been used which crashed the app when the ads media source is playing on a window index different to zero (in a playlist).
#minor-release
PiperOrigin-RevId: 428465833
Ignorable ad periods are skipped to resolve the media period id with the
ad playback state of the resulting period. In case of a change in the period
position un-played ad periods are rolled forward to be played.
PiperOrigin-RevId: 428011116
Right now, the option to build an IMA DAI URI programmatically is still
package-private. To simplify the process, we can remove the StreamRequest
wrapper and directly provide an URI builder.
The same class can provide some package-private helper methods to parse the
created URI.
#minor-release
PiperOrigin-RevId: 427445326
Allow opusV2JNI to be built-for & included-in non-Android build targets by ifdef'ing out the liblog dependency. Also removed libz and libandroid dependencies.
PiperOrigin-RevId: 427269838
This is a breaking change if the annotation itself is in use in Kotlin
code. It's judged that the IntDefs in this commit are unlikely to be
referred to often in Kotlin code. This is because they're either:
- Related to esoteric parts of the library, or
- In a common part of the library but only returned from methods (and
never passed to callback methods).
A follow-up change will fix the positions of existing usages to match
this new config.
#minor-release
PiperOrigin-RevId: 426410237
This only changes IntDefs that cannot be used by apps because they're
either private or package-private.
A follow-up change will fix the positions of existing usages to match
this new config.
#minor-release
PiperOrigin-RevId: 426372273
Remove most of the customisation documentation, since StyledPlayerView
isn't really designed to be customised as deeply as PlayerView.
Also remove most documentation around StyledPlayerControlView,
especially as a standalone controller class - since it doesn't work
well for this use-case.
#minor-release
PiperOrigin-RevId: 426090762
This makes sure the number of ads in an ad group matches to the number of periods representing an ad group in a multi-period timeline. This makes it easier to accurately mark ads as played in multi-period windows which is needed to correctly prevent seeking over unplayed ads.
PiperOrigin-RevId: 425317085
* @CryptoType is a TYPE_USE annotation, so should appear after modifiers and directly before the type.
(see go/java-style#s4.8.5-annotations)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle 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/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.
#codehealth
Tested:
Local presubmit tests passed.
PiperOrigin-RevId: 423821355
This change adds more standard metadata fields to Cast metadata including the artwork URL that makes the cast device show the artwork in the Cast route dialog (https://screenshot.googleplex.com/uj4n4Jqd7it9bob) and the Cast device.
This change also discriminates between media with an audio MIME type and others. For audio MIME type the Cast metadata is set to MEDIA_TYPE_MUSIC_TRACK which changes the layout and shows artwork and additional audio meta data to be displayed (https://screenshot.googleplex.com/ASy3KDcsTdJDM2T).
Issue: google/ExoPlayer#9663
PiperOrigin-RevId: 422589957
These were missed in 46ab94bd41
These references will be re-written to PlayerView when exporting to
exoplayer2, so this commit results in some small reformatting changes.
Also fix a reference to LegacyPlayerControlView that should be
StyledPlayerControlView.
PiperOrigin-RevId: 420707706
When sending a MediaItem to a MediaSession with a Media3 MediaController important information is removed for privacy reason. To look up the fully populated MediaItem the mediaId is used as a key. Hence having the mediaId marhalled to the JSON representation that is sent to a Cast device enables app developers to use the same look up facilities.
#minor-release
PiperOrigin-RevId: 420022868
Before this change we checked whether the playback state and playWhenReady have changed when the state from the cast device arrived. If we detected such a change we called the listener callback `onIsPlayingChanged`. However, in the case when `setPlayWhenReady(boolean)` is called on 'CastPlayer', we mask the change in `playWhenReady`, then send the play/pause request to the cast device and when the state from the cast device arrives we never detect a change because we have already masked `playWhenReady`.
This change now moves the check for `isPlaying` to the same place where the state and playWhenReady is updated, so we call the `onIsPlayingChanged` callback in either case, when masking or when a changed state from the server arrives.
Issue: google/ExoPlayer#9792
PiperOrigin-RevId: 418483509
This more closely matches the pattern we have for all implementations
except DefaultMediaSourceFactory (e.g. ProgressiveMediaSource.Factory)
and other factory interfaces like (Http)DataSource.Factory.
PiperOrigin-RevId: 417826803
