ShadowLooper -> ShadowLegacyLooper
ShadowRealisticLooper -> ShadowPausedLooper
ShadowBaseLooper -> ShadowLooper
And all public methods from ShadowLegacyLooper get pushed up to ShadowLooper
Pull Request: https://github.com/robolectric/robolectric/pull/4868
Copybara: OK
Also adjust Google3 tests using custom looper shadows where necessary.
Convert exoplayer to paused looper to eliminate reliance on custom shadows
PiperOrigin-RevId: 243839311
The only state DownloadInternal holds is duplicate of state contained
in Download, but can confusingly be temporarily out of sync. This is
error prone because it's easy to use the wrong variable (e.g.
download.state vs state). DownloadInternals methods are called into
and call out into DownloadManager, which makes some code paths that
are quite hard to follow.
It's possible to simplify DownloadManager quite a lot by removing the
duplicated state in DownloadInternal, at which point DownloadInternal's
methods flatten into DownloadManager, which can just hold an internal
list of Downloads directly.
This is a first step, which makes it clear that DownloadThready only
needs its immutable DownloadAction + an isRemove flag.
PiperOrigin-RevId: 243245288
It's a transient state whose only use is when passing a removed
download to onDownloadStateChanged. It's a bit strange to have it
as a proper state, since we end up asserting that it's an invalid
value in other places.
This change adds an explicit onDownloadRemoved, which allows
removal of the transient STATE_REMOVED, related assertions, and
uncertainty when dealing with an @State variable whether it's
necessary to handle it being STATE_REMOVED.
PiperOrigin-RevId: 242444128
This replaces the deprecated usages of RobolectricTestRunner and
RuntimeEnvironent and fully migrates the tests to androidx.
PiperOrigin-RevId: 238011667
Also add explicit Lint.IfChange/ThenChange rules to make it
clearer what needs to be done when changing one of the code
paths that's accessed via reflection.
PiperOrigin-RevId: 233406709
Without this change, any prepare() operation that requires posting to
the DummyMainThread's handler cannot complete preparation.
PiperOrigin-RevId: 233050367
Converting a single track selection to stream keys is only possible if the output
is independent from other track selections being made.
This is not the case for DASH and HLS embedded track groups which should select the
already selected primary track if possible (and thus needs to know whether a primary
track group is selected).
Also, update the test method to take a period index.
PiperOrigin-RevId: 231385490
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
Made DownloadState top level class.
Replaced action field DownloadAction fields.
Added removing, removed and restarting states.
Renamed started state to downloading.
PiperOrigin-RevId: 227664735
This is useful to write integration tests for MediaSources which check that the
stream keys returned by getStreamKeys are compatible with the respective manifest
parser.
PiperOrigin-RevId: 225542606
We currently have two factory methods where it is completely unclear which one needs
to be overridden.
This change deprecates the old one, adds a Util method to easily map back from the new
to the old behaviour, and updates all implementations of the now deprecated method in
our code.
PiperOrigin-RevId: 224303560
We currently default to not caching data if the content length
cannot be resolved once the DataSource has been open. The
reason for this is to avoid caching progressive live streams.
By doing this we were accidentally not caching in other places
where caching is possible, such as DASH/SS/HLS segments during
playback if the server doesn't include a Content-Length header.
Also HLS encryption key chunks, which were very unlikely to be
cached during playback because we explicitly set FLAG_ALLOW_GZIP
(which normally stops content length from resolving) without
setting FLAG_ALLOW_CACHING_UNKNOWN_LENGTH.
It seems like a good idea to flip the default at this point,
and explicitly disable caching in the one case where we want
that to happen.
PiperOrigin-RevId: 223994110
This allows more efficient range removals and is consistent with addition,
which supports adding multiple elements in a single operation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222396310
createTrackSelections decides whether to create an adaptive or a fixed track seletion to create.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222231011
A lot of methods just forward to other methods and there is no conceivable
way a player should implement it another way. Moving these methods to a
base player class allows to remove duplicated code across our player
implementations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215374192
This simplifies code skipping items in a playlist programatically.
Issue:#4863
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214580742
This provides the list of currently buffered media chunks and iterators over
the potential next chunks to the track selection. Having these two parameters
enables more advanced decision logic based on this data.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210551812
- Add @Deprecated on overrides of deprecated method.
- Suppress deprecation warnings where appropriate.
- Use non-deprecated alternatives where appropriate.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210092434
Similar to getBufferedPosition and getCurrentPosition, getDuration should
mention that it also returns the duration of the current ad.
And, also similar to getContentBufferedDuration and getContentPosition, a
new method getContentDuration simplifies querying the content duration while
playing an ad.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209914696
The MediaPeriodId with index is only properly defined together with a
timeline containing the index. Changing it to the period uid allows to use
the MediaPeriodId independent of the corresponding timeline.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209430257
