{{ message }}
Repository navigation
[Feat]: Add Android support for A2A HTTP Client and decouple JdkA2AHttpClient (v0.3.x) #793
Description
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
A2AHttpClientFactoryandA2AHttpClientProviderusing Java'sServiceLoader(SPI) to dynamically load the best HTTP client available on the classpath. - Android Client: Implement
AndroidA2AHttpClientusingHttpURLConnection(which is safe for Android). - Jackson Fixes: Add
@JsonPropertyannotations to records in thespec/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:
- Decoupling the HTTP client implementation so it is not hardcoded to the JDK client.
- Providing an Android-compatible HTTP client implementation.
- Fixing the Jackson parsing issues for records on Android.
Code of Conduct
- I agree to follow this project's Code of Conduct
Activity
ehsavoie commentedon Apr 15, 2026
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 commentedon Apr 15, 2026
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
JdkA2AHttpClientif no provider is found. This is problematic for Android, so I updated it toorElseThrowas 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 the0.3.xbranch anytime soon as well?ehsavoie commentedon Apr 15, 2026
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 commentedon Apr 15, 2026
@ehsavoie Yeah, I think that makes sense. We should check we pass the 0.3 TCK first though
sherryfox commentedon Apr 15, 2026
I ran the TCK tests (using the
0.3.xbranch of the TCK repository to avoid protocol mismatches present in main) against my PR and here are the results:test_send_message_with_push_notification_configfailed because the push notification config inSendMessagewas 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
extrasmodule as suggested by @ehsavoie) and let you handle the integration into the 0.3 release?ehsavoie commentedon Apr 15, 2026
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 commentedon Apr 15, 2026
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 commentedon Apr 15, 2026
Sounds great! I'll create a new PR targeting the
mainbranch to provide the Android HTTP client there as well.Thanks for the guidance on using the
0.3-beta3tag! For now, I will keep the Jackson changes in the PR unless you'll merge in the gson migration there first.ehsavoie commentedon Apr 15, 2026
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 commentedon Apr 16, 2026
Branch https://github.com/ehsavoie/a2a-java/tree/0.3-workflows passes the 0.3 TCK successfully with gson instead of jackson
feat(http-client): add Android support and implement SPI for A2AHttpC…
feat(client): add Android HTTP client and remove fallback in factory (#…
Wesley273 commentedon Jun 2, 2026
I am using Spring Boot and have also encountered some deserialization issues when using classes from the standard as input parameters. For instance, I need to define additional mixins such as SecurityScheme.
ehsavoie commentedon Jun 2, 2026
@Wesley273 maybe you should use the gson version ?