Setting the requested encoding in all cases ensures we receive the relevant
response headers indicating whether gzip was used. Doing that allows to
detect the content length in cases where gzip was requested, but the server
replied with uncompressed content.
PiperOrigin-RevId: 250660890
cache() opens all connections with unset length to avoid position errors.
This makes more data then needed to be downloading by the underlying
network stack.
This fix makes makes it open connections for only required length.
Issue:#5927
PiperOrigin-RevId: 250546175
"Write case, lock not available" was a bit confusing. When the
content is not cached and the lock is held, it's neither a read
or a write case. It's a "can't do anything" case. When blocking,
it may subsequently turn into either a read or a write.
PiperOrigin-RevId: 250530722
The former is deprecated and replaced by the latter in Mockito 2. However, there is a
functional difference: ArgumentMatchers will reject `null` and check the type
if the matcher specified a type (e.g. `any(Class)` or `anyInt()`). `any()` will
remain to accept anything.
PiperOrigin-RevId: 250458607
Removes the need for duplicate calls to SampleQueue#read when
implementing DecryptionResources acquisition in the MediaSources.
PiperOrigin-RevId: 250298175
The only known use case for contentTypePredicate is to catch
the case when a paywall web page is returned via a DataSource,
rather than the data that was being requested. These days streaming
providers should be using HTTPS, where this problem does not exist.
Devices have also gotten a lot better at showing their own
notifications when paywalls are detected, which largely mitigates
the need for the app to show a more optimal error message or
redirect the user to a browser.
It therefore makes sense to deprioritize this feature. In
particular by removing the arg from constructors, where nearly
all applications are probably passing null.
PiperOrigin-RevId: 249634594
This prevents further unexpected updates if the MediaSource happens to
finish its preparation at a later point.
Issue:#5915
PiperOrigin-RevId: 249439246
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
If a PlayerMessage throws an exception, it is currently not deleted from the
list of pending messages. This may be problematic as the list of pending
messages is kept when the player is retried without reset and the message is
sent again in such a case.
PiperOrigin-RevId: 247414494
Adding an explicit option to clear all downloads prevents repeated database
access in a loop when trying to delete all downloads.
However, we still create an arbitrary number of parallel Task threads for this
and seperate callbacks for each download.
PiperOrigin-RevId: 247234181
1. A content session after an ad has been played was not re-marked as active,
leading to new ad session being marked as active too early.
2. Switching from content to post-roll ended the content session because
the return value of getAdGroupTimeUs of C.TIME_END_OF_SOURCE was not
handled. Using the nextAdGroupIndex instead.
PiperOrigin-RevId: 246977327
As justification for why we should not have this type of logging,
it would scale up to about 13K LOC, 1800 Strings, and 36K (after
pro-guarding - in the case of the demo app) if we did it through
the whole code base*. It makes the code messier to read, and in
most cases doesn't add significant value.
Note: I left the Scheduler logging because it logs interactions
with some awkward library components outside of ExoPlayer, so is
perhaps a bit more justified.
* This is a bit unfair since realistically we wouldn't ever add
lots of logging into trivial classes. But I think it is fair
to say that the deltas would be non-negligible.
PiperOrigin-RevId: 246181421
- Removed DownloadInternal and its sometimes-out-of-sync
duplicate state
- Fixed downloads being in STOPPED rather than QUEUED state
when the manager is paused
- Fixed setMaxParallelDownloads to start/stop downloads if
necessary when the value changes
- Fixed isWaitingForRequirements
PiperOrigin-RevId: 246164845
They behave identically, and the old names are being removed.
Open-source note: The new methods are available in Truth as of version 0.44.
END_PUBLIC
More information:
go/issameas-lsc
Tested:
TAP --sample ran all affected tests and none failed
http://test/OCL:246024032:BASE:246042619:1556672975894:513e7746
PiperOrigin-RevId: 246101315
This resolves some naming confusion that previously existed
as a result of DownloadThread also being used for removals.
Some related variables (e.g. activeDownloadCount) would refer
to both download and removal tasks, whilst others
(e.g. maxParallelDownloads) would refer only to downloads.
This change renames those that refer to both to use "task"
terminology.
This change also includes minor test edits.
PiperOrigin-RevId: 245913671
[Problem]
There are 3 services / modes transported on line 21:
- Captioning
- TEXT (generally not program related)
- XDS (eXtended Data Services)
Bytes belonging to the unsupported modes are interleaved with the
bytes of the captioning mode.
See Chapter 7, Chapter 8.5 and Chapter 8.6 of the CEA608 Standard for
more details.
[Solution]
Drop all bytes belonging to unsupported modes.
[Test]
- All streams containing only captioning services should not be influenced
- Test all 4 CEA 608 channels with live over-the-air content and
using all available TEXT and XDS streams.
There are no logic changes here. It's just moving code around and removing
the "internal" part of names where no longer required.
PiperOrigin-RevId: 245407238
The AndroidX bundled version (0.42) lags behind the most up-to-date public
release (0.44) making it more difficult to stay close to the actual head
revision which is used internally.
PiperOrigin-RevId: 244848568
This ensures we keep the loading period in sync with the the playing period in
PlybackInfo, when the latter changes to something new.
PiperOrigin-RevId: 244838123
Experiments show this is beneficial for rebuffers with only minor impact
on battery usage.
Configurations which explicitly set a minimum buffer duration are unaffected.
Issue:#2083
PiperOrigin-RevId: 244823642
Before this change we'd release the audio track and create a new one as soon
as audio processors had drained when reconfiguring.
Fix this behavior by stop()ing the AudioTrack to play out all written data.
Issue: #2446
PiperOrigin-RevId: 244812402
- We had buildAddRequest and sendNewDownload. Converged to
buildAddDownload and sendAddDownload.
- Also fixed a few more inconsistencies, and brought the
action constants into line as well.
PiperOrigin-RevId: 244274041
- Listener based reporting of progress allows the content length
to be persisted into the download index (and notified via a
download state change) as soon as it's available.
- Moved contentLength back into Download proper. It should only
ever change once, so I'm not sure it belongs in the mutable part
of Download.
- Made a DownloadProgress class, for naming sanity.
PiperOrigin-RevId: 244242487
