Android 14 HttpEngine support

[yschimke]

The following test fails using the HttpEngine api

import android.content.Context
import android.net.http.HttpEngine
import androidx.test.core.app.ApplicationProvider
import assertk.assertThat
import assertk.assertions.contains
import java.net.URL
import org.junit.Test
import org.junit.runner.RunWith
import org.robolectric.RobolectricTestRunner
import org.robolectric.annotation.Config

@RunWith(RobolectricTestRunner::class)
@Config(
  sdk = [34],
)
class HttpEngineTest {

  @Test
  fun testHttpEngine() {
    val context = ApplicationProvider.getApplicationContext<Context>()
    val x = HttpEngine.Builder(context).build()

    val con = x.openConnection(URL("https://google.com/robots.txt"))

    val robots = con.getInputStream().bufferedReader().readText()

    assertThat(robots).contains("Disallow")
  }
}

error

java.lang.RuntimeException: Expected Cronet version number 114.0.5735.84, actual version number null.
	at android.net.connectivity.org.chromium.net.impl.CronetLibraryLoader.ensureInitialized(CronetLibraryLoader.java:63)
	at android.net.connectivity.org.chromium.net.impl.CronetUrlRequestContext.__constructor__(CronetUrlRequestContext.java:197)
	at android.net.connectivity.org.chromium.net.impl.CronetUrlRequestContext.<init>(CronetUrlRequestContext.java:192)
	at android.net.connectivity.org.chromium.net.impl.NativeCronetEngineBuilderImpl.build(NativeCronetEngineBuilderImpl.java:32)
	at android.net.http.ExperimentalOptionsTranslatingHttpEngineBuilder.build(ExperimentalOptionsTranslatingHttpEngineBuilder.java:305)
	at android.net.http.HttpEngine$Builder.build(HttpEngine.java:511)
	at okhttp3.android.HttpEngineTest.testHttpEngine(HttpEngineTest.kt:39)

Ideally it would work using a cronet build for the platform. Or alternatively this call might fallback to URLConnection, but that wouldn't be ideal.

[hoisie]

Ideally it would work using a cronet build for the platform

That would be great but would be a highly complex project.

[yschimke]

@hoisie does it have to be complex? Can we choose a simpler option for now?

This works (I'm using cronet API, not HttpEngine) with the Java fallback

    val engine = JavaCronetProvider(ApplicationProvider.getApplicationContext()).createBuilder().build()

    val con = engine.openConnection(URL("https://google.com/robots.txt"))

    val robots = con.getInputStream().bufferedReader().readText()

    assertThat(robots).contains("Disallow")

  implementation("org.chromium.net:cronet-fallback:119.6045.31")

Should I put up a PR and see?

[utzcoz]

@yschimke A new PR for future discuss is good. Does cronet-fallback library support Windows and macOS arm64?

[hoisie]

If enabling the fallback is simply a matter of projects adding org.chromium.net:cronet-fallback:119.6045.31 as test runtime dependencies, should we add a page to robolectric.org with this documentation?

[yschimke]

I think there is some plumbing required. But the APIs match so I hope it's fairly simple

[fridek]

A few points here:

• Cronet is not built for Windows and macOS. It is not to say it is not buildable, just that it doesn't have an .so in these architectures now. Don't get fooled by x86 build, that's for Android C runtime and it won't trivially run elsewhere.
• cronet-fallback would not work with gRPC and other cases where bidirectional streaming is used. cronet-embedded offers the full functionality and can be statically linked for testing (if you solve the problem above).
• Isn't roboelectric expected to not send actual requests? I'd assume a better way forward is to build a shadow for HttpEngine?

[hoisie]

@fridek thanks for the additional context 👍

It is understandable that Cronet is not built for Windows and MacOS by default, that would add unnecessary development overhead for your team. The same is true for Android's SQLite and graphics targets. Robolectric has a custom AOSP branch that enables Windows and MacOS builds for these targets. We try to upstream changes wherever possible, and we collaborate with the LayoutLib team as they have similar goals (essentially building libandroid_runtime on host platforms).

I don't think there is a requirement to use GRPC in Robolectric at the moment. This would be a complex project and we have a lot of other projects in the pipeline at the moment. However, due to recent advances in graphics, teams are now running larger and larger tests in Robolectric, and we are trying to work towards supporting larger integration-style tests. The resource savings of migrating tests to Robolectric are considerable.

[yschimke]

I'm not blocked on this.

More raising it for discussion. If you decide it shouldn't be supported, then your collective call.

For me, I'd expect to be able to hit a test or mock server as part of my tests. And would be annoyed to give up robolectric testing to use HttpEngine.

Robolectric can now run a "native" display, with "native" sqlite, and works with OkHttp or URL connection to a test server.

[yschimke]

It seems like a small override of https://cs.android.com/android/platform/superproject/main/+/main:external/cronet/android/java/src/android/net/http/HttpEngine.java;drc=b520a15dc110253cf27b170fa7ac103fafcebade;bpv=1;bpt=1;l=382

Or a shadow apps can apply? might unblock the non GRPC cases.