SDK / exoplayer

PiperOrigin-RevId: 303316976

This callback will be deprecated, so moving all usages to better callbacks.
Some usages are still remaining that are less straight-forward to update.

PiperOrigin-RevId: 303298834

PiperOrigin-RevId: 303298804

OnSeekProcessed is documented to be called as soon as all neccessary state changes
as a result of the seek have been made. As we now mask the state changes directly
when calling seekTo, we can also call this callback immediately without changing
the semantics of the method.

Our tests often use this callback as a way to wait for the internal player
to receive all pending commands and then report back. This is a special test
requirement for cases where we want to make sure no further updates happen as
a result of the player handling commands. To facilitate that, a new action is
added with a more descriptive name that achieves the same goal.

PiperOrigin-RevId: 303296210

PiperOrigin-RevId: 303286872

PiperOrigin-RevId: 303283147

PiperOrigin-RevId: 303217607

PiperOrigin-RevId: 303170259

issue:#7122
PiperOrigin-RevId: 303154493

Also document FrameworkMediaDrm overrides as dependent on API level.

These two methods call through to equivalent methods on MediaDrm that
were added in 23:
https://developer.android.com/reference/android/media/MediaDrm#setOnExpirationUpdateListener(java.util.concurrent.Executor,%20android.media.MediaDrm.OnExpirationUpdateListener)

PiperOrigin-RevId: 303102370

It looks like the video path will use a separate FfmpegVideoDecoder

Issue: #2159
PiperOrigin-RevId: 303068617

Defines a new no_native_gvr build rule in ExoPlayerV2 that doesn't depend on the shared object in the VR sdk.

PiperOrigin-RevId: 302945930

This moves the playlist API methods to the Player interface. Implementation is moved from ExoPlayerImpl to BasePlayer where possible.

Further the CastPlayer is changed to implement the Player interface. Proper migration of the Playermanager to not use the ConcatenatingMediaSource anymore follows in a separate, future CL.

PiperOrigin-RevId: 302937779

Most of these are no longer needed since https://github.com/google/ExoPlayer/commit/aa9eb5abc9b2b121db52d436215f40805928599c

Cleanup change automatically generated by error-prone refactoring
//java/com/google/devtools/staticanalysis/errorprone:UnnecessaryJavacSuppressWarnings_refactoring on targets third_party/java_src/android_libs/exoplayer/v2/... java/com/google/android/libraries/exoplayer/v2/...

PiperOrigin-RevId: 302916092

Add some mitigation about why this is probably on OK limitation.

PiperOrigin-RevId: 302907940

This is less confusing than having audio processing functionality (e.g., playback
speed adjustment) just "not work" for some pieces of media.

If this change is merged, I will update #6749 to also track making DefaultAudioSink
intelligently enable/disable float output depending on how the audio processors are
configured.

Issue: #7134
PiperOrigin-RevId: 302871568

PiperOrigin-RevId: 302856370

We currently have multiple places in ExoPlayerImpl that assign PlaybackInfo
instances and then inform listeners of all current changes. This is not ideal
because it causes multiple issues:
 1. Some changes may easily be forgotten, e.g. there are clearly some checks
    missing to see if isPlaying changed (e.g. in seekTo or setMediaSources)
 2. Some callbacks didn't check if the value actually changed before sending
    the callback (e.g. for the timeline change in setMediaSources - if the
    timeline is still the same, we shouldn't send a onTimelineChanged event).
 3. Having multiple callbacks in a single Runnable changes the order of
    listener invocations slightly: Currently all events for one listener will
    be send first before moving to the next listener. It should however send
    a single event to all listeners first before moving to the next event.

All these issues can be solved by always using updatePlaybackInfo and never
assigning playbackInfo directly in another place.

Some tests needed to be updated as well because of issues (2) and (3). Also
added a new test to cover issue (1).

PiperOrigin-RevId: 302844981

Update Activity and fragment libraries from aosp-androidx-master-dev with build id #6325864(2020-03-23) to google3

LSC doc: go/android-sdk-lsc , go/androidx-lsc

Global presubmit: https://tap.corp.google.com/ui#id=OCL:300623192:BASE:302596264:1585028366422:76f628fd

PiperOrigin-RevId: 302749181

PiperOrigin-RevId: 302684221

It's incorrect to use an AudioFormat returned from AudioProcessor.configure
unless the AudioProcessor is active.

Issue: #7134
PiperOrigin-RevId: 302674132

This is a no-op for DefaultAudioSink for now, because DefaultAudioSink
currently disables processing anyway if the input uses ENCODING_PCM_FLOAT.

Issue: #7134
PiperOrigin-RevId: 302670534

Issue: #7129
PiperOrigin-RevId: 302660343

PiperOrigin-RevId: 302659142

PiperOrigin-RevId: 302646400

The playback state will be immediately set to the most likely final state.

PiperOrigin-RevId: 302645852

androidTest of core already has the dependency on its main. Without this
exclude, gradle complains about type duplication when merging dex saying
"Type X is defined multiple times".

PiperOrigin-RevId: 302641585

If the start time of the edit falls within a sample, start from that
sample rather than the next one. This ensures playback can start from
the correct point if the sample is a keyframe, rather than having to
start from the next one.

Issue: #7133
PiperOrigin-RevId: 302639115

PiperOrigin-RevId: 302619179

PiperOrigin-RevId: 302474924

Add a test for this case, and extend the existing tests to ensure the
hour is parsed when it's present.

issue:#7122
PiperOrigin-RevId: 302472213

PiperOrigin-RevId: 302446077

- Show renderers with no tracks in EventLogger track logging
- Log renderer names in EventLogger track logging
- Add useful message to ExoPlaybackException instances (including
  renderer name for renderer errors)

PiperOrigin-RevId: 302421616

Remove add/removeEventListener methods & associated listener plumbing.

Part of issue:#6765

PiperOrigin-RevId: 302411347

#exo-offload

PiperOrigin-RevId: 302403507

If MaskingMediaSource masks a multi-window media source, it may be that a period
is removed while we are using an initial unprepared masking MediaPeriod. That
means it's not guaranteed that a timeline update still contains our
unpreparedMaskingMediaPeriod and we should ignore timeline updates where the
period is no longer present because the it will be removed anyway.

PiperOrigin-RevId: 302383787

PiperOrigin-RevId: 302345647

Gradle produces build warnings without this dependency.

PiperOrigin-RevId: 302045675

- Make sure logging of UnknownHostException indicates the failure reason
- Indent stack traces inside event blocks in EventLogger
- Don't log media URLs

PiperOrigin-RevId: 302007601

These methods document themselves only by referencing the Android's
MediaDrm, which explicitly accepts null [1]. The implementation in
FrameworkMediaDrm also handles nulls.

[1] https://developer.android.com/reference/android/media/MediaDrm#setOnEventListener(android.media.MediaDrm.OnEventListener)

PiperOrigin-RevId: 302007441