SDK / exoplayer

When ClippingMediaPeriod first tried to read a buffer, if its end
position was before the end of the stream and it was buffered to its end
position, it would sometimes erroneously signal end-of-stream for
protected content because the sample queue might be waiting for DRM keys
at this point.

Work around the issue temporarily by signaling this specific case back
to ClippingMediaPeriod via the DecoderInputBuffer.

There will likely be a cleaner fix as a result of adding support for
dynamic clip end points in the future, at which point this can be
reverted.

issue:#7188
PiperOrigin-RevId: 305081757

PiperOrigin-RevId: 305037428

PiperOrigin-RevId: 305006564

PiperOrigin-RevId: 304986313

PiperOrigin-RevId: 304795753

In particular, replace @SuppressWarnings("initialization") with
@SuppressWarnings("nullness"); see
https://github.com/typetools/checker-framework/issues/3212.

More information: go/checker-lsc

Tested:
    TAP train for global presubmit queue
    http://test/OCL:304697666:BASE:304680497:1585968008044:f0c4fd6c
PiperOrigin-RevId: 304751415

This should have been done before, I just missed it.

PiperOrigin-RevId: 304612519

This is supported (despite what my now-deleted comment says), see the
example here:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/rt

PiperOrigin-RevId: 304612099

PiperOrigin-RevId: 304420177

PiperOrigin-RevId: 304386857

PiperOrigin-RevId: 304356504

The attempt in <unknown commit> was hacky and incomplete.

PiperOrigin-RevId: 304356038

PiperOrigin-RevId: 304355717

It's interesting WebVTT explicitly handles line & position differently
in horizontal-rl/lr and vertical-lr/rl contexts. position is always
measured from the left of the viewport, even for rtl text, but line in
vertical-rl is measured from the right of the viewport.

We don't have to make Cue match WebVTT (I can go change the WebVTT
decoding instead) but it seems a reasonable 'default' to follow.

PiperOrigin-RevId: 304353900

With these additional properties, we can declare the behaviour for clear tracks and clear content on a media item level.

PiperOrigin-RevId: 304351716

PiperOrigin-RevId: 304196424

SimpleExoPlayer instances don't have to be created from the application
thread.

PiperOrigin-RevId: 304190901

PiperOrigin-RevId: 304186326

PiperOrigin-RevId: 304184650

PiperOrigin-RevId: 304164078

Without this, URL-encoding is assumed, which means ampersand-codes are
not carried through to the underlying web page correctly.

PiperOrigin-RevId: 304163733

These are handled by converting to ampersand codes - add a test to show
that's explicit & deliberate.

PiperOrigin-RevId: 304163712

HlsSampleStreamWrapper currently calls HlsMediaChunk.init, which calls back
to HlsSampleStraemWrapper.init. This re-entrancy seems a bit confusing.

PiperOrigin-RevId: 304139462

Before:
https://docs.oracle.com/javase/7/docs/api/index.html?java/lang/String.html

After:
https://developer.android.com/reference/java/lang/String.html
PiperOrigin-RevId: 304137011

This means is-external=true is removed and target=_top is
set on the <a> tag.

Without this, javadoc links to framework docs with anchors are
currently broken when viewed in the "frame view" on
exoplayer.dev/doc/reference/

Before this change:
https://developer.android.com/reference/android/media/MediaDrm.html?is-external=true#getKeyRequest-byte:A-byte:A-java.lang.String-int-java.util.HashMap-

With this change:
https://developer.android.com/reference/android/media/MediaDrm.html#getKeyRequest-byte:A-byte:A-java.lang.String-int-java.util.HashMap-

PiperOrigin-RevId: 304136858

Partial rollback of https://github.com/google/ExoPlayer/commit/ca799716b8dab5ddf05d7deaf219ce4c645aab9f. We'll have to plumb
the id manually, like the rest of the LoadEventInfo
members.

PiperOrigin-RevId: 304067761

PiperOrigin-RevId: 303998690

Selection of a passthrough codec will rarely (if ever) need to be customized, so
remove this capability from MediaCodecInfo.

Applications can still customize whether passthrough is used by overriding
MediaCodecAudioRenderer.usePassthrough, which now also checks for a passthrough
codec.

#exo-offload

PiperOrigin-RevId: 303964682

PiperOrigin-RevId: 303937576

This is used to generate the initialization vector for encrypting the
cache contents.

Startblock:
   <unknown commit> is submitted
   and then
   3w have passed
PiperOrigin-RevId: 303932151

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

PiperOrigin-RevId: 303930392

PiperOrigin-RevId: 303829900

This avoids massive changes to method signatures to add throws.  Also, took suggestion to make it an `IllegalStateException`.

Move the catch outside of the finally that sets `nextLoadPosition` (this allows for possible recovery by reseting the `Extractor` and `TimestampAdjuster`).

Lastly, took the suggestion to make a minimum value for the tolerance (especially usefull for very short i-Frame only segments).

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