FakeClock keeps an internal list of messages to be executed to
ensure deterministic serialization. The next message from the list
is triggered by a separate helper message sent to the real Handler.
However, if the target HandlerThread is no longer alive (e.g. when
it quit itself during the message execution), this helper
message is never executed and the entire message execution chain
is stuck forever.
This can be solved by checking the return values of Hander.post or
Handler.sendMessage, which are false if the message won't be
delivered. If the messages are not delivered, we can unblock the
chain by marking the message as complete and triggering the next
one.
PiperOrigin-RevId: 491275031
(cherry picked from commit 2977bef872d7f3a1611fd6e8a45931388ea21c9f)
Ignorable ad periods are skipped to resolve the media period id with the
ad playback state of the resulting period. In case of a change in the period
position un-played ad periods are rolled forward to be played.
PiperOrigin-RevId: 428011116
MediaSource can be reused with other Player instances after they
have been released, so we need to set the PlayerId when preparing
the source. Access can mostly be handled by the implementation in
BaseMediaSource.
PiperOrigin-RevId: 408878824
Our package-info.java files are annotated with @NonNullApi which results
in everything being non-null by default, so this annotation is never
needed.
#minor-release
PiperOrigin-RevId: 405864737
Assert that opening the DataSource at the end of the resource
results in only RESULT_END_OF_INPUT being read.
open() and read() are still permitted to throw, although this
permissiveness will be removed in subsequent commits.
PiperOrigin-RevId: 362905314
- Refactor TextEmphasis class to support different ordering of styles
- Merge RubySpan.Position and TextEmphasisSpan.Position
- Remove TTML constructs from Spanned classes
Assert that an exception is not thrown from DataSource.open
if the DataSpec's start position is valid but its end position
extends beyond the end of the data.
HTTP based DataSource implementations have no good way of
knowing when this is the case, so it makes sense to make this
the required behaviour, rather than requiring an exception to
be thrown or allowing both.
There are also use cases where the caller may want to use the
end position as an upper bound, without knowing for sure how
long the content is. An example of this use case is wanting to
pre-cache the first N bytes of a stream. This implies that any
exception should be thrown after reading to the end of the
data, rather than preemptively in open.
Issue: #7326
PiperOrigin-RevId: 359063721
We currently block the loading thread until the calculated load
time has past and then unblock again by a message sent from the
playback thread. However, because the loading thread itself is not
using a Looper and runs freely, we don't control when the short
calculations on the loader thread that determine how long we have
to wait are happening, and we also don't control how long it takes
to start and stop this thread.
To solve these problems and to make the playback deterministic we
can
1. Send a message on the playback thread to block until the loader
thread has started.
2. Block the playback thread whenever a loading thread is doing its
short calculation of wait times. The playback thread knows when it
can continue because loading either enter a new waiting state for
a simulated load time or loading is finished completely.
3. Also wait on the playback thread until the loader has shut down.
As this is waiting for a message on the playback thread, we can
achieve this by sending messages to ourselves at the current time
until the loader is shut down.
All 3 steps together ensure that the loading thread interaction is
compeltely deterministic when simulating bandwidth profiles with the
BandwidthProfileDataSource. As we need to notify the source before and
after the load started/finished, we also need a small wrapper for the
chunk source when running the playback.
PiperOrigin-RevId: 355810408
This is achieved by only triggering one message at a time. After
triggering a message we send another to ourselves to know when the
following message can be triggered.
Other required changes:
- The messages need to be sorted correctly (by time and creation order)
- To prevent deadlocks when one thread is waiting for another,
we need to add new method to Clock to indicate that the current
thread is about to wait. This then allows us to trigger messages
from other threads in FakeClock.
- AnalyticsCollectorTest needed some adjustments:
- onTimelineChanged now deterministically arrives after the initial
timline is already known, so some of the period information changes
from window only to full period info.
- The playlistOperations test suffers from a bug that the first frame
is rendered too early and that's why we now get additional events.
PiperOrigin-RevId: 353877832
We currently only remove messages that have already been sent
to the actual Handler, not the pending ones that are only kept
in the FakeClock. Fix this by also removing matching messages
from the FakeClock list.
PiperOrigin-RevId: 353877049
Currently only delayed messages are handled. Change this to handling
all messages so that we have more control over their execution order.
This requires adding a new wrapper type for the Message to support
the obtainMessage + sendToTarget use case.
PiperOrigin-RevId: 353876557
Add a test to DataSourceContractTest that asserts the gzip flag is
either ignored or handled correctly.
Add a test resource to DefaultHttpDataSourceContracTest that enables
gzip compression on the 'server' and checks it's handled correctly by
the client.
PiperOrigin-RevId: 352574359
Before this we added the resource info to Truth assertions, but the
same info is missing if an exception bubbles out of the SUT.
PiperOrigin-RevId: 346757960
This moves TestUtil#runMainLooperUntil and
TestUtil#createRobolectricConditionVariable to a new RobolectricUtil
class.
Also move testutil classes that use Robolectric-related utils classes
(e.g. TestPlayerRunHelper, TestDownloadManagerListener).
PiperOrigin-RevId: 336864959
This removes Supplier, Function and Predicate. Consumer is kept because
Guava doesn't have an equivalent (Java 8 does, but we can't use that
yet).
#exofixit
PiperOrigin-RevId: 323324392
We started using this method from other tests unrelated to
TestExoPlayer, so the method is better placed inside a generic Util
class.
PiperOrigin-RevId: 316675067
Add an `_` in long constants.
Eg: 10000 => 10_000.
I'm proposing this change because I have had multiple
missread due to confusing the number of 0 in a long number.
More specifically, added an underscore to all number matching:
`final.*\ [0-9]{2,}000;`
PiperOrigin-RevId: 313186920
If the condition isn't fulfilled, they currently block until the
test runner times out the test. Our usual approach is to timeout
in the test itself so that the error message is clearly showing the
blocked condition.
Also clean-up some documentation.
PiperOrigin-RevId: 309930198
- Improve documentation explaining the benefits of ExoPlayer's ConditionVariable
over the one that the platform provides
- Allow Clock injection
- Create TestUtil method for obtaining a ConditionVariable whose block(long)
method times out correctly when used in a Robolectric test
- Add basic unit tests for ConditionVariable
PiperOrigin-RevId: 308812698
Ultimately we only care if the style is both bold & italic, if some of
those are specified multiple times there's no problem.
PiperOrigin-RevId: 288862235
I decided the flags bit was a bit unclear so I played around with this
It's also needed for more 'complex' assertions like colors - I didn't
want to just chuck in a fourth int parameter to create:
hasForegroundColorSpan(int start, int end, int flags, int color)
PiperOrigin-RevId: 287989424
