SDK / exoplayer

A subsequent change will deprecate CronetEngineWrapper and move
all of the logic into a utility class for obtaining a suitable
CronetEngine.

This change also deprioritizes use of unknown cronet providers.

PiperOrigin-RevId: 381051164

PiperOrigin-RevId: 381021014

The way CronetDataSource.Factory can internally fall back to another
factory is confusing and unnecessary. In the case the application cannot
instantiate a CronetEngine, it should directly use another factory.

This makes CronetDataSource more consistent with OkHttpDataSource. In
both cases, their factory constructors take the component that the
respective libraries advise should only be created once by the application,
which are CronetEngine and OkHttpClient respectively.

CronetEngineWrapper will be deprecated in a subsequent change.

PiperOrigin-RevId: 381016504

PiperOrigin-RevId: 381016088

Before this change the `Format` on the image track output by the
`JpegExtractor` doesn't have a MIME type.

PiperOrigin-RevId: 381015819

Equivalent to onPlayerError, except it's also called for null.

PiperOrigin-RevId: 381015336

Previously, a SocketTimeourException is used to signal the end of the stream
that is caused by "no RTP packets received for a while". However, such
signaling is inappropriate under TransferRtpDataChannel, or FakeRtpDataChannel
in RtspPlaybackTests.

Hence, the signaling of end of stream is changed to use RESULT_END_OF_INPUT.
The RtpDataChannel implementations will Still block until a set timeout, but
will return a C.RESULT_END_OF_INPUT should a timeout occur, instead of
throwing a nested SocketTimeoutException.

This also allowed customization of the timeout amount, in
RtspMediaSource.Factory

PiperOrigin-RevId: 380981534

Those test are no longer flaky since the test clock
was made deterministic.

The removed assertions were introduced in https://github.com/google/ExoPlayer/commit/a4ad351fb15b60080ff53b345563e3f922464251.

PiperOrigin-RevId: 380793961

The current FLAG_REQUIRE_FORMAT documentation states: If an end of
stream buffer would be read were the flag not set, then behavior is
unchanged.

PiperOrigin-RevId: 380792251

The current FLAG_REQUIRE_FORMAT documentation states: If an end of
stream buffer would be read were the flag not set, then behavior is
unchanged.

PiperOrigin-RevId: 380781976

After this change, multiple BaseURL elements are parsed, but the player still only uses the first BaseURL element appearing in the manifest and its corresponding availabilityTimeOffsetUs.

PiperOrigin-RevId: 380775256

Amend release note for https://github.com/google/ExoPlayer/commit/46bc49a4f6e8194ddb28e7b17eb775157c3e241d.

PiperOrigin-RevId: 380766548

Issue: #9086
#minor-release
PiperOrigin-RevId: 380756562

The problem occurs when the primary media playlist URL switches
from one whose latest snapshot has not yet got the ended tag, to
one whose latest snapshot already has the ended tag. In this case:

- We trigger a redundant load of the ended playlist.
- When the redundant load completes,
  MediaPlaylistBundle.processLoadedPlaylist detects that the
  playlist is unchanged from the one it already has, and so
  doesn't call onPlaylistUpdated.
- PrimaryPlaylistListener.onPrimaryPlaylistRefreshed is never
  called with the new primary. Hence the externally visible primary
  is still the one that hasn't ended. HlsMediaSource therefore thinks
  the event hasn't ended, which in turn prevents the player from
  transitioning to the ended state.

This commit detects when the new primary already has the ended tag.
In this case, we call onPrimaryPlaylistRefreshed directly and remove
the unnecessary playlist load.

Issue: #9067
#minor-release
PiperOrigin-RevId: 380680532

The glitches were introduced in:
https://github.com/google/ExoPlayer/commit/6c31e34528

The problem is that Listener.onEvents is called in a later looper iteration
than the listener methods that were previously used. This created a gap on
the main thread between the UI component dispatching a seek operation to the
player, and onEvents being called to update the progress bar's position.

At the start of this gap the progress bar is rendering the new position,
but its position member variable is still set to the old position. If the
progress bar is re-drawn by another message on the main thread within the
gap, it will briefly show the old position until onEvents is called.

There are multiple possible fixes to this, and the best one is probably to
modify ListenerSet to remove the gap. That's high risk though, so for now we
fix the flicker by always updating the progress immediately after the seek
is dispatched, in addition to when onEvents is called.

