SDK / exoplayer

PiperOrigin-RevId: 356479682

PiperOrigin-RevId: 356474350

This parameterized test execute a single playback with a variety of
specified network conditions, user country and network types, and then
compares some basic ABR performance data against a dump file to detect
changes.

PiperOrigin-RevId: 356468304

ControlDispatcher and DefaultControlDispatcher also need
to move to common for the UI module. As does PlaybackPreparer,
although that will be removed entirely in a future release.

PiperOrigin-RevId: 356467394

PiperOrigin-RevId: 356456843

Also allow the player's prepared ad media period durations array to exceed the
length of the loaded ad URIs array, as it's possible for the player to buffer
an ad media period fully at the point where it's known that an ad is coming up
but its URI is still unknown.

#minor-release

PiperOrigin-RevId: 356249284

This may happen for HLS live streams without program date time
information.

Issue: #8560

#minor-release

PiperOrigin-RevId: 356227729

#minor-release

PiperOrigin-RevId: 356221487

PiperOrigin-RevId: 356157035

PiperOrigin-RevId: 355896218

We currently block the loading thread until the calculated load
time has past and then unblock again by a message sent from the
playback thread. However, because the loading thread itself is not
using a Looper and runs freely, we don't control when the short
calculations on the loader thread that determine how long we have
to wait are happening, and we also don't control how long it takes
to start and stop this thread.

To solve these problems and to make the playback deterministic we
can
 1. Send a message on the playback thread to block until the loader
    thread has started.
 2. Block the playback thread whenever a loading thread is doing its
    short calculation of wait times. The playback thread knows when it
    can continue because loading either enter a new waiting state for
    a simulated load time or loading is finished completely.
 3. Also wait on the playback thread until the loader has shut down.
    As this is waiting for a message on the playback thread, we can
    achieve this by sending messages to ourselves at the current time
    until the loader is shut down.
All 3 steps together ensure that the loading thread interaction is
compeltely deterministic when simulating bandwidth profiles with the
BandwidthProfileDataSource. As we need to notify the source before and
after the load started/finished, we also need a small wrapper for the
chunk source when running the playback.

PiperOrigin-RevId: 355810408

PiperOrigin-RevId: 355664280

PiperOrigin-RevId: 355659628

The current naming had cause confusinon in b/179369346
and #8545.

PiperOrigin-RevId: 355656404

#minor-release

PiperOrigin-RevId: 355652144

- When throwing a recoverable error from a renderer, it's important to understand
  exactly how the player will attempt recovery. Clarify the documentation to
  make this explicit.
- Rename some methods/constants to make it clear that error recovery is specific
  to renderer errors. The current recovery mechanism only makes sense for
  renderer errors. Making the naming renderer specific avoids reader doubt that
  the implementation doesn't appear to be generic enough for other types of
  errors.

PiperOrigin-RevId: 355650945

PiperOrigin-RevId: 355621265

It's for classes to clearly denote they support bundling and it gives
us a good place to document the best practice to implement fromBundle.

PiperOrigin-RevId: 355609942

Before, the level was set to null in this case.
MediaCodecUtil.getCodecProfileAndLevel() was therefore returning null
and the fallback to AVC/HEVC was not enabled in MediaCodecVideoRenderer.

Issue:#8530
#minor-release
PiperOrigin-RevId: 355574499

PiperOrigin-RevId: 355508621

In both cases it's deliberate that all excluded constants should use
the default branch. Furthermore, there are quite a lot of excluded
constants missing, so it's probably better to suppress the warning
than to include them all.

#minor-release

PiperOrigin-RevId: 355426749

This resolves the following constraint resolution issue when running our release script:

> Cannot find a version of 'org.chromium.net:cronet-api' that satisfies the version constraints:
    Dependency path 'com.google.android.exoplayer:extension-cronet:unspecified' --> 'com.google.android.gms:play-services-cronet:17.0.0' --> 'org.chromium.net:cronet-api:72.3626.96'
    Constraint path 'com.google.android.exoplayer:extension-cronet:unspecified' --> 'org.chromium.net:cronet-api:{strictly 72.3626.96}' because of the following reason: debugRuntimeClasspath uses version 72.3626.96
    Dependency path 'com.google.android.exoplayer:extension-cronet:unspecified' --> 'org.chromium.net:cronet-embedded:76.3809.111' --> 'org.chromium.net:cronet-common:76.3809.111' --> 'org.chromium.net:cronet-api:76.3809.111'

#minor-release

PiperOrigin-RevId: 355414968

Issue: #8427
PiperOrigin-RevId: 355381785

#minor-release

PiperOrigin-RevId: 355381610

This is a more targeted workaround, which still allows for the
containing package name to be obfuscated.

#minor-release

PiperOrigin-RevId: 355381201

PiperOrigin-RevId: 355356169

#minor-release

PiperOrigin-RevId: 355203044

* Move cherrypicked changes from dev-v2 to 2.13.0
* Use a bulleted list instead of comma-separated.
* Standardise everything into present, imperative sentences.
* Remove a couple of mixed-font words (I left cases with a separating
  apostrophe, as these seemed visually clearer).
* Merge multiple issue links into a single set of parentheses.

#minor-release

PiperOrigin-RevId: 355180143

#minor-release

PiperOrigin-RevId: 355159635

Note: We only support pro-guard on a best effort basis,
and developers should use R8 whenever possible.

#minor-release

PiperOrigin-RevId: 355129695

Main improvement is to switch away from ExoPlayerTestRunner and to
split out the waiting component so that the same class can be used
from Robolectric tests in the future.

The only functional difference is that that BufferLengthLogAction
is removed completely because the data isn't used downstream and the
method of collecting this data is a bit arbitrary.

PiperOrigin-RevId: 355117850

#minor-release

PiperOrigin-RevId: 354949992

#minor-release

PiperOrigin-RevId: 354938190

Without this no error is currently logged or propagated to EventLogger.
The propagation doesn't happen because
MergingMediaSource.ForwardingEventListener only propagates events
originating from the "main" source in the merge:
<unknown commit>

#minor-release

PiperOrigin-RevId: 354902467

We can dequeue as part of getting output buffers (or output buffer info) in
`MediaCodecAdapterWrapper`, which simplifies the caller slightly.

Also try to make minor clarifications in method naming in
`TransformerAudioRenderer`.

#minor-release

PiperOrigin-RevId: 354890796

The caller knows whether it's queued end-of-stream, so we can remove the return
value of the method.

#minor-release

PiperOrigin-RevId: 354888298

This also moves DefaultHttpDataSource to common, which seems
sensible, else non-player components that need a DataSource
don't have any useful concrete implementations. We should
think about moving some of the other concrete implementations
to common as well.

PiperOrigin-RevId: 354738925

This is needed to move it to common, since we don't want to start
adding any nullness exemptions for the common module.

PiperOrigin-RevId: 354734715