- If DownloadService is configured to run as a foreground service,
it will remain started and in the foreground when downloads are
waiting for requirements to be met, with a suitable "waiting for
XYZ" message in the notification. This is necessary because new
foreground service restrictions in Android 12 prevent to service
from being restarted from the background.
- Cases where requirements are not supported by the Scheduler will
be handled in the same way, even on earlier versions of Android.
So will cases where a Scheduler is not provided.
- The Scheduler will still be used on earlier versions of Android
where possible.
Note: We could technically continue to use the old behavior on
Android 12 in cases where the containing application still has a
targetSdkVersion corresponding to Android 11 or earlier. However,
in practice, there seems to be little value in doing this.
PiperOrigin-RevId: 398720114
The MIME type is currently required to select a SubtitleDecoder
implementation in the TextRenderer. Future changes might remove this
requirement, so we pre-emptively mark the field as @Nullable.
The change in SingleSampleMediaSource ensures the track still maps to
the TextRenderer, otherwise it shows up as unmapped. Passing null MIME
type to MediaItem.Subtitle constructor now results in this from
EventLogger:
TextRenderer [
Group:0, adaptive_supported=N/A [
[ ] Track:0, id=null, mimeType=text/x-unknown, language=en, supported=NO_UNSUPPORTED_TYPE
]
]
PiperOrigin-RevId: 398010809
Both license and provisioning requests could be considered 'DRM
requests', and these headers are only sent on license requests, so
rename them to reflect that.
The old field remains deprecated for backwards compatibility.
PiperOrigin-RevId: 397980021
The type is already UUID so there's no need to duplicate that info in
the field name, and 'scheme' is a widely used term throughout both
ExoPlayer and android.os.MediaDrm documentation.
The old field remains deprecated for backwards compatibility.
The MediaItem.DrmConfiguration.Builder#setUuid method is renamed
directly (without deprecation) because it's not yet part of a released
ExoPlayer version.
PiperOrigin-RevId: 397961553
This takes advantage of the new MediaItem.LiveConfiguration.Builder
This change will always allocate a new LiveConfiguration.Builder and
LiveConfiguration, but preserves the behaviour of keeping the same
MediaItem instance if no values have changed.
PiperOrigin-RevId: 397961427
This is known to silently drop the value. This setter is now deprecated
in favour of `MediaItem.Builder#setDrmConfiguration(MediaItem.DrmConfiguration)`,
which requires a UUID in order to construct the `DrmConfiguration`
instance.
Issue: #9378 tracks correctly propagating the DRM info out of
`DownloadRequest#toMediaItem`.
PiperOrigin-RevId: 397291013
The deprecated `Player.addListener(EventListener)`
is moved out of Player into its subclasses
(CastPlayer and ExoPlayer).
This is unlikely to break users because:
- the method has been deprecated in the last major version
- the method is still present in the major implementations
If an users is affected, they can either:
- use ExoPlayer instead of Player
- (recommended) switch to Player.Listener.
Additionally update the threading guarantees that did not
reflect the current implementation.
PiperOrigin-RevId: 397272144
* Avoid ActivityManager log spam by only calling startForeground once,
and subsequently updating the notification via NotificationManager.
* Tweak demo app service to make it a tiny bit easier to swap the Scheduler.
PiperOrigin-RevId: 397179398
The second getScheduler() call violates the documentation of
the class, which states that getScheduler() is not called if
foregroundNotificationId if FOREGROUND_NOTIFICATION_ID_NONE.
Presumably implementing subclasses would return null, in which
case this didn't do any harm, but we should make sure the
implementation behaves as documented regardless.
PiperOrigin-RevId: 397167603
*** Original commit ***
Ensure MediaSourceFactory instances can be re-used
This fixes DefaultDrmSessionManager so it can be used by a new Player
instance (by nulling out its reference to the playback thread, which is
unique per-Player instance). This only works if the
DefaultDrmSessionManager is 'fully released' before being used by the
second Player instance, meaning that the reference count of the manager
and all its sessions is zero.
#exofixit
Issue: #9099
***
PiperOrigin-RevId: 396861138
Previously the released preacquired sessions would start their keepalive
timeout, and so no additional resources would be freed in time for the
manager to retry the session acquisition.
This change adds an additional purge of keepalive sessions *after* the
preacquired sessions are released, which fixes the problem.
#exofixit
#minor-release
PiperOrigin-RevId: 396613352
This is was reported in #9257 where the PlaybackStatsListener may try to
access an emtpy ArrayList.
Issue: #9257
#minor-release
#exofixit
PiperOrigin-RevId: 396329373
This is a candidate fix for #8906. As mentioned in that issue,
negative positions within windows might be (kind of) valid in
live streaming scenarios, where the window starts at some
non-zero position within the period. However, negative positions
within periods are definitely not valid. Neither are positions
that exceed the period duration.
There was already logic in ExoPlayerImplInternal to prevent a
resolved seek position from exceeding the period duration. This
fix adds the equivalent constraint for the start of the period.
It also moves the application of the constraints into Timeline.
This has the advantage that the constraints are applied as part
of state masking in ExoPlayerImpl.seekTo, removing any UI flicker
where the invalid seek position is temporarily visible.
Issue: #8906
PiperOrigin-RevId: 395917413
The new name is consistent with the corresponding parameters to `onVolumeChanged`, `setDeviceVolume` and `onDeviceVolumeChanged`.
PiperOrigin-RevId: 395705288
This fixes DefaultDrmSessionManager so it can be used by a new Player
instance (by nulling out its reference to the playback thread, which is
unique per-Player instance). This only works if the
DefaultDrmSessionManager is 'fully released' before being used by the
second Player instance, meaning that the reference count of the manager
and all its sessions is zero.
#exofixit
#minor-release
Issue: #9099
PiperOrigin-RevId: 395490506
The C2 MP3 decoder produces an extra output buffer when draining after
end-of-stream is queued. This output buffer has a later timestamp than the last
queued input buffer so we need to calculate its timestamp to detect a stream
change in the correct position.
Before this CL we used the original input buffer timestamp as the largest
queued timestamp, which caused the stream change to be detected at the correct
position because the original input buffer timestamp was slightly larger than
the actual last output buffer timestamp. After this change we use exact
calculated timestamp as the largest queued timestamp. I manually verified
gapless continues to work on a device using the C2 MP3 decoder by comparing
output of the MP3 gapless and MP3 gapless stripped playlists in the demo app,
and that the last buffer timestamp now matches.
#exofixit
PiperOrigin-RevId: 395428928
C should only hold constants.
Also resolve the TODO in getErrorCodeForMediaDrmErrorCode(), and
annotate the deprecated methods with Error Prone's @InlineMe to
facilitate automated refactoring of callers.
PiperOrigin-RevId: 395244855
