SDK / exoplayer

This was messed up by me in https://github.com/google/ExoPlayer/commit/a035c2e20a4ce25bd86774a870b5960bcfa6f0df

PiperOrigin-RevId: 303930392

PiperOrigin-RevId: 303829900

PiperOrigin-RevId: 303776645

PiperOrigin-RevId: 303764399

These are about 5% flaky, so for now they are excluded from
continuous testing.

PiperOrigin-RevId: 303760340

PiperOrigin-RevId: 303757995

PiperOrigin-RevId: 303753642

issue:#7160
PiperOrigin-RevId: 303747338

CharSequence is used by Notification builders and allows to set Spannable text.
It's the base interface of the String class, so apps wouldn't be break after
the update.

PiperOrigin-RevId: 303731890

PiperOrigin-RevId: 303719911

PiperOrigin-RevId: 303717642

This is required to align google3's stub (currently marked non-null) with Checker Framework's.

More information: go/matcher-nullness-lsc

Tested:
    TAP train for global presubmit queue
    http://test/OCL:303344687:BASE:303326748:1585344475427:29edc250
PiperOrigin-RevId: 303709053

PiperOrigin-RevId: 303655497

PiperOrigin-RevId: 303447837

Issue: #6671
PiperOrigin-RevId: 303364788

Issue: #7046
PiperOrigin-RevId: 303354941

- They are always listed with their canonical names
- Considering aliases means that blacklisting a decoder can end up
  not actually blacklisting it, since it may still be accessible
  via an alias. It also means that our decoder fallback logic can
  end up falling back to a decoder that we've already tried!

PiperOrigin-RevId: 303348297

Issue: #7141
PiperOrigin-RevId: 303334072

PiperOrigin-RevId: 303319078

This is just for consistency with our other renderers

PiperOrigin-RevId: 303317443

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