🚀 Use org.chromium.net:cronet-embedded instead of com.google.android.gms:play-services-cronet

[AlexV525]

Resolves #807.

We can discuss the intention to use or not to use GMS-based dependencies further.

Cronet represent org.chromium.net instead of as part of Google Play Services. So it should be using the org.chromium.net, the implementation code in the package remains valid after the change.

[AlexV525]

@brianquinlan @natebosch

[brianquinlan]

Wouldn't this change increase the packaged size of applications significantly? A note on the exoplayer site suggests that the size increase would be ~8MB.

[AlexV525]

Wouldn't this change increase the packaged size of applications significantly? A note on the exoplayer site suggests that the size increase would be ~8MB.

Yes, but with phones that's unable to use GMS, the GMS version won't get any available instances of Cronet.

[brianquinlan]

As we discussed in the bug (#807), I think that we should have two separate packages here and the developer can decide whether they want to have a GPS dependency or not.

[AlexV525]

As we discussed in the bug (#807), I think that we should have two separate packages here and the developer can decide whether they want to have a GPS dependency or not.

So as I said in #807 (comment), a CI that writes different dependency and publish another package would be okay too. WDYT?

[brianquinlan]

In principle I like the idea! I have two concerns:

1. Whatever CI we use should be compatible with the rest of dart-lang/http (I think that there was some talk of doing automatic publishing - @devoncarew might know more)
2. That the implementation not be too hacky - were you planning on rewriting build.gradle and pubspec.yaml in the CI script?

[AlexV525]

1. Whatever CI we use should be compatible with the rest of dart-lang/http

It's easy to publish packages within a monorepo or nested repo, just need to use matrix when running jobs. See https://github.com/cfug/diox/blob/main/.github/workflows/publish.yml

2. That the implementation not be too hacky - were you planning on rewriting build.gradle and pubspec.yaml in the CI script?

Yes, that's the minimum requirement, we can run a Dart (or Shell) script during the job which won't require any manual tweak.

[natebosch]

I think we could symlink the same lib directory between two packages, and otherwise treat them like they are both independent packages. I don't have strong opinions between that and synthesizing the package during ah automated publish - but given that we don't currently have an automated publish at all, a package with symlinked content might be the best fit.

[AlexV525]

I think we could symlink the same lib directory between two packages, and otherwise treat them like they are both independent packages.

You'll have to deal with publishing scripts eventually because pub doesn't support symlink publishing.

[natebosch]

because pub doesn't support symlink publishing

It doesn't? I thought the new implementation supported them.

dart-lang/pub#2827 (comment)

If it doesn't, we can file an issue and see how hard it would be to make them work. I can't imagine it should be too hard.

[AlexV525]

If it doesn't, we can file an issue and see how hard it would be to make them work. I can't imagine it should be too hard.

dart-lang/pub#3143

[AlexV525]

I think we could symlink the same lib directory between two packages, and otherwise treat them like they are both independent packages.

And also, this will increase the complexities when maintaining two packages. Considering the current cronet adds other implementations without the symlinked, they will have to maintain with more commits.

[AlexV525]

Close in favor of #853.