Give OkHttp the application context before the Android suites run - #37
Merged
Conversation
The six public ECH cases executed for the first time on e0c7c1d, and all six failed the same way: java.lang.IllegalStateException: Unable to load PublicSuffixDatabase.list Caused by: java.io.IOException: Platform applicationContext not initialized. Startup Initializer possibly disabled, call OkHttp.initialize before test. So #33's diagnosis was wrong in mechanism. The asset was missing and adding `okhttp-android` did ship it, but that was only half: the list is read through a `Context` that nothing here ever supplied. `DnsOverHttps` asks `isPrivateHost` about the name before opening anything, so all six died there, upstream of any TLS — the runs said nothing about ECH. `okhttp3.internal.platform.PlatformInitializer` is declared in the merged androidTest manifest via androidx Startup, and it still didn't run. Rather than work out why an initializer inside an instrumentation APK stays dormant, set the context outright, in the runner, where it covers every suite and happens once. Verified as far as it can be without an emulator: the APK assembles and the merged manifest names the new runner — <instrumentation android:name="okhttp.testbed.android.ech.EchTestRunner" Not claimed: that this makes the public suite pass. It removes the failure that stood in front of ECH; what those six cases then say about API 37 is the result we have never had. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CqiK79k9uoWsn2AzgXpHMA
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
main is red on
android-ech, and the run that turned it red is the first useful one this suite has produced.The retry worked
On
e0c7c1dthe install raced as before, and this time the retry from #35 caught it:Six cases executed — the first time that has ever happened.
All six failed for a reason that isn't ECH
#33's diagnosis was wrong in mechanism. The asset genuinely was missing and adding
okhttp-androiddid ship it — but the list is read through aContextthat nothing here supplied.DnsOverHttpsasksisPrivateHostabout the name before opening a connection, so all six died upstream of any TLS handshake. The runs said nothing about ECH either way.Worth noting:
okhttp3.internal.platform.PlatformInitializeris declared in the merged androidTest manifest through androidx Startup, and it still didn't run. Rather than work out why an initializer inside an instrumentation APK stays dormant, this sets the context outright in the runner, where it covers every suite including ones added later and happens once rather than per test.Verification
What can be checked without an emulator, checked:
:android-ech:assembleDebugAndroidTestsucceeds.<instrumentation android:name="okhttp.testbed.android.ech.EchTestRunner"— a wrong runner name here is what would produce another zero-test run.Still open, and not addressed here
The gating fixture suite failed separately on the same run:
EncryptedClientHelloTest.rejectedConfigIsRetriedWithServerConfigFAILED, and the instrumentation process crashed with 2 of 3 completed. That suite passed 3/3 on earlier runs, and the log carries no assertion detail because the process died. It is a different failure from the one fixed here, I don't yet know its cause, and this PR does not claim to fix it. It is the thing keepingandroid-echred.This change removes the failure standing in front of ECH. What the six cases then say about API 37 is the result this repo has never had.
Generated by Claude Code