[Feat]: Add Android support for A2A HTTP Client and decouple JdkA2AHttpClient (v0.3.x)

[sherryfox]

Is your feature request related to a problem? Please describe.

Problem

Currently, the A2A Java SDK hardcodes the use of JdkA2AHttpClient in several places (such as A2A.java and various transport providers). This client relies on java.net.http.HttpClient, which is not available in standard Android environments, making the SDK unusable on Android.
Additionally, when running on Android, Jackson fails to deserialize Java records properly without explicit property annotations, leading to parsing errors for spec models.

Describe the solution you'd like

Proposed Solution

• SPI Pattern: Introduce A2AHttpClientFactory and A2AHttpClientProvider using Java's ServiceLoader (SPI) to dynamically load the best HTTP client available on the classpath.
• Android Client: Implement AndroidA2AHttpClient using HttpURLConnection (which is safe for Android).
• Jackson Fixes: Add @JsonProperty annotations to records in the spec/ module to ensure they can be parsed on Android.

Describe alternatives you've considered

No response

Additional context

Goal

The goal is to make the http-client module compatible with Android by:

1. Decoupling the HTTP client implementation so it is not hardcoded to the JDK client.
2. Providing an Android-compatible HTTP client implementation.
3. Fixing the Jackson parsing issues for records on Android.

Code of Conduct

• I agree to follow this project's Code of Conduct

[ehsavoie]

We have a SPI for HttpClient (at least in main) since we support also a vertx http client implementation. Maybe we can backport that part.

There is a branch for 0.3 with gson instead of jackson for serialization that is going to be used in main for retro compatibility: https://github.com/ehsavoie/a2a-java/tree/gson

[sherryfox]

For SPI, I used the implementation from main as a reference (cherry-picking would have caused too many conflicts due to package refactoring, so I took a manual approach to adapt it).

I have also just aligned the provider structure to match main.

There is one major difference remaining: in main, the factory falls back to JdkA2AHttpClient if no provider is found. This is problematic for Android, so I updated it to orElseThrow as a better "fail-fast" approach for Android.

Lastly, I see that the extensive refactor to move to Gson is in your fork (and it looks like it was already merged into main). Are you planning on backporting/merging it to the 0.3.x branch anytime soon as well?

[ehsavoie]

Maybe the Android HttpC Client could be an 'extras' in the main branch.
If it makes sense we could produce such a version, I would have to ensure that I didn't break everything
@kabir @jmesnil WDYT ? Should we have a 0.3 gson release with Android support ?

[kabir]

@ehsavoie Yeah, I think that makes sense. We should check we pass the 0.3 TCK first though

[sherryfox]

I ran the TCK tests (using the 0.3.x branch of the TCK repository to avoid protocol mismatches present in main) against my PR and here are the results:

• 🔴 Mandatory Tests: ✅ PASSED (31 passed)
• 🚀 Transport Equivalence: ✅ PASSED (12 passed)
• 🛡️ Quality Tests: ✅ PASSED (14 passed)
• 🎨 Feature Tests: ✅ PASSED (15 passed)
• 🔄 Capabilities: ❌ 1 failure (test_send_message_with_push_notification_config failed because the push notification config in SendMessage was ignored). This appears to be unrelated to the HTTP client changes in my PR.

Next Steps:
How would you like to proceed?
Should I port these changes to the main branch (perhaps as an extras module as suggested by @ehsavoie) and let you handle the integration into the 0.3 release?

[ehsavoie]

I think you should use the 0.3-beta3 tag as there were some changes in the 0.3.x that are talking about 0.4.

[ehsavoie]

Also I think this should be a nice addition to the main branch, do you mind adding a PR there to provide the android http client ?

[sherryfox]

Sounds great! I'll create a new PR targeting the main branch to provide the Android HTTP client there as well.

Thanks for the guidance on using the 0.3-beta3 tag! For now, I will keep the Jackson changes in the PR unless you'll merge in the gson migration there first.

[ehsavoie]

I'll do a TCK run tomorrow on 0.3 (I'm not sure if the fix to have proper failure in the CI is in). If it is ok I'll merge it and then proceed

[ehsavoie]

Branch https://github.com/ehsavoie/a2a-java/tree/0.3-workflows passes the 0.3 TCK successfully with gson instead of jackson