In some DataSources, it is not easy to assign an error code at the throw site.
For example, CronetDataSource.readInternal() throws SocketTimeoutException
on L1033, and is caught at L754 as IOException and is thrown.
We need the logic to assign error code for the actual type of the error cause.
While we can certainly do in individual DataSources, IMO there's value in
making this logic generic at a higher level (like what is in this CL).
The catch and translation logic is borrowed from EPII:L646.
PiperOrigin-RevId: 385789629
Before this fix, if DefaultDrmSessionManager.release() was called while
there was at least one 'external' session reference still active (i.e.
session.referenceCount > 1) then the manager will release it's reference
immediately but when the session's reference count subsequently drops to
1 (due to external references being released) the manager will schedule
a task to release its internal reference *again*.
This change fixes the problem by only scheduling the timed release if
the manager is unreleased. This ensures that the internal references
are only released once.
Issue: #9193
#minor-release
PiperOrigin-RevId: 385580741
* Constructors and methods with the same name should appear sequentially with no other code in between, even when modifiers such as static or private differ between the methods. Please re-order or re-name methods.
(see http://go/bugpattern/UngroupedOverloads)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* 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
PiperOrigin-RevId: 384877648
Also rename hasPrevious/Next to hasPrevious/NextWindow for consistency.
This makes it clearer what the difference between
seekToPrevious/NextWindow and seekToPrevious/Next is.
PiperOrigin-RevId: 384643373
The types (open/close/read) does not provide extra information about the thrown
playback exception, and they are not utilized at higher levels.
PiperOrigin-RevId: 384219870
The parameters staying in DefaultTrackSelector are considered
too ExoPlayer specific to be part of the `Player` interface.
Those are:
- exceedVideoConstraintsIfNecessary;
- allowVideoMixedMimeTypeAdaptiveness;
- allowVideoNonSeamlessAdaptiveness;
- exceedAudioConstraintsIfNecessary;
- allowAudioMixedMimeTypeAdaptiveness;
- allowAudioMixedSampleRateAdaptiveness;
- allowAudioMixedChannelCountAdaptiveness;
- disabledTextTrackSelectionFlags;
- exceedRendererCapabilitiesIfNecessary;
- tunnelingEnabled;
- allowMultipleAdaptiveSelections;
- rendererDisabledFlags
Track selection override will be migrated in a follow up cl.
To avoid breaking backward compatibility,
`DefaultTrackSelector.Parameters` extends
`TrackSelectionParameters` and
`DefaultTrackSelector.ParametersBuilder` extends `TrackSelectionParameters.Builder`.
The change are thus transparent for clients.
Test are incomplete for now, as this is a relatively big cl, I though
the reviewer could give a first pass will the tests are completed.
PiperOrigin-RevId: 383767021
In order to avoid doing the classification in ExoPlayerImplInternal. Note:
This only makes the constructor change. The error code assignment will
happen in an immediately following CL.
PiperOrigin-RevId: 383397729
MediaItem.mediaId used to default to the content URI, but this changed:
cc26a92e07
Before the mediaId change linked above, a playlist of different content
all with the same ad URI would play the ads for every item. After the
change the ad would only play once (because mediaId == "" for every
item, so they're all the same). This change restores roughly the
original behaviour by always considering both mediaId and the content
URI.
#minor-release
Issue: #9106
PiperOrigin-RevId: 382763618
Without this annotation it seems that `SimpleExoPlayer` effectively
'un-deprecates' the method, specifically:
* A usage of these methods isn't flagged by Android Studio if the
declared type is `SimpleExoPlayer` (up-casting to e.g.
`ExoPlayer.VideoComponent` results in the warning showing up).
* The `SimpleExoPlayer` javadoc doesn't mention this method is
deprecated:
https://exoplayer.dev/doc/reference/com/google/android/exoplayer2/SimpleExoPlayer.html#addVideoListener(com.google.android.exoplayer2.video.VideoListener)
* The Metalava API output for `SimpleExoPlayer` doesn't show these
methods as deprecated.
PiperOrigin-RevId: 382756174
- Use `PlaybackException.ErrorCode` IntDef for `DataSourceException` error code
- Deprecate `DataSourceException.POSITION_OUT_OF_RANGE`
- All other changes are related to replacing the deprecated constant and
constructor
PiperOrigin-RevId: 382683522
