This change deprecates Player.onPlayerStateChanged(boolean pwr, int state). It removes deprecation for trivial cases. I'll remove other deprecated usages (mostly in ui module) in follow-up CLs to not bloat this CL.
PiperOrigin-RevId: 292917872
ImaAdsLoader relies on preloading being enabled (it doesn't
work without it) so we may as well remove the constant to
avoid potential confusion.
PiperOrigin-RevId: 284951356
*** Original commit ***
Rollback of 4ad4e3e4fc
*** Original commit ***
Rollback of 3b22db33ba
*** Original commit ***
add top-level playlist API to ExoPlayer
Public design doc:
https://docs.google.com/document/d/11...
***
PiperOrigin-RevId: 275813737
This flag is currently merged into Window.isDynamic, which isn't always true
because
1. A window can be dynamic for other reasons (e.g. when the duration is still
missing).
2. A live stream can be become non-dynamic when it ends.
Issue:#2668
Issue:#5973
PiperOrigin-RevId: 271999378
If the app seeks after we get an ads manager but before the player exposes the
timeline with ads, we would end up expecting to play a preroll even after the
seek request arrived. This caused the player to get stuck.
Wait until a non-empty timeline has been exposed via onTimelineChanged before
initializing IMA (at which point it can start polling the player position). Seek
requests are not handled while an ad is playing.
PiperOrigin-RevId: 265058325
Any seek before the first timeline becomes available will result in a NPE.
Change it to handle that case gracefully.
Issue:#5831
PiperOrigin-RevId: 264603061
AdsMediaSource posts AdsLoader.start to the main thread during preparation, but
the app may call AdsLoader.setPlayer(null) before it actually runs (e.g., if
initializing then quickly backgrounding the player).
This is valid usage of the API so handle this case instead of asserting. Because
not calling setPlayer at all is a pitfall of the API, track whether setPlayer
has been called and still assert that in AdsLoader.start.
PiperOrigin-RevId: 264329632
We no longer need two modules as AndroidX-Test takes care of the system
abstraction and we no longer have Robolectric Handler/Looper workarounds.
PiperOrigin-RevId: 262363201
- Remove manifest argument from callbacks of Player.EventListener and
SourceInfoRefreshListener. Instead make it accessible through
Player.getCurrentManifest() and Timeline.Window.manifest.
- Fix all MediaSource implementation to include the manifest in the
Timeline instead of passing it to the SourceInfoRefreshListener.
- Refactor ExoPlayerTestRunner, FakeTimeline, FakeMediaSource to
reflect these changes and make tests pass.
PiperOrigin-RevId: 257359662
We are currently defaulting to targetSdk=1 as no targetSdk is specified. Only
tests which explicitly ask for another SDK use another test SDK. With the
versioned manifest, all tests run using the targetSDK by default.
PiperOrigin-RevId: 249060796
We previously only checked whether the reason for the timeline change is
RESET which indicates an empty timeline. Change this to an explicit check
for empty timelines to also ignore empty media or intermittent timeline
changes to an empty timeline which are not marked as RESET.
Issue:#5831
PiperOrigin-RevId: 248499118
The old domain automatically forwards to the new one. For consistency, change
all doc and code references regardless.
Also adds GitHub CNAME config file which configures our page for the custom
domain.
PiperOrigin-RevId: 243592110
This replaces the deprecated usages of RobolectricTestRunner and
RuntimeEnvironent and fully migrates the tests to androidx.
PiperOrigin-RevId: 238011667
Switch from passing an ad UI ViewGroup to passing an object that can also
provide information about controls overlays.
Also switch to using a dedicated overlay for ads instead of the overlay frame
layout, which apps have easy access to.
PiperOrigin-RevId: 233393500
Given the change to require setPlayer on AdsLoaders, it seems like a good
opportunity to clean up deprecated ads-related symbols.
PiperOrigin-RevId: 233020171
That's the same position set in MediaPeriod.prepare (where it may be removed
in the future).
Having the position at an earlier point is necessary to fix an
issue with lazy preparation in ConcatenatingMediaSource where the prepare
position was assumed to be known but MediaPeriod.prepare hasn't been called
yet.
Issue:#5350
PiperOrigin-RevId: 229756637
They are not longer needed anywhere, are error-prone (because of threading
requirements), and complicate testing and using MediaSources without a player.
PiperOrigin-RevId: 227871157
Passing the player through MediaSource.prepare is only needed for the AdsLoader
and complicates other usages of MediaSource. Providing the player directly to
the AdsLoader is also in line with the usage pattern of PlayerView and other
components.
Also rename methods to start/stop to better reflect their usage.
PiperOrigin-RevId: 227682112
