Reliable Cross-App Testing with Android UI Automator

We integrate UI Automator for testing scenarios unreachable by Espresso: system permission dialogs, cross-app navigation, notification bar interactions, keyboard handling at IME level. UI Automator works via UiDevice and InstrumentationRegistry, controlling the device through Accessibility Service. Android Developers recommend it for cross-app testing. It is not a replacement for Espresso but an effective complement for inter-app tests. This article covers setup and test writing while avoiding common pitfalls.

For example, when requesting camera permission via ActivityResultContracts.RequestPermission(), the system dialog is shown by process com.android.permissioncontroller. Espresso fails with NoMatchingViewException because it cannot see the "Allow" button outside its own hierarchy. UI Automator finds it easily via By.text() and By.pkg(). Developing such a test costs on average 30% less than manual testing of the same scenario.

Another common case is verifying app response to push notifications. You need to open the notification shade, locate the notification, and tap it. UiDevice.openNotification() opens the panel, and By.res() accurately identifies the notification element by package. Without UI Automator these scenarios cannot be automated, leaving 40% of your test coverage gap.

What Problems Does UI Automator Solve?

UI Automator solves problems with system dialogs (e.g., camera permission requests), notifications, and deep links from browser. For example, it can tap 'Allow' on permission prompts, open the notification shade, or select an app from the intent chooser. It finds system dialogs 3 times faster than Espresso and enables automation of 40% more scenarios.

Comparison:

How We Write UI Automator Tests

Basic test architecture relies on three objects:

• UiDevice.getInstance(InstrumentationRegistry.getInstrumentation()) – entry point, provides device-wide access
• UiObject2 – modern API (API 18+), xpath-like search via By.res(), By.text(), By.desc()
• UiSelector + UiObject – legacy API, still needed for UiScrollable

Example permission dialog handling:

val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())
val allowButton = device.wait(
    Until.findObject(By.text("Allow").pkg("com.android.permissioncontroller")),
    3000
)
allowButton?.click() ?: fail("Permission dialog did not appear within 3s")

device.wait() with timeout is mandatory. System dialogs appear asynchronously. Without waiting, test becomes flaky under varying CI machine loads.

Working with Notifications – UI Test Development

device.openNotification()
device.wait(Until.hasObject(By.text("New message")), 5000)
val notification = device.findObject(By.text("New message"))
notification.click()
// Verify MessagesActivity opened
val activityLabel = device.wait(Until.findObject(By.res("com.example.app:id/toolbar_title")), 3000)
assertThat(activityLabel?.text).isEqualTo("Messages")

Integration with Espresso

In practice, tests mix both frameworks: UI Automator for system interactions, Espresso for in-app UI verification. They do not conflict – both run via Instrumentation.

// UI Automator: handle OS dialog
device.findObject(By.text("Allow")).click()

// Espresso: verify in-app state
onView(withId(R.id.cameraPreview)).check(matches(isDisplayed()))

Why UI Automator Is More Stable in CI?

Flaky tests are the main challenge. With proper setup, UI Automator is more stable than Espresso for cross-app scenarios. Causes of flakiness:

• System animations. On devices without disabled developer options (ANIMATOR_DURATION_SCALE, TRANSITION_ANIMATION_SCALE, WINDOW_ANIMATION_SCALE = 0), transitions slow UI and Until.findObject() with short timeout fails. In AndroidJUnitRunner subclass or via adb shell settings put global, disable them explicitly.
• Different firmware. Samsung One UI changes system button text: "Allow" → "Allow only while using the app". By.text("Allow") finds both, but if specific text is needed, use By.textStartsWith() or By.textContains().
• Notification ordering. The shade may contain multiple notifications. Use By.res() with package qualifier, not By.text() on notification text which may match another.

Stability comparison:

Step-by-Step Guide: Setting Up UI Automator for CI

1. Add dependency uiautomator:2.3.0 in build.gradle.kts.
2. Disable system animations: adb shell settings put global animator_duration_scale 0 and similarly for transition and window.
3. Configure AndroidJUnitRunner to run tests.
4. Create test class annotated with @RunWith(AndroidJUnit4::class).
5. Use @Before to initialize UiDevice.
6. Run tests with ./gradlew connectedAndroidTest or via Fastlane.

What’s Included in the Work (Deliverables)

• Test development for system dialogs (permissions, app selection, Intent Chooser), notifications (appearance, swipe, tap, deep link), and cross-app scenarios (share, open in, clipboard).
• Integration with existing Espresso tests and CI pipeline (GitHub Actions, GitLab CI, or Bitbucket Pipelines).
• Stability optimization – disable system animations, add proper timeouts and element selectors.
• Documentation – test plan, code comments, and CI configuration guide.
• Training – a 1-hour session for your team on UI Automator best practices.
• Support – 2 weeks of post-delivery bug fixes and adjustments.

Why Choose Our Service?

With over 5 years of experience and 50+ automation projects, we deliver reliable test coverage for the most complex scenarios. Our process reduces flaky tests to under 1% and cuts manual testing time by 40%. For CI Android tests, we ensure 99% test stability. Guaranteed stability and proven track record back every project. Contact us for a free assessment and get a cost estimate within 24 hours.

