Add HarmonyOS phones beside the Android phones and you can keep using the same central control, split into two groups. After the devices are connected, the connection method and the script operation layer differ, while grouping, parameters, task dispatch, and logs can be viewed together. If devices from both platforms sit in one group, a HarmonyOS device runs Android locating logic, and the log only shows a failure.
Set the names and directories first, then connect the devices
When one device has a problem, the name has to show the platform, the batch, and the index. Names can be set like this:
android-a-01 // Android, first device in group A
android-a-02
harmony-a-01 // HarmonyOS, first device in group A
harmony-a-02The prefix separates the platform, the middle letter is the batch or the content direction, and the last two digits are the index. Do not use the default serial as the device name. A serial does not show the platform, and it does not tell you the group at a glance. Split the asset directories by platform too:
media/
android/2026-09-24/
harmony/2026-09-24/
content/
android-copy.txt
harmony-copy.txtContent that both platforms publish gets a shared/ directory for the common assets, and the script fetches them from the configuration. Once the rules are set, do not rename in the middle of a run. After a rename, old logs no longer match the new names.
The Android side has three main channels. Pick by what the desk allows:
| Channel | Preconditions | Fits |
|---|---|---|
| USB mirroring | Data cable + ADB debugging on the phone | Devices stay put, and you want the steadiest link |
| ADB WIFI | Open network debugging over USB first, then switch to wireless | You want to drop the cables, medium quantity |
| LAN WIFI mirroring | EC APK on the phone, broadcast scan (8178) | Scaling up, no cable |
| WAN mirroring | Port mapping + intranet penetration | Device and computer are on different networks |
Before connecting, turn automation on in the central-control toolbar, or mirroring and scripts cannot run. Android 5 and later can all connect. HarmonyOS 1.0 through 4.0 devices use this same set of channels and can be handled together with the Android devices. The execution channel is the accessibility service or ADB debugging, and both are no-root. Use one channel for a given batch of devices, so troubleshooting has one less variable. For mirroring detail, see Android cluster-control mirroring in practice.
HarmonyOS Next does not share those three Android channels. A Windows PC plus a real HarmonyOS device on 5.0.0 or later: turn on Developer Mode and USB debugging, install the central-control components with the product downloader (3.0.0 or later is recommended, with the group and script sidebars), connect the real device with a data cable, and wireless debugging is supported too. After the central control reads the device, turn automation on, then finish authorization binding as prompted. HarmonyOS Next does not rely on root. Connecting uses the system’s own Developer Mode and USB debugging, and it does not modify the system. After install, run the minimal flow on one device first: open an app, tap once, look at the result. Once that works, add it to the device pool. The full write-up is in a look at the HarmonyOS cluster-control setup.
Grouping, script reuse, and task dispatch
Group devices as soon as they are connected. Platform first, then batch:
Android group
├─ android-a (batch one)
└─ android-b (batch two)
HarmonyOS group
├─ harmony-a (batch one)
└─ harmony-b (batch two)Scripts are adapted per platform, so the platform is the first layer. If the platforms do not cross, a script will not run on the other locating system. The batch is the second layer, used to separate what is published and when. After grouping, do one batch rename and check that names and groups match.
Logic can be shared. Operations and locating are rewritten per platform:
| Layer | Can it be reused | Notes |
|---|---|---|
| Logic layer | Can be shared | Business flow, loops, conditions, and data handling are reused as a whole |
| Operation layer | Needs separate adaptation | Taps, swipes, and typing connect to each platform’’s capabilities |
| Locating layer | Needs a separate pass | Element locating is confirmed again against each platform’’s UI system |
The work is in the operation layer and the locating layer. Parameters share one structure, and paths that depend on the platform stay apart:
// matrix.config.json
module.exports = {
platforms: {
android: {
group: 'android-a',
mediaDir: './media/android/2026-09-24',
copyPool: './content/android-copy.txt'
},
harmony: {
group: 'harmony-a',
mediaDir: './media/harmony/2026-09-24',
copyPool: './content/harmony-copy.txt'
}
},
topics: ['#日常分享', '#好物记录'], // shared by both platforms
perDevice: 1, // items per device
retry: 2 // retries on failure
};Topics, items per device, and retry count share one copy. Paths are split by platform, so you do not have to maintain two fully independent configs. Script writing starts from write your first mobile automation script, step by step, then the interfaces for each platform.
Day-to-day work is selecting a group and dispatching a task. Both platforms dispatch from the same central control, and the execution log is in the same place. Read the log as overall, platform, group, then single device: look at the overall success rate first, then split by platform. One side normal and the other failing across the board means you check that platform’s script or connection first. Inside one platform, only one batch failing means you then check that batch’s asset path, accounts, or device state. The name is what finds the specific device at the end. Reading only one device’s log at the start misses a failure that is happening in a block.
How to troubleshoot in a mixed environment, and the rollout checklist
Troubleshoot in this order. Step one, look at the failure scope: a block of failures checks the platform side’s script adaptation and connection first, and a one-off failure checks that machine’s cable, power, and online status first. Step two, look at online status. A dropped device often shows in the log as a task that never ran, or a run that stopped halfway, and editing the script does nothing for it. Step three, run the minimal flow on one device. If it runs through, the problem is in the script. If it does not, the problem is the device or the connection. Step four, run the same script on another device of the same platform. Failure on several devices is the script. Failure on only one device is the device. Step five, only then edit the script. A loose cable sending you into the code is the most common misread in a mixed environment.
Check these items before rollout: the device naming rule is set, with a platform prefix and an index; asset directories are split by platform plus date, and shared assets have their own directory; Android devices pick a channel by conditions, and one batch uses one channel; HarmonyOS Next devices connect with Developer Mode plus USB debugging, automation is on, and authorization binding is finished; devices are grouped by platform first and then by batch, and a batch rename has been checked; the script logic layer is reused and the operation and locating layers are adapted per platform; parameters share one structure and path-like values are split by platform; each platform has one device that has run the minimal publish chain; tasks are dispatched in batches, and the log is read as overall, then platform, then group, then single device. For how assets are organized, see e-commerce batch automation and short-video batch operations. For the testing side, see the mobile automation testing guide.
Put both platforms in one central control, and separate the names and the groups first. With a platform prefix in the name and groups split by platform, later dispatch and troubleshooting line up with the devices.
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
Ready to build it for real?
Every approach in this article can be built with EasyClick capabilities on iEasyClick — full documentation, developer tools and automation products, free to try.