SDK / exoplayer

This CL changes PlayerActivity's VIEW_LIST action intent contract:
Each media item configuration is provided by indexing the entries.
For example, the URI of the first item is passed as "uri_0", the
second one is "uri_1", etc. Optionally, the extra parameters, like
the extensions, are passed as "extension_1", where the intent extras
with matching indices, refer to the same media sample.

The VIEW action's contract remains unchanged.

PiperOrigin-RevId: 260518118

Issue: #6229
PiperOrigin-RevId: 260500986

PiperOrigin-RevId: 260479923

Both periods are rarely updated in the same iteration. If they are, advancing
the reading period first seems more logical and also more efficient as it may
avoid one extra doSomeWork iteration.

PiperOrigin-RevId: 260463735

Moved update of reading and playing periods in their own respective method.
This is a no-op change.

PiperOrigin-RevId: 260463668

PiperOrigin-RevId: 260164426

When using speed adjustment it was possible for playback to get stuck at a
period transition when the channel count changed: SonicAudioProcessor would be
drained at the point of the period transition in preparation for creating a new
AudioTrack with the new channel count, but during draining the incorrect (new)
channel count was used to calculate the output buffer size for pending data from
Sonic. This meant that, for example, if the channel count changed from stereo to
mono we could have an output buffer size that stored an non-integer number of
audio frames, and in turn this would cause writing to the AudioTrack to get
stuck as the AudioTrack would prevent writing a partial audio frame.

Use Sonic's current channel count when draining output to fix the issue.

PiperOrigin-RevId: 260156541

Issue: #6222
PiperOrigin-RevId: 260146226

PiperOrigin-RevId: 260021990

PiperOrigin-RevId: 259918196

We keep track of the last publicly known playing period to report it as part
of events happening after the period has been released.

In cases where a period briefly becomes the playing one and is released
immediately afterwards, we currently don't save it as the "last known playing
one". Improve that by saving an explicit reference.

Issue:#5407
PiperOrigin-RevId: 259737218

Creating a period in MaskingMediaSource may result in delayed event reporting
depending on when the actual period gets created. To avoid event reporting
inaccuracies, report the mediaPeriodCreated and mediaPeriodReleased events
directly.

Issue:#5407
PiperOrigin-RevId: 259737170

Both tags allow any BCP47 compliant code, not just the ISO 639-2/T ones.

PiperOrigin-RevId: 259714587

This changes the logic in the following ways:
 - If no preferred language is matched, prefer better scores for the selected
   audio language.
 - If a preferred language is matched, always prefer the better match
   irrespective of default or forced flags.
 - If a preferred language score and the isForced flag is the same, prefer
   tracks with a better selected audio language match.

PiperOrigin-RevId: 259707430

PiperOrigin-RevId: 259707359

PiperOrigin-RevId: 259687632

PiperOrigin-RevId: 259608495

PiperOrigin-RevId: 259586520

PiperOrigin-RevId: 259582498

Some variables were defined although they are the default and other things
were set-up in a non-sensible way, e.g. asserting that audio is selected
although no audio renderer is available, or using unset duration for
everything.

PiperOrigin-RevId: 259532782

PiperOrigin-RevId: 259529691

PiperOrigin-RevId: 259523450

PiperOrigin-RevId: 259520431

PiperOrigin-RevId: 259479785

+ Emulates what's done for ID3 stripping.
+ Also avoid a copy if fields will not change because of the
  copy.

PiperOrigin-RevId: 259369101

PiperOrigin-RevId: 258812820

Recognize AV1ProfileMain10HDR when getting codec profile and level.

PiperOrigin-RevId: 258799457

PlaybackInfo changes are one of the last ones not masked and reported in the same
way as all other changes.

The main change to support this is to also mask the parameters set in
DefaultAudioSink.

PiperOrigin-RevId: 258787744

1. Using the Locale on API<21 doesn't make any sense because it's a no-op
   anyway. Slightly restructured the code to avoid that.
2. API<21 often reports languages with non-standard underscores instead of
   dashes. Normalize that too.
3. Some invalid language tags on API>21 get normalized to "und". Use original
   tag in such a case.

Issue:#6153
PiperOrigin-RevId: 258773463

PiperOrigin-RevId: 258754710

PiperOrigin-RevId: 258752996

AV1 profile recognition requires additional info contained in format.

PiperOrigin-RevId: 258746315

2-letter codes (ISO 639-1) are the standard Android normalization and thus we
should prefer them to 3-letter codes (although both are technically allowed
according the BCP47).

This helps in two ways:
 1. It simplifies app interaction with our normalized language codes as the
    Locale class makes it easy to convert a 2-letter to a 3-letter code but
    not the other way round.
 2. It better normalizes codes on API<21 where we previously had issues with
    language+country codes (see tests).
 3. It allows us to normalize both ISO 639-2/T and ISO 639-2/B codes to the same
    language.

PiperOrigin-RevId: 258729728

Issue:#6192
PiperOrigin-RevId: 258592902

PiperOrigin-RevId: 258590215

If we use the default start position, we currently resolve it immediately
even if we need to play an ad first, and later try to project forward again
if we believe that the default start position should be used.

This causes problems if a specific start position is set and the later
projection after the preroll ad shouldn't take place.

The problem is solved by keeping the content position as TIME_UNSET (= default
position) if an ad needs to be played first. The content after the ad can
then be resolved to its current default position if needed.

PiperOrigin-RevId: 258583948

PiperOrigin-RevId: 258574110

Add appropriate unit tests.

PiperOrigin-RevId: 258552404

Issue: #6184
PiperOrigin-RevId: 258527533