UI Automator for Android Testing: A Deep Dive

UI Automator is Google's testing framework for cross-app UI testing on Android. Unlike Espresso (which tests within a single app), UI Automator can interact with any app on  device, including system settings, notifications, permission dialogs, and third party apps.

What is UI Automator? It's an instrumentation based API that finds elements on screen using selectors (resource IDs, text content, class names) and performs actions on them. It's Android only, black  box, and works without access to your app's source code. For Android teams that need to test flows involving system-level interactions, UI Automator is  standard tool.

How does UI Automator work?

UI Automator operates at  system level through Android's accessibility layer. It uses  AccessibilityService framework to read  view hierarchy of any app running on  device and interact with visible elements.

The core components:

• UiDevice represents  device itself. You use it to press buttons (home, back), rotate  screen, open notifications, and manage device state.
• UiObject2 represents a UI element on screen. You find it using selectors and then interact with it (tap, type, scroll, swipe).
• By is  selector builder. You use it to find elements by resource ID, text, class name, or content description.
• Until defines conditions to wait for before proceeding (element visible, element gone, text matches).

A basic UI Automator test in Kotlin looks like this:

@Test
fun testLogin() {
    val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())

    // Find and interact with elements
    device.findObject(By.res("com.app:id/username")).text = "user@test.com"
    device.findObject(By.res("com.app:id/password")).text = "pass123"
    device.findObject(By.res("com.app:id/login_btn")).click()

    // Wait for result
    device.wait(Until.hasObject(By.text("Welcome")), 5000)
    val welcome = device.findObject(By.text("Welcome"))
    assertNotNull(welcome)
}

‍

The test finds elements by their resource ID (com.app:id/username), types text, clicks a button, and waits for a result. This is standard selector-based testing.

What is UIAutomatorViewer?

UIAutomatorViewer (also written as uiautomatorviewer) is a visual inspection tool that ships with  Android SDK. It takes a screenshot of  device screen and shows  complete view hierarchy alongside it. You use it to find  resource IDs, text labels, and content descriptions you need for your selectors.

To use  ui automator viewer:

1. Connect your Android device via USB or start an emulator
2. Run uiautomatorviewer from  Android SDK tools/bin directory
3. Click  screenshot button to capture  current screen
4. Click on any element to see its properties (resource ID, class, text, bounds)

UIAutomatorViewer is  standard way to discover selectors for UI Automator tests. It's also used for Appium tests on Android, since Appium uses UI Automator as its backend driver.

The limitation: UIAutomatorViewer shows you what selectors exist right now. It doesn't tell you whether those selectors will still be valid next sprint when  frontend team ships a redesign. The ui automation viewer helps you write tests, but it doesn't help you maintain them.

How does UI Automator compare to other Android testing tools?

Android has multiple testing frameworks. Here's how they compare:

‍

The key takeaway: UI Automator, Espresso, and Appium all use selectors to find elements. When  UI changes, selectors break across all three frameworks. The difference between them is scope (single app vs cross-app vs cross-platform), speed, and language support.

When should you use UI Automator?

UI Automator is  right choice for specific Android testing scenarios:

• Testing flows that involve system UI (handling permission dialogs, interacting with notifications, changing device settings mid-test). These scenarios require proper test environment management because device state affects test reliability.
• Testing flows that cross app boundaries (sharing content to another app, opening a deep link that launches a different app, interacting with  app launcher)
• Black-box testing when you don't have access to  app's source code (third-party app validation, competitor testing)
• Android UI Automator testing for device-level operations (screen rotation, pressing hardware buttons, controlling WiFi/Bluetooth)

UI Automator isn't  best choice for:

