esedark
Android phone beside a development workstation

android / appium / uiautomator2 / real devices

Appium for Android: a practical guide to automating real apps

A stable Appium system controls device state, uses semantic selectors, records evidence and stops safely when the app changes.

Appium is useful for testing Android applications and running authorised repetitive workflows on devices you control. It is not permission to bypass access controls, platform rules, rate limits or user consent. Define allowed actions and data retention before connecting the first phone.

Understand the execution path

Your client sends WebDriver commands to Appium. UiAutomator2 translates them into Android actions through ADB. Failures can therefore come from the client, server, driver, transport, Android or application. Pin compatible versions of Appium, UiAutomator2, SDK tools and the client library. Give every device a unique ADB serial and session port. See UiAutomator2 explained for backend developers for the driver layer.

Make device state deterministic

Start every run with a documented state: screen awake, known orientation, expected locale and timezone, sufficient battery, stable connectivity and the correct app version. Decide explicitly whether application data is reset. Verify package, activity, permissions and free storage before accepting a job.

When several devices are involved, allocate work through a queue. On shutdown, capture the final screen and release the session. Quarantine a phone after repeated infrastructure failures instead of returning it immediately to the pool.

Use stable selectors and meaningful waits

Prefer accessibility IDs, then resource IDs. Text selectors need locale handling; long XPath expressions tied to the view hierarchy are fragile. Wrap screens in page objects so selector changes have one repair point. Wait for visible or enabled states rather than using fixed sleeps.

Recover without hiding defects

Classify transport errors, device faults, app defects, invalid input and workflow changes. Retry only safe, idempotent operations. Before repeating a submission, inspect the screen or system of record to avoid duplication. Capture a screenshot, page source, safe log excerpt, device serial, app version, correlation ID and last step—never passwords, tokens or unnecessary personal data.

Common mistakes

  • using XPath for every element
  • sharing one port across parallel sessions
  • assuming identical device state
  • using fixed sleeps
  • retrying submissions without reconciliation
  • mixing workflow logic with selectors
  • logging credentials
  • running unlimited actions
  • upgrading drivers without compatibility tests

Practical checklist

  • document authorisation and data boundaries
  • pin Appium, UiAutomator2 and SDK versions
  • assign unique serials and ports
  • verify package, activity and device health
  • prefer semantic selectors
  • use page objects and explicit waits
  • make retries bounded and state-aware
  • capture safe diagnostics
  • monitor success, latency and availability
  • provide pause, quarantine and manual review

When hiring a technical person makes sense

Hire a specialist when a prototype must become a maintained device service, several models run concurrently, or failures affect customers. A technical owner designs allocation, recovery, secrets, metrics and upgrade tests. The challenge is operational stability, not making Appium tap once.

Final takeaway

Good Appium automation produces repeatable, explainable runs on controlled devices. To turn a fragile mobile script into a traceable service, review my technical services or contact me.