This doesn't affect the nullness checker or Kotlin, but it does make
weird warnings appear in Android Studio. It seems mildly preferable to
have the same spurious warnings in these files that we have in other
tests, rather than different spurious warnings.
PiperOrigin-RevId: 321173760
This removes a lot of duplication from the module configuration,
avoids divergence, and makes sure that only the important differences
to the default are visible in each module file.
PiperOrigin-RevId: 318024823
The correct order of initializing the MediaCodec should be (as per
documentation
https://developer.android.com/reference/android/media/MediaCodec#initialization)
"create -> setCallback -> configure -> start"
but the MediaCodecRenderer currently does
"create -> configure -> setCallback -> start"
MediaCodec implementations did not complain about this so far, but the
wrong sequence does not work with the MediaCodec in block mode (new mode
in Android R) and also the ShadowMediaCodec won't operate in
asynchronous mode otherwise. To initialize the MediaCodec in the correct
order, this commit adds configure() in the MediaCodecAdapter so the
MediaCodecRenderer can do:
adapter.configure(); // sets the callback and then configures the codec
adapter.start(); // starts the codec
PiperOrigin-RevId: 316127680
Guava is heavily optimized for Android and the impact on binary size
is minimal (and outweighed by the organic growth of the ExoPlayer
library).
This change also replaces Util.toArray() with Guava's Ints.toArray()
in order to introduce a Guava usage into a range of modules.
PiperOrigin-RevId: 312449093
The error type thrown when acquiring a license that has already
been released changed from MediaDrmStateException to IllegalStateException
from API 29.
Update the tests to assert the correct type of error based on API version.
PiperOrigin-RevId: 308239508
Something that helps a constructor always seemed a bit strange.
It's now possible to use CacheDataSource.Factory directly instead.
PiperOrigin-RevId: 307661930
- Show renderers with no tracks in EventLogger track logging
- Log renderer names in EventLogger track logging
- Add useful message to ExoPlaybackException instances (including
renderer name for renderer errors)
PiperOrigin-RevId: 302421616
This is a partial revert of <unknown commit>. The split and the order is important. For
example, as things are currently, if playback fails for a test that makes additional
assertions in onTestFinished, the visible reason the test failed is quite likely to
be one of the additional assertions, rather than the error that actually caused the
playback to fail. I think we probably also don't want to log metrics if playback
fails.
PiperOrigin-RevId: 300733109
This is one step toward following the google3's test naming convention.
See go/java-testing/getting_started#basic-test-template for details
why prefix test isn't necessary.
This CL is generated by following command
$ find -name '*Test.java' | xargs -I{} sed -i 's/^\ \ public\ void\ test\([A-Z]\)\(.*\)$/ public void \L\1\E\2/' {}
PiperOrigin-RevId: 300537212
Currently only one access unit can be written per
buffer write. This has been found to be power
inefficient in an offload situation.
#exo-offload
PiperOrigin-RevId: 294886188
Currently, resetting the internal state related to the codec in done in 4 places
in MediaCodecRenderer:
1. In the constructor to set some sensible initial default.
2. In flushOrReleaseCodec to reset state after flushing
3. In releaseCodec to reset state to default values for a released codec.
4. In initCodec to reset state to defaul values for a new codec.
There are actuall only two types of state reset operations:
1. Resetting state for a released codec, so that a new codec isn't influenced by
previous codecs.
2. Resetting state after flushing an existing codec. This is a subset of (1).
So to simplify the class, this change moves all state resets to two methods
corresponding to the two cases above.
PiperOrigin-RevId: 285731913
Some methods marked as throwing DecoderQueryException actually
did not throw it. Switch to marking throws Exception
everywhere.
PiperOrigin-RevId: 277674401
DrmSessionManagers may now be in released state, in which case they
may release their MediaDrm. In that case, it would be invalid to
forward method calls to the underlying MediaDrms. Users should
instead call these methods directly on the MediaDrm.
Issue:#4721
PiperOrigin-RevId: 270963393
Inline invocations of these methods, which still leaks the MediaDrms.
However, it will be fixed once the DefaultDrmSessionManager API is finalized
and ExoMediaDrm.Providers are introduced.
Issue:#4721
PiperOrigin-RevId: 270681467
