PiperOrigin-RevId: 453510883
(cherry picked from commit 21ad8cf)

We need to request the external storage permission to access these

PiperOrigin-RevId: 454160546
(cherry picked from commit a90d523)

PiperOrigin-RevId: 455121899
(cherry picked from commit 545cd1e)

PiperOrigin-RevId: 455157744
(cherry picked from commit 91de5fa)

#minor-release

PiperOrigin-RevId: 455380010
(cherry picked from commit 4f5e99c)

Issue: #10316
PiperOrigin-RevId: 456084302
(cherry picked from commit d86bc10)

The offload sleeping stops as soon as a new DO_SOME_WORK message
is handled (because this indicates an expected change in rendering
and we want to stop sleeping until we know it's safe to do so).

Every exit path from doSomeWork needs to clear other pending
DO_SOME_WORK messages as these requests have already been handled by
the current method invocation. This currently doesn't happen from the
offload sleeping return path and a previously queued DO_SOME_WORK
message can immediately wake up the rendering loop again.

Fix this by moving the message removal to the beginning of the
doSomeWork method (as it prevents forgetting it in one of the
exit paths later).

PiperOrigin-RevId: 456259715
(cherry picked from commit 251389d)

PiperOrigin-RevId: 456753343
(cherry picked from commit 531f03a)

This was likely missed in 33373d0.

PiperOrigin-RevId: 457422574
(cherry picked from commit aaa0152)

1. The offloadSchedulingEnabled value doesn't need to be in
   PlaybackInfo because it's never updated in EPII.
2. The sleepingForOffload value in EPII wasn't updated explicitly
   (just via the return value of a method). It was also only
   meant to be enabled while the player is actively playing, but
   confusingly triggered from a path where the player may
   theoretically be buffering as well.
3. The offload sleeping (=not scheduling doSomeWork) was interwoven
   into the actual scheduling code making it slightly hard to follow.
   This can be improved slightly by keeping the offload sleeping
   decision and the scheduling separate.

PiperOrigin-RevId: 457427293
(cherry picked from commit aedde2d)

Issue: #10363
PiperOrigin-RevId: 457679928
(cherry picked from commit 194043a)

PiperOrigin-RevId: 457680579
(cherry picked from commit 40350bc)

NoUidTimeline still exists as a private detail of TestUtil, but it no
longer extends ForwardingTimeline because the interactions are quite
hard to reason about.

#minor-release

PiperOrigin-RevId: 457703593
(cherry picked from commit 292f6de)

Previously two timelines that differed only in shuffle order were
considered equal, which resulted in no call to
Player.Listener.onTimelineChanged when calling
ExoPlayer.setShuffleOrder. This in turn resulted in no call to
MediaControllerCompat.Callback.onQueueChanged.

Also make a small fix inside ExoPlayerImpl.setShuffleOrder, to ensure
that the new shuffle order is used when constructing the masked
timeline.

Issue: #9889
#minor-release
PiperOrigin-RevId: 457703727
(cherry picked from commit 5c7ec13)

Issue: #10298
#minor-release
PiperOrigin-RevId: 457991028
(cherry picked from commit bf86b60)

As per MP4 spec, the length of URL array is a 8 bit number.

#minor-release

PiperOrigin-RevId: 458421436
(cherry picked from commit 5095ff1)

As per MP4 spec, bitrates in esds boxes can be a 32 bit number which doesn't fits in Java int type, so now reading it as a long value. Our class for holding media format, only allows bitrates value to be an int as we don't expect the bitrates to be greater than or equal to 2^31. So we're limiting the values for bitrates to Integer.MAX_VALUE.

#minor-release

PiperOrigin-RevId: 458423162
(cherry picked from commit 9e10286)

ProgressiveMediaPeriod loads all available tracks into SampleStreams
(because it needs to read the data anyway and it allows easy activation
of tracks without reloading). However, the SampleStreams for disabled
tracks are not read and no one if waiting for them.

The buffered position is used for user-visible state (e.g. in the UI)
and to check how much data is already buffered to decide when to stop
buffering (using LoadControl). Both values benefit from only
using the actually enabled tracks to better reflect what is available
for playback at the moment.

Issue:Issue: #10361
PiperOrigin-RevId: 458475038
(cherry picked from commit 577e191)

This is to be consistent with what cast `QueueMediaItem` is doing. If a contentId is
not available the contentUrl is used as the ID.

#minor-release

PiperOrigin-RevId: 459133323
(cherry picked from commit 84c801a)

This profile is declared as supported although it isn't.

Issue: #10345
Issue: #3537

#minor-release

PiperOrigin-RevId: 459205512
(cherry picked from commit bf88f28)

PiperOrigin-RevId: 459485334
(cherry picked from commit 752e82d)

Also added the test to `MP4PlaybackTest`.

PiperOrigin-RevId: 459492188
(cherry picked from commit a166584)

PiperOrigin-RevId: 458883441
(cherry picked from commit 486c350)

PiperOrigin-RevId: 459215225
(cherry picked from commit 9521807)

We wait until a previous AudioTrack has been released before
creating a new one. This is currently done with a thread
block operation, which may cause ANRs in the extreme case
when someone attempts to release the player while this is
still blocked.

The problem can be avoided by just returning false from
DefaultAudioSink.handleBuffer to try again until the previous
AudioTrack is released.

Reproduction steps to force the issue:
1. Add Thread.sleep(10000); to the AudioTrack release thread.
2. Add this to the demo app:
    private int positionMs = 0;

    Handler handler = new Handler();
    handler.post(new Runnable() {
      @OverRide
      public void run() {
        player.seekTo(positionMs++);
        if (positionMs == 10) {
          player.release();
        } else {
          handler.postDelayed(this, 1000);
        }
      }
3. Observe Player release timeout exception.

These steps can't be easily captured in a unit test as we can't
artifically delay the AudioTrack release from the test.

Issue: #10057
PiperOrigin-RevId: 459468912
(cherry picked from commit a80dd60)

#minor-release

Issue: #10420
PiperOrigin-RevId: 460223064
(cherry picked from commit c43d9f5)

The media item needs to be assigned to `Window.mediaItem` in `CastTimeline.setWindow`. For this the `MediaItem` needs to be available in the timeline.

When a `MediaItem` is passed to the `set/addMediaItems` method, we can't yet know the Cast `MediaQueueItem.itemId` that is generated on the device and arrives with an async update of the `RemoteMediaClient` state. Hence in the `CastTimelineTracker`, we need to store the `MediaItem` by Casts's `MediaItem.contentId`. When we then receive the updated queue, we look the media item up by the content ID to augment the `ItemData` that is available in the `CastTimeline`.

Issue: androidx/media#25
Issue: #8212

#minor-release

PiperOrigin-RevId: 460325235
(cherry picked from commit 02e1484)

I don't think it's useful to keep these in numerical order, it makes
more sense to keep them grouped into a 'logical' ordering.

#minor-release

PiperOrigin-RevId: 460453464
(cherry picked from commit 1b1e0f8)

Issue: androidx/media#25
PiperOrigin-RevId: 460476841
(cherry picked from commit d6659e9)

Note: This was already reviewed in <unknown commit>. This doesn't mean we cannot apply further changes though.
PiperOrigin-RevId: 460542835
(cherry picked from commit d59334c)

Leaving the media item that has been passed in unchanged, ensures that the
media item in the timeline is equal to the media item that the user has
passed into the player. The value of the tag is the uid of the window,
meaning this is redundant information.

#minor-release

PiperOrigin-RevId: 460542246
(cherry picked from commit 9d87c0d)

PiperOrigin-RevId: 460513413
(cherry picked from commit c75b6a3)

PiperOrigin-RevId: 460689252
(cherry picked from commit 6043739)

The call doesn't currently reset the already loaded suppliers and
factories. Also fix the supplier loading code to use a local copy
of the current dataSourceFactory to avoid leaking an updated
instance to a later invocation.

Issue: androidx/media#116

#minor-release

PiperOrigin-RevId: 460721541
(cherry picked from commit 6be0d6e)

#minor-release

PiperOrigin-RevId: 461162552
(cherry picked from commit 6d27ff8)

#minor-release

PiperOrigin-RevId: 461177918
(cherry picked from commit 7a10dd1)

Also rearranged release notes to correctly show when the changes were released.

#minor-release

PiperOrigin-RevId: 462361982
(cherry picked from commit c6e69a3)