Journeys for Android Studio, powered by Gemini AI and integrated via AGP Test Suites, replaces brittle Espresso and UI Automator selector-based E2E tests with natural language intent-driven testing. Instead of hardcoded testTags or resource IDs, developers write XML step descriptions describing user goals, and a multimodal vision-reasoning engine interprets screenshots to compute taps, swipes, and assertions. The piece covers how the underlying screen-capture-to-Gemini-to-ADB pipeline works, rules for writing unambiguous journey steps, Gradle/AGP 9.0+ setup for CI execution, and where Journeys fit in a testing pyramid alongside unit and Compose tests.
Table of contents
Stop Writing Brittle Espresso and UI Automator TestsHow Journeys Work Under the Hood1. Declarative Intent over Hardcoded SelectorsThe Old Way: Espresso / Compose Test RuleThe Modern Way: Android Studio Journeys XML2. Eliminate Ambiguity to Tame Non-Deterministic ExecutionGet Dilipchandar ’s stories in your inboxRules for Writing Reliable Journeys:3. Running Journeys in CI/CD via AGP 9.0+RequirementsGradle Setup ( build.gradle.kts )CLI Execution for Continuous Integration4. When to Use Journeys vs. Traditional Test FrameworksKey Takeaways for Android TeamsQuestions this post answers
What is Journeys for Android Studio and how does it differ from Espresso testing?
Journeys is an AI-driven end-to-end UI testing feature in Android Studio, powered by Gemini and integrated via AGP Test Suites, that replaces hardcoded element selectors with natural language step descriptions. Instead of referencing testTag or resource IDs like Espresso does, you write XML steps such as tapping a field and verifying a total updates, and Gemini's vision engine interprets screenshots to compute taps, swipes, and assertions. daily.dev surfaces practical breakdowns like this for teams evaluating AI-driven UI testing approaches.
What are the requirements to run Journeys tests in Android Studio and CI?
Journeys requires Android Studio Otter 3 Feature Drop or later with Journeys enabled under Settings, Studio Labs, plus Android Gradle Plugin 9.0.0 or higher and a Google Developer Account signed in with Gemini access. Tests are configured through the testSuites DSL in build.gradle.kts and can run headlessly in CI environments like GitHub Actions or Firebase Test Lab via gradlew runJourneys. developers wiring AI-based UI testing into CI pipelines track setup details like these on daily.dev.
How does the Journeys AI testing engine decide where to tap on the screen?
The engine captures a high-resolution screenshot plus lightweight semantic metadata from the device, sends the frame along with the natural language instruction to Gemini's vision engine, which computes precise spatial coordinates and an interaction type such as a tap at specific x,y coordinates or a scroll amount. The gesture executes via ADB/UI Automator, then the engine waits for the screen to stabilize before capturing the next frame and verifying success. engineers debugging flaky UI test runs can dig into pipelines like this one on daily.dev.