DEV Community

Elliot Gao
Elliot Gao

Posted on • Originally published at handsets.dev

Mobile RPA on Android Without Root

#android #rpa #automation #testing

Mobile RPA usually starts with a simple sentence:

We need to do the same thing in this Android app every day.

Maybe it is checking an account. Maybe it is downloading a report. Maybe it is entering a code, reading a status, or moving data between an app and an internal system.

If the app has no API, automation falls back to the UI.

You can automate many Android app workflows without root. The trick is to keep the workflow close to what a human sees: tap labels, fill fields, wait for screens, and save evidence when something breaks.

Quick answer

A no-root Android RPA flow can look like this:

hs use
hs go com.example.app
hs wait "Sign in" --timeout 15s
hs fill "Email" "$APP_EMAIL"
hs fill "Password" "$APP_PASSWORD"
hs tap "Continue" --visible --unique
hs wait "Dashboard" --timeout 20s
Enter fullscreen mode Exit fullscreen mode

It runs through normal Android debugging access. No root. No custom ROM. No app integration.

Why root is the wrong default

Root can make automation powerful, but it also changes the device.

For business workflows, that is often a problem:

  • The device no longer behaves like a normal user device.
  • Some apps detect rooted environments.
  • Security assumptions change.
  • Maintenance becomes harder.
  • Enterprise teams get nervous.

If the workflow can be driven through visible UI, start there.

Model the workflow as states

Good mobile RPA scripts are not just tap sequences. They are state transitions:

Launch app
Wait for Sign in
Fill credentials
Tap Continue
Wait for Dashboard
Open Reports
Download file
Capture confirmation
Enter fullscreen mode Exit fullscreen mode

In shell:

hs go com.example.app
hs wait "Sign in"
hs fill "Email" "$APP_EMAIL"
hs fill "Password" "$APP_PASSWORD"
hs tap "Continue"
hs wait "Dashboard"
Enter fullscreen mode Exit fullscreen mode

The wait commands are as important as the actions. They make the workflow resilient to slow devices and network delays.

Prefer labels over coordinates

Coordinate automation is tempting:

adb shell input tap 540 860
Enter fullscreen mode Exit fullscreen mode

But RPA workflows need to survive small layout changes.

Use visible labels instead:

hs tap "Download"
hs wait "Saved"
Enter fullscreen mode Exit fullscreen mode

When labels repeat, tighten the selector:

hs tap 'Button:has-text("Download")' --visible --unique
Enter fullscreen mode Exit fullscreen mode

If there are multiple matches, --unique fails instead of tapping the wrong one.

Capture proof

Business automation needs evidence.

At the end of a successful run:

hs see --size 768 "/tmp/run-success.jpg"
hs ui > "/tmp/run-ui.txt"
Enter fullscreen mode Exit fullscreen mode

On failure:

ARTIFACTS="/tmp/mobile-rpa-$$"
mkdir -p "$ARTIFACTS"
trap 'hs ui > "$ARTIFACTS/ui.txt"; hs see --size 768 "$ARTIFACTS/screen.jpg"; hs logs --tail 200 > "$ARTIFACTS/logs.txt"; echo "$ARTIFACTS"' ERR
Enter fullscreen mode Exit fullscreen mode

That gives you a screenshot, a UI dump, and recent logs for debugging.

Handle OTP and notification flows

Many mobile workflows involve one-time passwords, push notifications, or deep links.

When the app shows a code field:

hs wait "Enter the code"
hs fill "Code" "$OTP_CODE"
hs tap "Verify"
Enter fullscreen mode Exit fullscreen mode

When a push opens the app:

hs wait com.example.app --timeout 15s
hs wait "Approve" --timeout 15s
hs tap "Approve"
Enter fullscreen mode Exit fullscreen mode

The important part is still the same: wait for real UI state instead of sleeping.

Where LLM agents fit

Some RPA workflows are too variable for a fixed script.

An LLM agent can help decide the next action when the screen changes. But the tool surface should still be small:

tap   Button    "Approve"  #approve  540,860
fill  EditText  "Code"     #otp      540,640
Enter fullscreen mode Exit fullscreen mode

The agent should choose labels and actions, not raw pixels. That keeps the run auditable.

Limitations

No-root mobile RPA still follows Android's security model.

Some things may require device-owner policy, app integration, or root:

  • Reading private app data.
  • Bypassing secure windows.
  • Changing protected system settings.
  • Automating apps that intentionally block accessibility.

For many workflows, though, visible UI automation is enough.

FAQ

Can Android RPA run without root?

Yes. Many Android workflows can be automated without root by using ADB, visible UI labels, text input, waits, screenshots, and logs.

Is this the same as Appium?

No. Appium is a full mobile testing framework. A CLI workflow with Handsets is smaller and better suited to scripts, RPA jobs, and agent loops.

Can this run on real devices?

Yes. It works on real Android devices and emulators as long as adb can reach the device.

What should I log for compliance?

At minimum: start time, device/session id, action timeline, final status, screenshots for important states, and logs around failures.

Related guides

Originally published at https://handsets.dev/blog/mobile-rpa-android-without-root/.

Top comments (0)