SDK / exoplayer

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

PiperOrigin-RevId: 301996778

PiperOrigin-RevId: 301798563

This was missed in https://github.com/google/ExoPlayer/commit/f08eed4145613527c0a4907e035ba483db6df253

Part of issue:#6765

PiperOrigin-RevId: 301796232

Also add a couple of tests to enforce the documentation.

PiperOrigin-RevId: 301796102

Issue: #2159
PiperOrigin-RevId: 301705371

- This change also adds support for VideoFrameMetadataListener in the
  AV1 renderer
- This is a preliminary step prior to adding FfmpegVideoDecoder

Issue: #2159
PiperOrigin-RevId: 301702460

This is a necessary step for Decoder implementations to support
audio and video. MediaCodecRenderer.DecoderException is renamed
MediaCodecDecoderException and extends the new DecoderException

Issue: #2159
PiperOrigin-RevId: 301698238

We have two known scenarios where the app could create an OOM error and
we want to handle it gracefully:
 1. The app continues to allocate memory but doesn't make any progress
    in the buffered position. OOM should be prevented by the default
    load control and it should eventually throw an exception.
 2. An extractor tries to allocate a large amount of memory on the
    Loader thread based on information it read in faulty media files.
    In this case we should attempt to play remaining media and then
    throw an exception.

Both cases are already handled correctly, but we don't have any tests
ensuring that we don't introduce regressions.

PiperOrigin-RevId: 301585700

This removes a workaround that always continues buffering and instead
detects if the LoadControl returns false even though we don't have
any buffer. If enabled by a flag, this condition throws an exception.

PiperOrigin-RevId: 301584239