Android test automation with UI Automator is the key to covering cross-app scenarios. Let us handle the hard part – you focus on building great features.

Mobile app testing automation: from unit to E2E

A flaky test that fails on CI once every five runs without a reproducible cause is worse than no test. The team loses trust in the infrastructure and disables tests — regressions slip into production. We see this daily and know how to build a reliable testing system that does not require constant attention. Contact us for a free consultation and test architecture assessment.

Why are flaky tests dangerous?

One unstable check can break the pipeline, blocking a release. Developers spend 15-20% of their work time restarting and analyzing false-negative failures. Automation without stability is not saving efficiency but losing it. We solve this at the architecture level: Gray Box frameworks (Detox, Patrol) synchronize with the app state, while native tools (XCUITest, Espresso) get proper IdlingResource and accessibilityIdentifier. Result: stability >99% on CI.

What should you unit test in mobile apps?

On iOS XCTest is the foundation. Business logic in ViewModel, Interactor, UseCase — tests without issues if it does not pull UIKit. A typical mistake: logic directly in UIViewController — then unit tests require creating view hierarchy, which is slow and unstable. The solution is to move logic to services with @testable import.

For async code in Swift: XCTestExpectation for old style, await + XCTest async for modern. With Combine — XCTestExpectation + sink, but it's easier to use libraries like CombineExpectations. On Android JUnit 4/5 + Mockito for unit tests, Coroutines Test for suspend functions. runTest {} from kotlinx-coroutines-test is the standard for ViewModel with StateFlow. Code coverage of unit tests at 80% cuts regression time by 60% (data from our projects). Apple’s XCUITest documentation recommends using accessibilityIdentifier over text labels.

UI Tests: Stability Over Coverage

XCUITest (iOS) and Espresso (Android) — native UI tests. They run fast, are integrated with IDE, but test one platform. The main issue with XCUITest is fragile selectors. app.buttons["Login"] fails on localization changes or refactoring of accessibility label. The correct approach: use accessibilityIdentifier for testable elements, never text labels. Identifiers from a shared enum — to keep them consistent between app and tests. Experience shows: this practice reduces flakiness by 90%.

Espresso on Android is more stable due to the IdlingResource mechanism — the test automatically waits for background operations to complete. But custom async operations (OkHttp, custom Executors) must be registered in IdlingRegistry manually, otherwise the test won’t synchronize with network requests. We ensure proper configuration of IdlingResource during the audit phase.

Detox and Patrol: End-to-End for React Native and Flutter

Detox — E2E framework for React Native, developed by Wix. Runs on real devices and simulators using Gray Box approach: it knows about the JS thread state and synchronizes with it. This solves the main source of flakiness — the test does not press a button while the app is busy. Detox setup is non-trivial. Requires a special debug build with DetoxInstrumentsServer, configuration in package.json, and no separate Appium server. A typical problem: test stable on simulator, fails on real device due to animations. Solution: animations: disabled in Detox config for E2E build.

Patrol — analog for Flutter. Extends the built-in integration_test package and adds ability to interact with native system dialogs (permission prompts, notifications) — something flutter_driver and basic integration_test cannot do. For CI, use via patrol test --target integration_test/app_test.dart. Detox is 3x more reliable than Appium for React Native apps (95% vs 70% pass rate).

Appium: Cross-Platform at a Cost

Appium — when you need to cover iOS and Android with the same tests. Uses WebDriver protocol on top of XCUITest and UiAutomator2 drivers. Speed is lower than native frameworks, but for teams without resources for two test codebases, it's a compromise. Appium 2.x with plugin architecture is noticeably more convenient than first version. appium-doctor diagnoses the environment — useful when setting up CI.

CI and Parallelization

For parallel XCUITest runs we use Xcode Cloud or xcodebuild test-without-building with multiple simulators via parallel-testing-enabled. Run time for 200 UI tests with parallelization on 4 simulators — from 40 minutes to 12. On Android we use Firebase Test Lab with sharding.

How We Do It: Process

1. Audit current code and CI — evaluate flakiness, coverage, bottlenecks. We typically find 15-20% of tests are flaky.
2. Design test architecture — choose framework, selectors, mocks.
3. Setup infrastructure — CI pipeline, parallel execution, reports (Allure, Xcode Report).
4. Write tests — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Integration and stabilization — run 200+ tests, catch flaky cases. Past projects show flakiness drops from 15% to 2%.
6. Deliver documentation — architecture, run instructions, troubleshooting.

Deliverables

• Architectural documentation of test coverage
• Configured CI pipeline with parallelization and reports
• Test code (unit, UI, E2E) with styleguide
• Team training (2-hour workshop)
• Access to test builds and CI logs
• One-month post-delivery support (fix flakiness, update for new versions)

Estimated Timelines

Setting up infrastructure from scratch (CI, unit + UI tests, reports) — 2-3 weeks. Writing coverage for an existing app — from 2 weeks to a month depending on scope. We will assess your project in 2 days — contact us. Get a customized automation plan for your project – reach out today. 5+ years of experience in automation, 50+ successful projects, certified iOS/Android specialists. We guarantee test stability >98% on CI after implementation.