In a later change ImaAdsLoader will use multiple AdTagLoaders.
This change shouldn't have any substantial changes in behavior (it's almost
entirely moving code around). An exception is that ImaSdkSettings is configured
when making a request rather than at construction time.
Issue: #3750
PiperOrigin-RevId: 339891712
ImaAdsLoader notified onEnded whenever an ad finished playing, but when an ad
is skipped in an ad pod we'd receive a playAd call before the player
discontinuity for skipping to the next ad. Fix this behavior by checking that
IMA's playing ad matches the player's playing ad before notifying onEnded.
#minor-release
PiperOrigin-RevId: 339424910
The 'implementation' dependency causes problems when resolving
ListenableFuture in contexts that also include the
com.google.guava:listenablefuture:1.0 dependency.
Issue: #7905
Issue: #7997
Issue: #7993
PiperOrigin-RevId: 337093024
This will reduce the amount of boilerplate required to pass the configuration
values around (especially in a planned future change when logic is factored out
of ImaAdsLoader).
PiperOrigin-RevId: 337058355
This is in preparation for supporting playlists of ads media sources using
ImaAdsLoader.
Existing ways of passing ad tags should still function but are deprecated (and
won't be supported with playlists).
Issue: #3750
PiperOrigin-RevId: 335618364
On receiving a fetch error for an ad that would otherwise play based on an
initial/seek position, the pending content position wasn't cleared which meant
that position reporting was broken after a fetch error. Fix this by always
clearing the pending position (if there was a pending position that will have
triggered the fetch error).
Also deduplicate the code for handling empty ad groups (fetch errors)
and ad group load errors.
Issue: #7956
PiperOrigin-RevId: 334113131
This is useful because ImaAdsLoader.getAdsLoader() can now return null
(before ads have been requested), and it avoids the app needing to get
an AdsManager to attach its listener.
PiperOrigin-RevId: 330907051
- Use a setter, which is consistent with how other optional
components are passed.
- Remove nesting where a provider provides another provider.
Since AdSupportProvider then only provides one thing, it
can be renamed to AdsLoaderProvider, which more clearly
expresses what it provides.
PiperOrigin-RevId: 330396334
This callback was not notified before, which could theoretically lead to ad
loading timing out. In practice it doesn't currently happen because the timeout
appears to start when the ad cue point is reached, not when loadAd is called.
We notify onLoaded when the ad media period is prepared (for HTML5 the
recommendation is to notify on the HTMLMediaElement 'canplay' event, which this
roughly corresponds to).
PiperOrigin-RevId: 324568407
AdDisplayContainer now takes the video ad player at construction time,
and obstructions are registered/unregistered via a new method. Also
'content complete' is now notified via ad callbacks rather than the
AdsLoader.
PiperOrigin-RevId: 320567666
Also move implementations of some VideoAdPlayer callback methods into
their own methods. This is a no-op change except for expanding the
scope of some defensive try blocks associated with those callbacks.
Also add static imports for Math.max and Assertions helpers methods.
PiperOrigin-RevId: 319958087
On reaching the end of the content we would notify content complete
and skip unplayed ads, causing a timeline change. That timeline change
was handled in a way that caused a further timeline change in the
2.11.6 release, where we don't yet deduplicate no-op Timeline changes,
causing repeated timeline changes indefinitely.
At tip-of-tree, the timeline wouldn't refresh repeatedly. However the
code for sending content complete at the point of transitioning to
play a preloaded postroll ad was not correct in that it didn't mark
previous ads as skipped. Instead they happened to be marked as
skipped later on due to the timeline change handling content
completion code triggering again.
Fix this by only marking ads as skipped when content completes once,
to avoid the duplicate timeline change, and moving the skipped ad
marking so it happens in the same place as notifying content complete.
PiperOrigin-RevId: 318454908
This removes a lot of duplication from the module configuration,
avoids divergence, and makes sure that only the important differences
to the default are visible in each module file.
PiperOrigin-RevId: 318024823
The IMA SDK now preloads postrolls which is great as we no longer need
to rely on detecting buffering at the end of the stream to trigger
playing postrolls.
Add in the required logic to detect the period transition to playing
the postroll.
Issue: #7518
PiperOrigin-RevId: 317610682
We currently get float ad cue points from IMA, but store these as
longs in microseconds. The cast from double to long would take the
floor of the value, which could lead to stored ad cue points being
off-by-one. Use Math.round to avoid this.
ImaAdsLoader also has code to map a double AdPodInfo position (which
should match a cue point) onto the corresponding ad group index by
searching the long ad cue points. Match the calculation used where we
map float cue points, including narrowing the position to a float
first to avoid regressions if IMA SDK behavior changes to represent
positions in more than float precision later, and also remove the
requirement that the ad positions match exactly as a defensive
measure.
PiperOrigin-RevId: 317607017
After an ad pod coming up has preloaded, if the user seeks before it
plays we get pauseAd/stopAd called for that ad pod. Also, the ad will
not load again. Work around this unexpected behavior by handling
pauseAd/stopAd and discarding the ad.
In future, it's likely that the IMA SDK will stop calling those
methods, and will loadAd again for the preloaded ad that was
unexpectedly discarded. This change should be compatible with that,
because the ad won't be discarded any more due to not calling stopAd.
Issue: #7492
PiperOrigin-RevId: 316873699
Ads can appear due to asynchronous ad tag requests completing after
earlier ads in a pod have loaded, so remove the requirement that the
ad count can't change. The MediaPeriodQueue should handling discarding
buffered content if an ad appears before already buffered content, so
I think this case is actually handled correctly by the core player
already.
Also remove the requirement that an ad URI can't change. This is a
defensive measure for now, but it's likely that a later fix in the IMA
SDK for an issue where loadAd is not called after preloading then
seeking before a preloaded ad plays will result in loadAd being called
more than once, and I think it's possible that the second call to
loadAd may have a different URI. Because the ad URI should only change
after an intermediate seek to another MediaPeriod, there shouldn't be
any problems with buffered data not getting discarded.
Issue: #7477
PiperOrigin-RevId: 316871371
The release() method was added in the recent IMA API changes for
preloading and now 'collides' with the ExoPlayer AdsLoader release
method. This led to all ads completing being treated as a call to
completely release the ads loader, which meant that the ad playback
state was not updated on resuming after all ads had completed, which
in turn led to playback getting stuck buffering on returning from the
background after all ads played.
Move the IMA callbacks into an inner class to avoid this.
Issue: #7508
PiperOrigin-RevId: 316834561
We're then able to use this same helper class from tests, to avoid
running into spurious failures caused by long microseconds being
round-tripped through float seconds.
PiperOrigin-RevId: 316435084
Some but not all VideoAdPlayer callbacks from the IMA SDK included
defensive handling of unexpected cases. Add the remaining ones.
Issue: #7492
PiperOrigin-RevId: 316082651