Issue: #9049
#minor-release
PiperOrigin-RevId: 380678388

#minor-release

PiperOrigin-RevId: 380655806

Issue: #9061
PiperOrigin-RevId: 380640601

And replace it with factory method which includes more
context for error code assignment.

PiperOrigin-RevId: 380624625

This change parses the entire BaseURL element including DVB extension attributes, stores it in an instance of new BaseUrl class and puts it in a list of base URLs of the resulting Representation. The base url handling itself is still the same, which means that only the first base url is taken into account, just as before this change.

PiperOrigin-RevId: 380609495

This softens the language around suppressing individual test methods.
There are some legitimate cases where this is needed, e.g.
ByteArrayDataSourceContractTest has to suppress all the tests related
to non-existent resources because it's not possible to simulate that
case.

#minor-release

PiperOrigin-RevId: 380570017

Some server will wrongly insert duplicated attributes. We used to treat this as
a unrecoverable error, but it is better to treat the duplicated attributes in
an "over-writable" fashion like HashMaps.

Issue: #9080,
Issue: #9014
PiperOrigin-RevId: 380547079

* Constructors and methods with the same name should appear sequentially with no other code in between, even when modifiers such as static or private differ between the methods. Please re-order or re-name methods.
  (see http://go/bugpattern/UngroupedOverloads) (2 times)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

PiperOrigin-RevId: 380544425

*** Original commit ***

Target demo apps to API level 30

***

PiperOrigin-RevId: 380542402

#minor-release

PiperOrigin-RevId: 380531272

The test prepare_withSupportedTrack_playsTrackUntilEnded

- sets up the supported AAC track with the RTSP server;
- uses RtpPacketTransmitter to send RTP packets from the server to the client;
- runs the player until the playback has ended, and
- asserts on the data RTSP has received and queued to the SampleQueue.

In the test, it was necessary to create a FakeUdpDataSourceRtpDataChannel. The
reason we cannot reuse TransferRtpDataChannel is, we rely on BlockingQueue.poll
timeout to identify the end of an RTSP stream, but the time out mechanism is
unstable in Robolectric. For example, when the timeout is set to 8,000 ms, the
actual timeout occasionally happens after 2,000,000 ms (in FakeClock).

PiperOrigin-RevId: 380528710

Also change to explicitly track the provisioning session, which makes
the code easier to reason about than always using the zero'th element
of the list.

PiperOrigin-RevId: 380181453

Allows for compatibility with METADATA_KEY_COMPILATION.

PiperOrigin-RevId: 380179505

PiperOrigin-RevId: 380176846

PiperOrigin-RevId: 380174672

Also avoid mentioning that those fields cannot be null, since they are primitives.

PiperOrigin-RevId: 380169988

This is the package that CacheDataSource and CacheDataSourceTest(2) are
in.

PiperOrigin-RevId: 380156879

If google3 is the source-of-truth for this third_party code (or if this is legacy code that is no longer synced with an external source), just LGTM this CL and Rosie will submit it. If not, you should patch the upstream source of these files, since we will be disabling support for /-as-division in google3 before support is formally removed from the language.

See go/lsc-slash-as-division-deprecation.

Tested:
    TAP found no affected targets. No targets were built or tested.
    http://test/OCL:380056637:BASE:380052721:1623976139468:f2fd2cbd
PiperOrigin-RevId: 380140762

In prepare_withSupportedTrack_sendsPlayRequest(), the DESCRIBE includes two
tracks, one AAC and one MP4A-LATM. The test is run until a PLAY is sent, and
asserts on only one SETUP is sent (for AAC).

In prepare_noSupportedTrack_throwsPreparationError(), the DESCRIBE includes one
track: one MP4A-LATM. This format is not supported at the moment, so the player
will throw out an error, on which we assert.
PiperOrigin-RevId: 380131458

PiperOrigin-RevId: 380009757

PiperOrigin-RevId: 380000589

PiperOrigin-RevId: 379962022

In preparation for the onPlayerError callback to take a PlaybackException.

PiperOrigin-RevId: 379939108

PiperOrigin-RevId: 379935363

Issue: #8960

#minor-release

PiperOrigin-RevId: 379922704

#minor-release

PiperOrigin-RevId: 379913814