• Single-app UI testing (Espresso is faster and more reliable for this)
• Cross-platform testing (UI Automator is Android-only, you'll need a separate framework for iOS)
• Tests that need to survive frequent UI changes (selector-based testing breaks when  UI changes)
• Teams that want non-technical testers to write tests (UI Automator requires Java or Kotlin)

How does Appium use UI Automator under  hood?

When you run Appium tests on Android, you're actually using UI Automator behind  scenes. Appium's UiAutomator2 driver wraps UI Automator's APIs and exposes them through  WebDriver protocol.

Here's  flow:

1. Your test sends a command via  Appium client (find element, click, type)
2. The Appium server receives  command and translates it to a UI Automator API call
3. UI Automator executes  action on  device through  accessibility layer
4. The result flows back through  same chain

This means that what is appium on Android is essentially a wrapper around what is uiautomator. The android uiautomator framework does  actual work. Appium adds cross platform support (iOS uses XCUITest as its backend), multi language support, and a standardized API.

The implication: if your UI Automator tests break because of selector changes, your Appium tests break for  same reason. The underlying technology is  same.

What are UI Automator's limitations?

Most guides focus on what UI Automator can do. Here's what it can't do, or does poorly:

Android-only. UI Automator doesn't work on iOS. If your team ships on both platforms, you need a separate testing framework for iOS (XCUITest or Appium). This means maintaining two test suites with different languages, different selectors, and different debugging tools.

Selector fragility. UI Automator finds elements by resource ID, text content, or class name. When a developer changes a resource ID,  test breaks. When a designer changes button text from "Log In" to "Sign In,"  text-based selector breaks. This is  same selector maintenance problem that affects every selector-based framework.

Slow execution. UI Automator tests run through  instrumentation layer, which adds overhead. A single test takes 5 to 15 seconds to execute. A suite of 200 tests takes 30 to 60 minutes. Compare this to unit tests that run in milliseconds.

Flaky waits. UI Automator provides Until conditions for waiting, but timing on real devices is unpredictable. Network delays, device performance variations, and animation timing all cause intermittent test failures. Teams spend time tuning wait conditions instead of writing new tests.

No visual validation. UI Automator can check that an element exists, but it can't check that  element looks correct. An element might be present in  view hierarchy but rendered off-screen, hidden behind another element, or visually broken. UI Automator won't catch these visual bugs.

What does a team's experience with UI Automator look like?

A mid-size Android team at a food delivery company built 150 tests with UI Automator over four months. The tests covered ordering, payment, delivery tracking, and push notification handling.

For  first two months,  suite ran well. Tests passed on  CI device farm. The team caught real bugs in  ordering flow and payment error handling.

Then  frontend team shipped a major UI refresh. 40% of  selectors broke. The resource IDs changed. Button text changed. The view hierarchy restructured. The SDETs spent two sprints updating selectors and fixing tests. During that time,  suite couldn't be trusted for regression.

After  refresh,  team faced a choice: keep maintaining  UI Automator suite and accept  recurring maintenance cost, or try a different approach for  test types that broke most often.

They kept UI Automator for  20 tests that genuinely needed system-level access (notification handling, permission dialogs, deep links). They moved  remaining 130 tests to Drizz, where plain English tests run on real devices using Vision AI. When  next UI refresh happened,  Drizz tests adapted automatically. The 20 UI Automator tests still needed selector updates, but 20 tests is a manageable maintenance scope.

How should you decide between UI Automator and Vision AI?

Use this framework:

For most Android teams,  practical answer is both. UI Automator for  small number of tests that need system level access. Vision AI for  larger number of tests that cover user flows and need to survive UI changes. Tools like Drizz handle  high volume user flow testing while UI Automator handles  Android-specific system interactions that only it can reach.

FAQs

What is UI Automator?

UI Automator is Google's Android testing framework for cross-app UI testing. It uses  accessibility layer to find and interact with UI elements across any app on  device, including system settings, notifications, and third-party apps. It requires Java or Kotlin and is Android-only.

What is UIAutomatorViewer?

UIAutomatorViewer is a visual tool in  Android SDK that captures a screenshot of  device screen and shows  view hierarchy. You use it to find resource IDs, text labels, and content descriptions for building selectors. It helps you write UI Automator tests but doesn't solve  selector maintenance problem.

What is  difference between UI Automator and Espresso?

Espresso tests within a single app with in-process synchronization (fast, reliable, but can't access system UI). UI Automator tests across apps and system components via  accessibility layer (slower, but can handle notifications, permission dialogs, and device settings). Use Espresso for single-app testing and UI Automator for cross-app flows.

How does Appium relate to UI Automator?

Appium uses UI Automator as its Android backend driver (UiAutomator2). When you run Appium tests on Android, your commands are translated to UI Automator API calls. Appium adds cross-platform support (iOS via XCUITest), multi-language support, and a standardized API on top of UI Automator's capabilities.

Can you use UI Automator with Python?

Not directly. UI Automator requires Java or Kotlin. For ui automator python access, use Appium with its Python client or  python uiautomator library (uiautomator python wrapper). These tools expose UI Automator's functionality through Python APIs, though with some performance overhead from  client-server architecture.

When should you use Vision AI instead of UI Automator?

Use Vision AI (like Drizz) when your tests break frequently due to selector changes, when you need cross-platform tests (iOS and Android), when non-technical team members need to write tests, or when you want tests that adapt to UI changes automatically. Keep UI Automator for tests that genuinely need system-level access (notifications, device settings, permission handling).

‍