Android Automation Batch Publishing Tutorial: How to Set Up and Run a Multi-Account Matrix

Get four things ready before you start

You have thirty or forty Android phones, accounts written on a few sheets of paper, and assets scattered across several folders. Every morning you open the app, switch accounts, paste copy, pick media, and tap publish, dozens of times, and by the time you look up it is already late. Teams running a matrix have all done this. A small device count is still something one person can hold. Once accounts multiply and the daily post count goes up, labor cannot keep up. After the flow is in a script, you mainly do two things: set the rules clearly, and read the results once.

When the front end gets stuck, it is usually short cables, unsorted accounts, or assets left everywhere. Spend half an hour gathering four things. On the computer, central control is least trouble on Windows. Up to ten devices, an ordinary office laptop is enough. A dozen or more plugged straight into the chassis makes power and bandwidth easy to break, and an independently powered USB hub saves a lot. On a LAN, the network card and the router have to hold every device online at once. Android phones can connect from Android 5, and HarmonyOS 1.0 through 4.0 is in range too. Keep system versions as close as you can so problems are easier to compare sideways, and leave long-running devices plugged in. Accounts have to be ones you control. Think through the use and the platform rules first. File assets ahead of time by date or theme. The script only references paths. Android-side scripts are written in JavaScript, with a smart IDE, and image search, OCR, and control search are all supported. If you can find the button by control, skip guessing screen coordinates. One UI change and coordinates are all dead. When it is written, it can also be packed into a standalone iec.

Connect devices to central control, and pick the channel by scale

Device scale	Suggested connection	Notes
1–5 devices	USB direct	Most stable, usable as soon as it is plugged in
6–20 devices	USB plus a powered hub, or LAN WIFI	Depends on desk space and cabling
More than 20	LAN WIFI as the main path	No cables, low cost to expand
Remote devices	WAN channel plus intranet penetration	The phone and the computer are not on the same network

Getting central control running is not the hard part. The choice is which channel brings the devices in. Pick the wrong one and every later day is spent fighting drops and cables. First ask whether the devices move. USB mirroring is the most stable: a data cable to the computer, ADB debugging on, and mirroring works once the device list shows a normal state. The ceiling is USB ports and cables. ADB WIFI is how you pull the cable: connect over USB, turn on network debugging, then open ADB WIFI from the device list in central control and join by scan. After that, operation matches ADB mode. LAN WIFI mirroring fits larger scale: install the EC APK on the phone, tap scan in central control, choose network scan, and use broadcast scan. After the APK receives the info it remembers the cluster-control address and connects on its own. If the scan finds nothing, check the network-card setting, or fill in the central-control computer IP by hand (port 8178). Before you use it, turn automation on in the central-control toolbar.

Devices that stay put and need stability use USB. Devices that are plugged and unplugged often, or a tight desk, use LAN WIFI. There is also an HID tap channel (USB-HID / Bluetooth HID / OTG-HID). HID does not require accessibility or adb, and OTG-HID is simpler to configure. Details are in Android cluster-control mirroring in practice.

Grouping, writing the script, pulling parameters out

Connecting the devices is only the first step. Dozens of devices named with the default serial take forever to find. Group first, then batch-rename. Group by how you will dispatch tasks later: by account batch (“batch one, publish group”, “batch two, publish group”), by content direction (“daily group”, “campaign group”), or by where the devices sit (“rack A”, “rack B”). After grouping, batch-rename with the group and index in the name, like android-a-01. When the log shows android-a-07 publish failed, you know which rack to walk to. In central control, selecting the whole group dispatches the same task to the whole group.

Before writing the script, list the steps of one complete publish, then turn them into code: open the target app and wait until the home element appears, switch to the assigned account (skip this if one phone holds one account), enter the publish entry and wait until the upload button is tappable, pick media, fill copy, add topics, tap publish and wait for the success prompt or the page change, record the result, and keep a screenshot when something goes wrong. Skip a hardcoded “sleep 3 seconds”. Wait until an element appears. Do not live on coordinates for long. Prefer control id, then text. After a failure, either retry or mark the device for a person. Do not skip it silently. One phone, one account is the least work, and the script does not switch accounts. One phone, many accounts means the switch has to be in the flow. For the basics of writing scripts, see write your first phone automation script and Android no-root automation scripts, full breakdown.

Copy changes, and assets update every day. Hardcoded in the script, you edit code and walk the flow again. Once it is in config, you edit the config.

// config.json — only this file changes for each dispatch
module.exports = {
  group: 'android-a-01',              // target device group
  copyPool: './content/copy.txt',     // copy pool, one item per line
  topics: ['#日常分享', '#好物记录'],  // topics
  mediaDir: './media/2026-09-24',     // media directory
  publishAt: '09:30',                 // dispatch time
  perDevice: 1,                       // posts per device
  retry: 2                            // retries after a single step fails
};

A new set of content then changes only mediaDir and copyPool. The script itself stays still. The copy pool is one item per line, and the script takes lines in order. Name media directories by date, archive them after the run, and the next time you look for old content you are not guessing. For how to organize assets, see e-commerce batch automation and short-video batch operations. Run the whole chain on a single device first, then go to the next step.

Batch dispatch, reading the record, and the order to check when something fails

At this step the action is simple: select a group in central control, dispatch the script and parameters, then read the execution record. Watch three things in the record:

What to watch	What it tells you
Success / failure counts	The overall ratio, and whether the problem is general or a single case
Which step the failure stopped on	The log stops on a specific action: the button was not found, or the page was wrong
Device online status	A drop is usually connection or power

Do not rush to rework devices one by one. If the same failure clusters across many devices, the script or the page usually changed. If it shows up on only one or two, check that device first. On rework, run only the failed devices. Leave the successful ones alone, so already published content is not published again. Keep the execution record until this batch is fully closed. When you need to look back mid-problem, the time and the step in the log are more reliable than memory.

Check in this order. Device will not connect: look at the status in the device list. If it is unauthorized, tap authorize on the phone. If it is offline, change the cable and the port and plug it in again. On the ADB channel, also confirm the driver. WIFI join finds nothing: confirm the phone and the computer are on the same intranet, check that the network card is the right one, and if that still fails fill in the central-control IP and port 8178 by hand. The script runs and the screen does not move: check, in order, whether automation is on, whether permissions are complete (accessibility, floating window, screenshot), and whether a dialog is in front of the target button. It can tap and lands on the wrong page: this is usually the locator. Add “wait until the element appears, then tap”, replace coordinates with control or text location, and check whether a wait is missing between page changes. One device fails over and over: disconnect it from the center and reconnect it. If that fails, run the same script on another device. That separates a device problem from a script problem immediately. Some items in the same batch never went out: first confirm that device was online at dispatch time, then check whether the asset path is wrong. This is usually unrelated to script logic.

From ten devices to several dozen, power, network, dispatch pace, and naming all change. Leave long-running devices plugged in. The hub has to supply power steadily, and do not stack the phones so they trap heat. When every device is online, LAN bandwidth and router concurrency are the bottleneck. Add devices in small batches, watch mirroring and execution delay, then decide the next batch. Do not fire every task at once. Push in batches and add volume while you watch the record. Once naming and asset filing rules are set, the next person can still read them.

---

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