Google ADK for Kotlin and Android 0.1.0: Hybrid On-Device Agent Guide

The short answer

Google’s Agent Development Kit (ADK) for Kotlin and ADK for Android 0.1.0 give Kotlin teams a code-first way to build agents that can combine cloud reasoning with on-device work. The Android artifact is designed for agents running inside Android apps, including workflows that use Gemini Nano through ML Kit GenAI APIs, while a cloud orchestrator can handle tasks better suited to a hosted model.

The most useful architecture is hybrid: keep sensitive retrieval, document extraction, and low-latency interactions on the device when possible; send only the minimum necessary context to a backend or hosted model; and keep authorization, secrets, and high-impact side effects outside the model.

This guide targets intermediate Android and Kotlin developers. It covers the release, setup, a small tool-enabled agent, hybrid orchestration, security boundaries, performance and cost trade-offs, debugging, and when ADK for Android is a better fit than a direct Gemini integration.

At a glance: ADK for Kotlin/Android 0.1.0 is an experimental foundation, not a drop-in replacement for every mobile AI feature. Use it when you need agent loops, tools, sub-agents, session state, or a cloud/on-device split. For a single prompt-and-response feature, a direct model API may be simpler.

What Google released

Google announced ADK for Kotlin 0.1.0 and a specialized ADK for Android library on May 21, 2026. The official Google Developers announcement describes Kotlin support for backend projects and Android support for agents that can run locally, use cloud models, or combine both. The release includes LLM-based, workflow-based, and custom agents; function and long-running tools; MCP and A2A integrations; plugins; session and memory services; OpenTelemetry; and a development web interface.

The Android developer documentation adds the mobile-specific contract: Android projects should use google-adk-kotlin-core-android:0.1.0, compile with SDK 34 or higher, support minSdk 24 or higher, and use Kotlin/JVM tooling compatible with the documented KSP setup. The Android artifact replaces the JVM core dependency; do not add both to the same Android module.

Google’s ADK documentation now lists Python, TypeScript, Go, Java, and Kotlin surfaces, plus agent workflows, MCP tools, evaluation, deployment, observability, and a newer ADK 2.0 section. That broader ecosystem is useful, but the Kotlin/Android 0.1.0 APIs should still be treated as an early release: pin versions, run the official samples, and test model and runtime behavior on the devices you support.

The hybrid architecture

The release is most interesting when the phone is not treated as a thin UI for a cloud chatbot. A cloud agent can coordinate the task while local sub-agents handle work that benefits from privacy, offline availability, or low latency.

Visual 1 — Hybrid agent request path. This original diagram adapts the cloud-orchestrator and on-device-sub-agent pattern described in Google’s announcement. The diagram is editorial, not an official Google architecture figure. Source: Google Developers Blog.

A travel assistant is a useful example. The cloud orchestrator can understand a complicated user request and coordinate booking-related workflows. An on-device retrieval agent can inspect a locally stored confirmation, extract the reservation number, and return only the structured fields needed for validation. The document itself does not need to leave the device.

That split is not automatically private. A tool, prompt, telemetry event, crash report, or model fallback can still leak data. Define the data boundary explicitly and test what crosses it.

Set up an Android project

The Android documentation lists Android Studio, compileSdk 34+, and minSdk 24+ as prerequisites. The following is a compact dependency shape based on Google’s documented configuration:

1plugins {
2    id("com.android.application")
3    kotlin("android")
4    id("com.google.devtools.ksp") version "2.1.20-2.0.1"
5}
6
7android {
8    namespace = "com.example.agent"
9    compileSdk = 34
10
11    defaultConfig {
12        applicationId = "com.example.agent"
13        minSdk = 24
14        targetSdk = 34
15    }
16}
17
18dependencies {
19    implementation("com.google.adk:google-adk-kotlin-core-android:0.1.0")
20    ksp("com.google.adk:google-adk-kotlin-processor:0.1.0")
21}
22
23kotlin {
24    jvmToolchain(17)
25}

