Google upgraded Android's UI language, can test automation keep up?

Surya Polavarapu — Thu, 13 Aug 2026 10:48:42 +0000

On May 19, Google made it official: Jetpack Compose is now the only way forward for Android UI. The older approach of writing screens in XML, the markup language that defined app development for over a decade, is now placed in maintenance mode. No new feature launches, bug fixes only. 

For most developers, this landed as good news. Compose is genuinely better to build with: less code, faster iteration, cleaner architecture. So most of the attention since has been on what developers gained and barely anything on what happens to the test suites!

What actually changed under the hood

To understand why this matters for quality teams, it helps to know what automation tools have always relied on.

Android testing frameworks typically found elements on screen using identifiers: resource IDs, class names, positions in a structure called the View hierarchy. Every button, text field, and screen element in an XML-based app lives in that hierarchy. Your test says "find the element with ID btn_checkout" and the framework finds it.

Compose doesn't produce Views. It produces a semantics tree - a structure closer to how a screen reader navigates an app than to how traditional layouts worked. These are two different models.

Appium can interact with Compose, but not in the way most teams currently have it set up. It requires switching to the UIAutomator2 driver specifically - not the Espresso driver - and it only works if developers have explicitly added testTag modifiers to Compose elements and enabled testTagsAsResourceId in the app configuration. Those are deliberate, manual steps that someone on the engineering side has to take for every element that needs to be reachable by a test.

Most teams migrating existing apps to Compose haven't done this. The result is a test written to find btn_checkout by its resource ID will silently fail on a Compose screen - not because the button disappeared, but because the element it was looking for no longer exists in that form. Tests stop finding elements and the suite starts failing. So when teams are quickly rewriting UI code, they are quietly invalidating years of recorded test steps, locators, and automation logic

The same problem we solved for Flutter is now arriving for the Android native ecosystem

This isn't a new class of problem. Flutter introduced a version of it years ago, and it was worse. Flutter renders entirely on its own canvas, bypassing the native UI framework completely. UIAutomator2 sees nothing. XCUITest sees nothing. There is no View tree, and no semantics tree accessible through standard drivers. The only reliable paths are Flutter Driver - which only works on debug builds, not release ones.

At QApilot, we built our proprietary layer using advanced methods like OCR & computer vision precisely because standard locators find nothing. No custom framework setup or coordinate scripts - the test finds the element visually, the way a human would.

Compose is a step along the same spectrum. The accessibility layer is still reachable if the app is configured correctly. The problem is that "configured correctly" now requires deliberate choices from the development team that most aren't making yet.

The abstraction layer we've built normalises Native, Flutter, React Native, and WebView apps into a single locator and action interface. Compose First is another reason why that kind of abstraction matters. The specific UI framework your team chose to build in shouldn't be a variable that determines whether your test suite survives a platform update. 

It's worth watching how quickly Android teams migrate. Compose adoption has been steady but slower than Google would prefer - partly because legacy codebases are large, and partly because migration comes with invisible costs that don't show up in a developer experience comparison.

DEV Community: Surya Polavarapu

Google upgraded Android's UI language, can test automation keep up?