jellyfin
ExoPlayer: Use cronet where available
Cronet supports HTTP/3 and is better suited for streaming over lossy networks than Android's built-in stack. It's also recommended for this use case. This commit adds a soft dependency on Cronet from Google Play Services and falls back to the previously used implementation if it's not available.
I don't know how a soft dependency on Google Play Services affects the libre build or if 16 MB in-memory cache is acceptable. Therefore, I welcome any feedback.
Sorry but we're not interested in using exoplayer-cronet. It adds the google play services library in the dependency chain which is proprietary and closed source. The only exception we've made to allowing proprietary stuff is for chromecast until there is a better alternative (open-source implementation).
I like the idea and appreciate the work you put into this, but I'm equally concerned about the additional propietary Google library. I'm not decided yet on our propietary build flavor with cast support, but we definitely cannot use this in the libre build.
How about trying the embedded cronet implementation though? That seems to be fully open source, but at the cost of increasing the APK size by 8 MB (which should be ok, but I cannot decide that myself).
If I understand this correctly, the issue is that cronet exoplayer extension depends on com.google.android.gms:play-services-cronet (https://github.com/google/ExoPlayer/blob/dev-v2/extensions/cronet/build.gradle#L23) which is released under the Android SDK License, probably with no source code available. Cronet itself is open source. We could probably replace it with https://mvnrepository.com/artifact/org.microg.gms/play-services-cronet-core which is under Apache 2 license. I don't know if you can override dependencies of dependencies in gradle or we'd have to fork the extension.
Alternatively, we can switch to OkHttp ExoPlayer extension. It supports HTTP/2, and you can plug in the embedded cronet library without adding a dependency on Google Play Services. Would you find this acceptable, @Maxr1998 ?
Personally I'd prefer using okhttp instead yes. Our SDK uses okhttp too.
All right, I switched it to OkHttp and cronet-embedded and it doesn't depend on any Google Play Services. The apk is significantly bigger now, though.