This is a versioned example, not a promise that future releases keep the same plugin combination. Verify the current Android setup page before upgrading. In particular, use google-adk-kotlin-core-android in an Android module instead of also adding google-adk-kotlin-core.

Build a small tool-enabled agent

ADK’s Kotlin API uses an LlmAgent, a model configuration, an instruction, and generated tools. The official announcement shows @Tool, @Param, and .generatedTools() for exposing typed Kotlin functions to an agent. A safe starter should keep the tool deterministic and narrow:

1package com.example.agent
2
3import com.google.adk.kt.agents.Instruction
4import com.google.adk.kt.agents.LlmAgent
5import com.google.adk.kt.annotations.Param
6import com.google.adk.kt.annotations.Tool
7import com.google.adk.kt.models.Gemini
8
9class TripService {
10    @Tool
11    fun lookupTrip(
12        @Param("The user's local trip identifier") tripId: String
13    ): Map<String, String> {
14        require(tripId.matches(Regex("[A-Za-z0-9_-]{1,64}")))
15        // Replace with an authenticated repository lookup.
16        return mapOf("tripId" to tripId, "status" to "ready")
17    }
18}
19
20object TripAgent {
21    val root = LlmAgent(
22        name = "trip_assistant",
23        model = Gemini(
24            name = "gemini-flash-latest",
25            apiKey = error("Inject a protected model configuration")
26        ),
27        instruction = Instruction(
28            "Use lookupTrip only for the authenticated user's trip. " +
29                "Never invent booking details or expose document contents."
30        ),
31        tools = TripService().generatedTools()
32    )
33}

The example intentionally does not show a real client-side API key. Google’s Android guidance explicitly warns developers not to embed API keys in published apps; for production, call cloud models through your backend or use Firebase AI Logic. A local model path can reduce network exposure, but it does not remove the need for Android permissions, app authentication, local storage protection, and output validation.

Run an agent from the app

The Android documentation uses InMemoryRunner, InMemorySessionService, Kotlin coroutines, and ADK content types to invoke an agent. Keep the runner off the main thread and bind its lifecycle to a screen or application scope so a rotation or background transition does not orphan work.

1class AgentController {
2    private val sessionService = InMemorySessionService()
3    private val runner = InMemoryRunner(TripAgent.root, sessionService)
4
5    suspend fun ask(text: String): String {
6        val content = Content(
7            role = Role.USER,
8            parts = listOf(Part.fromText(text))
9        )
10        val events = runner.runAsync("user-123", "session-123", content)
11        return events.lastOrNull()?.content?.text ?: "No response"
12    }
13}

Check the exact runner method and event shape against the versioned reference before compiling: early SDKs can change signatures. In a real app, replace the hard-coded IDs with authenticated, server-issued or locally scoped identifiers, and never use a user-controlled string as a tenant or authorization identity.

Choosing local versus cloud execution

On-device execution can lower network latency and cloud token usage, but it is constrained by device class, thermal throttling, model availability, memory, and battery. Cloud execution offers more predictable capability and centralized observability, but it adds network latency, recurring inference cost, and a larger data-transfer surface. Measure p50 and p95 end-to-end latency on representative devices instead of assuming that local always wins.

Security and privacy boundaries

Treat the model as an untrusted planner. ADK can expose tools and coordinate sub-agents, but it does not make a model-generated tool call an authorization decision.

Visual 2 — Authorization sequence for an ADK mobile agent. This original sequence diagram shows the control that must sit outside the model. It is informed by Google’s Android warning about client-side keys and by the site’s Google ADK zero-trust security guide.

Use these minimum controls:

• Keep cloud credentials out of the APK. Use a backend or Firebase AI Logic for hosted calls.
• Allowlist tools and validate typed arguments server-side; do not trust tool descriptions as policy.
• Separate read tools from write, delete, payment, messaging, or permission-changing tools.
• Require an explicit approval flow for consequential actions and re-check authorization after approval.
• Redact secrets and unnecessary personal data from prompts, tool results, logs, traces, and crash reports.
• Keep local documents in protected storage and request only the Android permissions the feature needs.
• Cap tool output size, model retries, execution time, and network access.
• Treat on-device model output as untrusted input before displaying it or using it in a state mutation.

