Upgrade a2a-sdk to a 1.x-compatible range to unlock gRPC/REST transports, agent extensions, and proto types

[ferponse]

Summary

google-adk[a2a] currently pins a2a-sdk>=0.3.4,<0.4. The a2a-sdk 1.x line (proto-based, A2A 1.0 spec) adds a number of capabilities that ADK's A2A layer (to_a2a, RemoteA2aAgent, A2aAgentExecutor) cannot expose while pinned to 0.3.x. This is a request to move to a 1.x-compatible range so those capabilities become reachable for ADK users.

Motivation — capabilities the current pin blocks

Building an ADK orchestrator that acts as an A2A client (RemoteA2aAgent) delegating to a second ADK agent exposed as an A2A server (to_a2a), the following a2a-sdk 1.x features are unavailable while ADK stays on 0.3.x:

• Multi-transport clients. 1.x ships a real transport abstraction (a2a.client.transports: jsonrpc, rest, grpc) selectable via ClientConfig.supported_protocol_bindings / grpc_channel_factory. Today ADK's A2A path is effectively JSON-RPC + HTTP/JSON only — no gRPC binding, which matters for high-throughput / streaming agent-to-agent links and for teams standardizing on gRPC service meshes.
• Proto-based types (a2a.types.a2a_pb2). Cross-language schema parity for AgentCard / Task / Message across Python/Java/Go implementations, and the foundation for the gRPC binding.
• Agent Extensions. The A2A-Extensions header + AgentExtension on the agent card + with_a2a_extensions let agents advertise and negotiate capabilities beyond the base spec — the intended way to add features without forking the protocol. Not reachable on 0.3.x.
• Richer client architecture. ClientFactory / Client / ClientConfig with use_client_preference, polling, and per-call push_notification_config.
• Server-side scale features. Push notifications delivered across all owners, multi-tenant support (tenant_decorator), and DefaultContextBuilder.build_user for custom A2A user resolution — useful for multi-user / multi-tenant orchestrators.

Concrete breakage — mixed environments fail at import

The pin isn't only conservative; it strands anyone who co-installs a modern a2a-sdk. With a2a-sdk 1.1.0 present, both public A2A entry points fail hard at import time (not a graceful degradation):

from google.adk.agents.remote_a2a_agent import RemoteA2aAgent
  → ImportError: cannot import name 'ClientEvent' from 'a2a.client'

from google.adk.a2a.utils.agent_to_a2a import to_a2a
  → ModuleNotFoundError: No module named 'a2a.server.apps'

Cause: the 1.x refactor removed ClientEvent / ClientTaskManager / Consumers from a2a.client, and replaced the A2AStarletteApplication wrapper under a2a.server.apps with route-based endpoints (add_routes_to_app → Starlette routes).

Migration surface (for scoping)

The breaking surface is mostly on the server-construction side:

• A2AStarletteApplication wrapper → add_routes_to_app routes (affects to_a2a / A2aAgentExecutor).
• Renames: push_notification_config plural → singular; removal of ClientEvent / ClientTaskManager / Consumers.
• Well-known path: /.well-known/agent.json → /.well-known/agent-card.json (RemoteA2aAgent already reads AGENT_CARD_WELL_KNOWN_PATH from the SDK with a fallback, so this is partly absorbed).

Request

1. Move the [a2a] extra to a 1.x-compatible a2a-sdk range so gRPC/REST transports, agent extensions, and proto types become reachable.
2. Consider a clearer runtime error when an incompatible a2a-sdk is installed, so co-installed environments fail with a helpful message instead of a raw ImportError.

Happy to test the [a2a] extra against a real orchestrator ↔ A2A-server ADK setup once the range is updated.

Environment

• google-adk 2.3.0 (Requires-Dist: a2a-sdk>=0.3.4,<0.4 ; extra == "a2a")
• a2a-sdk 1.1.0 installed
• Python 3.12

[llalitkumarrr]

Hello @ferponse ,

Thank you for your request. We will review it and let you know if we require any further information. We appreciate your patience in the meantime.