Android Script Development: The Full Path from Zero to a Live Run

Automating on Android no longer requires root. There are two mature channels: the accessibility service reads the UI, and ADB sends commands.

What to have ready before you start

Android automation script development is writing a js file. The file is sent to the phone over ADB and run there, or the accessibility service taps the screen directly. There is no APK to pack, no store to publish to, and no end user to integrate with. Change one line and you can see the result. The same script can be dropped onto any Android phone. If you know variables, loops, and if/else, you can start writing.

Hardware is three things: an Android phone, a USB cable, and a computer. One set is enough if you only manage one phone. For batch management, use the same model where you can. Compatibility is less work that way.

For software you can use EasyClick directly. The IDE is based on IntelliJ IDEA and installs on Windows, Mac, and Linux. It includes sample projects. Change a few parameters and they run. The phone side installs a small APK, with no root. AnJian has a lower bar, and fewer features. Auto.js suits people who want to tinker. UiAutomator2 leans toward testing, and the setup has more steps. Most people use EasyClick and configure less.

A first script in ten minutes, and a few pits to avoid

Get one run working before you talk about technique. Download and install the EasyClick IDE, open it, and create a new project with the platform set to Android. On the phone, open Settings, then About phone, tap the version number seven times, go back up into Developer options, and turn on USB debugging. Plug in the cable, click connect in the IDE, and confirm the authorization prompt on the phone. The IDE includes an “auto-tap check-in” sample, usually under Sample projects, then Android. Open it and you will see main.js. That is your first script. It looks like this:

var appPackageName = "com.example.app"; // change this to the package name of the app you want to operate

app.launch(appPackageName);
sleep(3000);

if (clickByText("签到")) {
    toast("签到成功！");
} else {
    toast("没找到签到按钮");
}

sleep(2000);
if (clickByText("确定") || clickByText("关闭")) {
    // close the popup
}

toast("搞定");

Three steps: open the app, find the two characters for check-in, and tap them. Click run in the IDE and the script executes on the phone. The phone opens the app, enters the check-in page, and taps the button.

Coordinates are the thing beginners hard-code. A button will not stay at (500, 800) forever. One app redesign and the whole thing is off. Find by text or by image:

// preferred
clickByText("继续");           // find the two characters for Continue, then tap
clickByDesc("下一步按钮");      // find by accessibility description

// avoid this
click(500, 800);               // one layout change and it taps the wrong place

A fixed sleep should not be the default either. Waiting a flat five seconds wastes time when the page is fast, and is not enough when it is slow:

// counterexample: a flat five-second wait wastes time when the page is fast and is not enough when it is slow
sleep(5000);

// wait at most ten seconds, and stop waiting once it is found
waitForElementByText("确认", 10000);

Some screens have no control text to read. Take a screenshot and let OCR read it:

var pos = findImage("confirm-button.png");
if (pos) {
    click(pos.x, pos.y);
}

If the script stops in the middle and there is no log, you do not know where it stopped. Wrap it in try-catch:

try {
    launchApp("com.example.app");
    sleep(3000);
    tapTarget();
} catch(e) {
    print("出错了: " + e.message);
    showToast("任务失败，请检查网络");
}

How to debug problems, and how to keep using it after the first run

The common failures fall into a few kinds. If the phone will not connect, check whether adb devices sees your device, whether the driver is installed, and whether USB debugging is on. If an element cannot be found, the app was usually redesigned. Switch strategy, for example image matching or OCR. If the script stops in the middle, battery saving probably killed the background process. In battery settings, set your app to unrestricted. If a tap does nothing, a popup in front is the usual cause. Add a bit of popup handling. If it is obviously sluggish, shorten the sleep, or use an async non-blocking approach.

At the start, clicking run by hand is enough. Later, add scheduling by scenario. For a timed task, use system cron or Windows Task Scheduler and trigger the script at 8 a.m. every day. Above a dozen phones, cloud control fits: one cloud panel for management, one-click dispatch, and a live view of each phone’s status. Cloud control starts at 3.11.0, with EC client 9.4.0 and later. The demo environment is at http://ecloud.devicefarm.cn/ . The account and password are both test123. That account cannot create, delete, or update. You can also use a webhook as an event trigger, and run when a notice arrives, for example an inventory check before shipping. Above a hundred phones, use iEasyClick cloud control and the visual operations panel.

Further reading

EasyClick official docs, the API reference First project tutorial, create a project from zero How the accessibility service works, the layer underneath

============================

iEasyClick official site ieasyclick.net. Phone automation across Android, Apple, and HarmonyOS.

============================

About EasyClick: A mobile automation script development platform covering three phone ecosystems: Android without root, iOS without jailbreak, and HarmonyOS. It also offers Apple script writing, Apple cluster control, Android cluster control, remote cloud control, and AI phone cluster control. → Explore all products