We currently only catch IOExceptions to close the opened data source.
This means any other type of exception leaves the data source open,
which can caused SimpleCache to be blocked forever when another
data source tries to access the same cache area (which is still
locked by the open data source).
This problem was the cause for flakiness in DownloadManagerDashTest.
#cherrypick
Issue: google/ExoPlayer#9760
PiperOrigin-RevId: 729441817
This change only enable the partial support for progressive stream. For now, creating `DownloadRequest` for partial adaptive media will result in an `IllegalStateException`.
PiperOrigin-RevId: 729100584
In some cases, the ExoPlayer immediately transitions to `STATE_IDLE` or `STATE_ENDED` on application thread, while `isLoading` can still remain as `true` before it is finally updated from playback thread.
Issue: androidx/media#2133
#cherrypick
PiperOrigin-RevId: 728724157
This ensures it's easier to handle these State updates in other
helper classes if needed.
Issue: androidx/media#2128
#cherrypick
PiperOrigin-RevId: 728264396
The publish task currently forces to run lint and test
even though there is no technical dependency. If a
process (e.g. releasing a new library) wants to verify
lint and test work, it should run these steps explicitly.
#cherrypick
PiperOrigin-RevId: 728234811
Otherwise it's impossible to install the androidTest apk
of both lib-datasource and lib-exoplayer on the same device
#cherrypick
PiperOrigin-RevId: 727867871
This includes creating a new Factory for `MetricsReporter` and adding it to Transformer. This is done as we need to create a new `MetricsReporter` for each export operation, so it makes sense to have a Factory.
PiperOrigin-RevId: 727798528
Currently, as soon as the playback is considered disengaged (not
ready and playing), the foreground service is stopped.
This causes problems if the app or the user attempts to restart
playback after a short amount of time, where apps may run into
foreground service start restrictions.
Almost all of these short-term interaction issues can be solved
by keeping the foreground service running for an additional
timeout period, which is chosen to be 10 minutes to match the
behavior of future Android system enforcements. For any longer
term interactions, apps need to implement playback resumption
paths that can restart the service with the previous playback.
One caveat is that we currently use player.pause() as a way to
stop the foreground service in onTaskRemoved() if the app wants
to abandon playback at this point. With the timeout, the service
can no longer be stopped immediately just by calling pause(),
so we need to explicitly disable the timeout in the corresponding
helper method.
Issue: androidx/media#1928
Issue: androidx/media#111
PiperOrigin-RevId: 726942625
Controller and browsers are typically obtained with
Futures.addCallback(future, getMainExecutor()), which triggers
the onSuccess callback with a message post. We currently send
the initial media button preferences inline, causing the callback
in MediaController.Listener.onMediaButtonPreferencesChanged to
arrive before the FutureCallback.onSuccess callback.
In the test controller app, which causes crashed when
connecting to existing sessions for example. We can make this
more robust by also posting the initial update of the media button
preferences.
PiperOrigin-RevId: 726923498
We currently set both actions depending on the playWhenReady state
and we require both actions when converting a platform session to
a Media3 session (if ACTION_PLAY_PAUSE isn't set anyway).
This causes problems in two situations:
- A controller using the platform ACTION_PAUSE/ACTION_PLAY to
determine which button to show in a UI. This needs to be aligned
to the existing Util.shouldShowPlayButton we already use when
setting the PlaybackStateCompat state.
- A session only setting either ACTION_PAUSE or ACTION_PLAY
depending on its state. We should check if the action triggered
by setPlayWhenReady(...) is possible and allow COMMAND_PLAY_PAUSE
accordingly.
PiperOrigin-RevId: 726916720
When converting to platform states, STATE_ENDED is mapped to
STATE_STOPPED, but the reverse mapping always assumes STATE_STOPPED
means STATE_IDLE at the moment. We can use the same logic we already
apply for STATE_PAUSED to figure out if we are ended.
PiperOrigin-RevId: 726902064
Currently the notification disappears immediately when the player
enters an error or stopped state, but still has its media and
could resume on user request.
This can be fixed by only checking the existence of media and not
the state when deciding to show a notification.
PiperOrigin-RevId: 726901050
Added tests for APIs `getDrmInitData()`, `getPsshInfo()`, `getLogSessionId()` and `setLogSessionId(LogSessionId)`.
The Widevine encrypted sample was created from already existing `sample_fragmented.mp4` using `mp4encrypt`.
PiperOrigin-RevId: 726881977
This means the volume is available in the internal player,
which is a preparation step to moving the audio focus
handling to the internal player too.
PiperOrigin-RevId: 726880098
The creation can be moved to the playback thread (to guarantee it
happens in sync other initialization after playback start) and the
potentially blocking calls to the reporting methods can be moved
to the generic shared BackgroundExecutor (it can't use the playback
thread because it no longer exists when the session is ended after
the player is released).
PiperOrigin-RevId: 726872818
The mute value usually changes in line with volume == 0.
Also update the test to provide better coverage of the
immediate and delayed state changes.
PiperOrigin-RevId: 726839927
