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
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
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"
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
But RPA workflows need to survive small layout changes.
Use visible labels instead:
hs tap "Download"
hs wait "Saved"
When labels repeat, tighten the selector:
hs tap 'Button:has-text("Download")' --visible --unique
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"
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
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"
When a push opens the app:
hs wait com.example.app --timeout 15s
hs wait "Approve" --timeout 15s
hs tap "Approve"
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
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
- How to Automate Android Without Appium
- Fast Android UI Automation with ADB
- How to Run Mobile QA Tests Without Rooted Phones
Originally published at https://handsets.dev/blog/mobile-rpa-android-without-root/.
