10 Commits

Author SHA1 Message Date
kak
2202397758 Automated Code Change
PiperOrigin-RevId: 660491742
2024-08-07 12:28:25 -07:00
ibaker
e150e0d39f Remove OkHttpDataSource constructors & OkHttDataSourceFactory
Use `OkHttpDataSource.Factory` instead.

PiperOrigin-RevId: 636585523
2024-05-23 10:03:12 -07:00
ibaker
4986fdd1a6 Remove deprecated setContentTypePredicate() methods
Use the suggested alternative on the respective
`XXXDataSource.Factory` instead.

PiperOrigin-RevId: 636560182
2024-05-23 08:32:26 -07:00
ibaker
7f5b1a98e9 Use Guava's toByteArray & fromByteArray methods where possible
Also remove intermediate object allocations in
`Util.toByteArray(int...)`.

`Util.toByteArray(InputStream)` is kept (but deprecated) because it's
been part of the library for a while and might be in use by some apps.
The others are much newer, so the chance of usages outside the library
is very low, so we just remove them directly.

PiperOrigin-RevId: 613878453
2024-03-08 03:27:29 -08:00
tonihei
ed5b7004b4 Replace or suppress deprecated usages
Many usages are needed to support other deprecations and some
can be replaced by the recommended direct alternative.

Also replace links to deprecated/redirected dev site

PiperOrigin-RevId: 601795998
2024-01-26 10:06:18 -08:00
ibaker
2deb435625 Annotate methods that always return this with @CanIgnoreReturnValue
It's always safe to ignore the result of these methods, because the
caller already has a reference to the returned value.

PiperOrigin-RevId: 462388947
2022-08-08 07:55:25 +00:00
yschimke
80928e730c Workaround for OkHttp Interrupt issues.
Relates to https://github.com/square/okhttp/issues/3146. This was from https://github.com/androidx/media/pull/71.

There is a draft PR https://github.com/square/okhttp/pull/7185/files which documents OkHttp's ideal handling of cancellation including interrupts.

But a few key points

1) This is a target state, and OkHttp does not currently handle interrupts correctly.  In the past this has been identified, and the advice is to avoid interrupts on Http threads, see discussion on https://github.com/square/okhttp/issues/1902. Also an attempt at a fix here https://github.com/square/okhttp/pull/7023 which wasn't in a form to land.

2) Even with this fixed, it is likely to never be optimal, because of OkHttp sharing a socket connection for multiple inflight requests.

From https://github.com/square/okhttp/pull/7185

```
Thread.interrupt() is Clumsy
----------------------------

`Thread.interrupt()` is Java's built-in mechanism to cancel an in-flight `Thread`, regardless of
what work it's currently performing.

We recommend against using `Thread.interrupt()` with OkHttp because it may disrupt shared resources
including HTTP/2 connections and cache files. In particular, calling `Thread.interrupt()` may cause
unrelated threads' call to fail with an `IOException`.
```

This PR leaves the Loader/DataSource thread parked on a countdown latch, while this may seem wasteful and an additional context switch. However in practice the response isn't returned until the Http2Connection and Http2Reader have a response from the server and these means effectively parking in a `wait()` statement here 9e039e9412/okhttp/src/jvmMain/kotlin/okhttp3/internal/http2/Http2Stream.kt (L140)

PiperOrigin-RevId: 446652468
2022-05-09 10:59:41 +01:00
ibaker
fe8996e634 Allow stable API users to customise the DataSource used
Also stabilise the 3 HTTP-based DataSource implementations:
* DefaultHttpDataSource
* OkHttpDataSource
* CronetDataSource

PiperOrigin-RevId: 436690643
2022-03-23 10:05:27 +00:00
Ian Baker
38717ce969 Reformat some javadoc 2022-02-18 14:54:02 +00:00
Andrew Lewis
933e207b3e Update to androidx.media3
PiperOrigin-RevId: 405656499
2021-10-27 09:12:46 +01:00