For MCP-connected tools, the same threat model applies: the MCP security threat-modeling guide explains why tool metadata, OAuth discovery, token audiences, and SSRF controls belong in the host and gateway rather than in a prompt.

Performance, cost, and observability

ADK for Android’s main performance advantage is routing. A small extraction or classification can stay on the device, while difficult reasoning can escalate to a hosted model. The cost advantage depends on how often escalation occurs and whether local work increases battery or thermal pressure.

Track at least:

• time to first visible response and total completion time;
• local versus cloud route percentage;
• model, device, Android version, and network type;
• token usage and retry counts for hosted calls;
• battery and thermal impact for longer local runs;
• tool error, cancellation, and approval rates;
• redacted input/output sizes and fallback reasons.

ADK’s documentation lists telemetry and OpenTelemetry support, but instrumentation is not a license to collect raw private documents. Define a retention policy and sample high-volume traces. Test process death, airplane mode, rotation, background execution, duplicate submissions, and partial cloud failure.

Common errors and debugging

Adding both Kotlin core artifacts. Android should use the Android-specific core dependency. Remove the JVM core artifact from the Android module.

Calling the model on the main thread. Use coroutines and a lifecycle-aware scope. A blocked UI thread creates ANRs and makes cancellation unreliable.

Leaking a key in the APK. Assume anything shipped in the client can be extracted. Move hosted inference behind a backend or Firebase AI Logic.

Trusting generated text as structured state. Make tools return typed values, validate them, and reject missing or out-of-range fields before a write.

Assuming local means private. Review logs, analytics, crash reporting, model fallback, clipboard use, and every network call.

Copying an early API example without pinning versions. Lock the ADK, KSP, Kotlin, and Android Gradle Plugin versions in CI, compile the official sample, and upgrade one dependency at a time.

Ignoring lifecycle cancellation. Cancel agent work when the owning UI scope disappears unless the operation is deliberately persisted as a background job with its own user-visible state.

FAQ

Is ADK for Android the same as calling Gemini Nano directly?

No. Gemini Nano is a model/runtime capability; ADK adds agent abstractions such as tools, instructions, sub-agents, runners, sessions, and workflows. Use the smaller direct API when you only need a bounded inference call.

Can an Android agent use cloud and local models in one workflow?

Yes. Google’s release is specifically positioned around hybrid orchestration: a cloud agent can delegate selected tasks to on-device sub-agents, including local retrieval and sequential work.

Is version 0.1.0 production-ready?

It is an experimental initial release. It may be useful for controlled pilots, but production adoption should include pinned dependencies, device-matrix tests, offline and lifecycle testing, security review, and an upgrade plan.

Should I put business authorization in the agent instruction?

No. Instructions can guide behavior, but authorization belongs in typed tools, backend policy, identity checks, approval gates, and database constraints.

Conclusion

ADK for Kotlin and ADK for Android 0.1.0 make a credible case for mobile agents that are more than cloud chat screens. The strongest pattern is a deliberate split: cloud models coordinate complex work, while on-device agents handle private, local, or latency-sensitive tasks. The framework supplies useful agent and tool primitives, but developers still own the difficult parts—secrets, authorization, lifecycle, observability, data minimization, and failure handling.

Start with one narrow workflow, one typed tool, and one explicit data boundary. Benchmark it on real devices. Add cloud escalation only when the local path cannot meet the quality or latency target. That approach will produce a safer pilot and a clearer decision about whether ADK should become part of the app’s long-term architecture.

Sources and visual credits

• Google Developers Blog: Announcing ADK for Kotlin and ADK for Android 0.1.0
• Android Developers: Build ADK agents for Android
• Google ADK documentation
• Visual 1: original Mermaid diagram by Essa Mamdani, adapted from Google’s hybrid orchestration description; source credit: Google Developers Blog.
• Visual 2: original Mermaid sequence diagram by Essa Mamdani; informed by Android ADK security guidance and Google ADK Zero-Trust AI Agents Security Guide.