Also rename hasPrevious/Next to hasPrevious/NextWindow for consistency.
This makes it clearer what the difference between
seekToPrevious/NextWindow and seekToPrevious/Next is.
PiperOrigin-RevId: 384643373
The types (open/close/read) does not provide extra information about the thrown
playback exception, and they are not utilized at higher levels.
PiperOrigin-RevId: 384219870
* @ImaAdState is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs.
(see go/java-style#s4.8.5-annotations)
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: 383121587
- Use `PlaybackException.ErrorCode` IntDef for `DataSourceException` error code
- Deprecate `DataSourceException.POSITION_OUT_OF_RANGE`
- All other changes are related to replacing the deprecated constant and
constructor
PiperOrigin-RevId: 382683522
Until now, we have stuck with the 3.12 long-term branch so as
to keep support for older API levels. However, this means that
the version we're using is 2.5 years old at this point. The
3.12 branch will stop receiving critical updates in December
2021.
Since use of the OkHttp extension is optional anyway, it seems
preferable to move to a modern version of OkHttp at this point.
PiperOrigin-RevId: 381465269
Currently when a HTTP POST request receives a 302, CronetDataSource will change the request method from POST to GET for the redirected request, and drop the post body. This aligns with the behaviours of many user agents, but our use case would like to keep the POST method and the post body.
org.chromium.net.UrlRequest.followRedirect also changes POST to GET for 302, so should be avoided here.
PiperOrigin-RevId: 381233011
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
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
More information: go/checker-3130-lsc
Tested:
Some test failures are present, but the CL author has decided to mail the change anyway
PiperOrigin-RevId: 379622938
