Android + HarmonyOS Automation: A Unified Configuration Tutorial for Mixed Matrices

A row of Android phones sits on the desk, and a few HarmonyOS phones have just been added beside them. The first instinct is usually: do I need a second system, one process per platform, one log per platform?

Not really. The least troublesome approach is one central control, two groups. Once devices are connected, the only differences are the connection method and the script operation layer; grouping, parameters, task dispatch, and logs can all be managed together.

The one place that genuinely goes wrong is this: putting devices from both platforms into one group. The script goes out, a HarmonyOS device runs into Android locating logic, and the log only tells you it failed - you can dig for ages before realizing the grouping crossed over. What follows sets up a mixed matrix step by step.

1. Define the Directory and Naming Rules Before You Touch Any Device

This chapter looks like formalism, but in a mixed matrix it pays back the most. When one device goes wrong, you need to answer “which platform, which batch, which machine” within three seconds.

Here is a naming rule worth adopting:

android-a-01   // Android, group A, device 1
android-a-02
harmony-a-01   // HarmonyOS, group A, device 1
harmony-a-02

The prefix marks the platform, the middle letter is the batch or content direction, and the last two digits are the index. Do not use default serial numbers as device names - a serial number tells you nothing about the platform and cannot indicate a group at a glance.

Keep asset directories separated by platform too:

media/
  android/2026-09-24/
  harmony/2026-09-24/
content/
  android-copy.txt
  harmony-copy.txt

If some content goes to both platforms, add a shared/ directory for the common assets and let the script pull from it by config. Once the directories are set, swapping content, archiving, and reuse all follow the same rules. And do not change the rules midway - change them once and every earlier log and record no longer lines up, which makes troubleshooting harder, not easier.

2. How to Connect Android Devices

The Android side has three main channels. Pick by your desk setup:

Channel	Prerequisite	Best for
USB mirroring	Data cable + ADB debugging enabled on the phone	Fixed devices, stability matters most
ADB WIFI	Enable network debugging over USB first, then go wireless	Cutting the cable, medium device count
LAN WIFI mirroring	EC APK on the phone, broadcast scanning (8178)	Scaling up, no cables
WAN mirroring	Port forwarding + NAT traversal	Devices and PC on different networks

Before connecting, remember to turn on automation in the central control toolbar - that is what lets mirroring and scripts run. Android 5+ connects, and HarmonyOS 1.0-4.0 devices fall within this same set of channels, so older HarmonyOS phones can be handled alongside Android devices without a separate process.

The execution channel is the accessibility service or ADB debugging, and both are no-root. When devices are mixed, keep one batch on one channel type so troubleshooting has fewer variables. For mirroring details, see Android cluster control mirroring in practice.

3. How to Connect HarmonyOS Devices

HarmonyOS Next devices go through a different path, one that does not share the three Android channels:

1. Prepare: a Windows PC plus a HarmonyOS 5.0.0+ physical device;
2. Enable permissions: turn on Developer Mode, then USB debugging;
3. Install central control: install the central control component from the product downloader, ideally 3.0.0 or above, which brings grouping and the script sidebar;
4. Connect: link the physical device with a data cable (wireless debugging is supported too) and let central control read the device;
5. Enable automation: once the device status is normal, turn on automation;
6. Authorization binding: complete the binding as prompted and confirm the link works.

To be clear about one point: HarmonyOS Next has no root concept. Access relies on Developer Mode and USB debugging, which the system already provides, without modifying the system - the same idea as Android’s no-root approach. Once installed, run a minimal flow on one device first (open app -> tap once -> check result), and only add more once the link works. The full explanation is in the HarmonyOS cluster control guide.

4. Device Grouping: Platform First, Then Batch

Group the devices as soon as they are all connected. The order is platform first, then batch - not the other way round.

Android group
  +-- android-a (batch 1)
  +-- android-b (batch 2)
HarmonyOS group
  +-- harmony-a (batch 1)
  +-- harmony-b (batch 2)

Platform sits on the first level because scripts are adapted per platform. Grouping is the first gate: as long as the platform level never crosses over, a script will not run on the wrong system. Batch sits on the second level, and it answers “what content, when”.

This is the step most easily skipped: after grouping, batch-rename right away and confirm the names match the groups. Selecting a whole group in central control lets you dispatch a task to all of it, which is the foundation for every batch operation later.

5. Reusing Scripts and Parameters

This is the most practical question in a mixed matrix: how many times do you write the two sets of scripts?

The answer is reuse the logic, rewrite the interface:

Layer	Reusable?	Notes
Logic layer	Yes, shared	Business flow, loops, conditions, and data handling carry over wholesale
Operation layer	Needs separate adaptation	Tapping, swiping, and typing map to each platform capability
Locating layer	Needs separate mapping	Element locating is reconfirmed against each platform UI system

So neither “change nothing” nor “rewrite everything” is right - the work concentrates in the operation and locating layers. Share one parameter structure as far as possible, and split only the platform-related parts:

// 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: ['#dailyshare', '#productfinds'], // shared by both platforms
  perDevice: 1,                             // posts per device
  retry: 2                                  // retries on failure
};

Rule-type parameters (topics, posts per device, retry count) are shared, while path-type parameters are split per platform. That way the rules do not drift apart, and you are not maintaining two fully independent configs. The script authoring itself is generic - start from Write your first phone automation script step by step and then work through the interface differences per platform.

6. Task Dispatch and Execution Logs, All in One Place

Once the environment is configured, daily operation comes down to two sentences: pick a group, dispatch a task. This is where a mixed matrix pays off most - tasks for both platforms are dispatched from the same central control, and the execution logs are read in the same place. Read the log in this order:

1. Overall success rate. Start with how the batch ran as a whole, to tell normal variation from a widespread problem;
2. Break it down by platform. The success rate for the Android group and the HarmonyOS group separately. One normal and one broadly failing means the problem is basically locked to that platform’s script or connection;
3. Break it down by group. If only one batch fails within a platform, it is usually that batch’s asset paths, accounts, or device status;
4. Drill down to the device. Use the naming to find the machine, then verify on-site through mirroring.

The four-level order “overall -> platform -> group -> device” is the fastest way to read logs in a mixed environment. Jumping straight into one device’s log tends to miss problems that appear in clusters. Archive task records by batch too, keeping one batch’s logs together so later review does not mean scrolling through everything.

7. Troubleshooting Order in a Mixed Environment

Step one, look at the failure scope. Cluster failures point at the platform side first: did the script adaptation change, did the connection drop. One-off failures point at the device: cable, power, online status.

Step two, check device online status. Dropped devices usually show up in the log as a task that never ran or stopped halfway, and fixing the script does nothing for them.

Step three, verify separately. Run a minimal flow on one device (open app -> tap once -> check result). If it works, the environment is fine and the problem is the script; if it does not, the problem is the device or the connection.

Step four, cross-verify. When unsure, run the same script on another device of the same platform. Several failing means the script; just that one failing means the device.

Step five, only now touch the script. Change the script only after the first four steps have ruled everything else out. The most common misjudgment in a mixed environment is rewriting code when the device cable came loose.

8. A Delivery Checklist

Work through these in order and the mixed matrix will run steadily:

• Device naming rule settled, with platform prefix and index;
• Asset directories split by platform + date, with a separate directory for shared assets;
• Android devices connected by the channel that fits your setup, one channel type per batch;
• HarmonyOS Next devices connected via Developer Mode + USB debugging, with automation enabled and authorization binding done;
• Devices grouped by platform first, then subdivided by batch, with a batch-rename check;
• Script logic layer reused, operation and locating layers adapted per platform;
• Parameters sharing one structure, with path-type values split per platform;
• One device per platform running the minimal publishing chain end to end;
• Tasks dispatched in batches, logs read as “overall -> platform -> group -> device”;
• Asset organization following E-commerce batch automation and Short-video batch operations, and the testing scenario covered by the Mobile automation testing guide.

Managing two platforms together was never really a technical difficulty - it is classification and naming. Get those two solid and the rest is just repeated execution.

---

About EasyClick: A phone automation AI-agent platform covering Android no-root, iOS no-jailbreak (proxy / Bluetooth HID / OTG HID) and HarmonyOS Next, offering script development, Apple cluster control, local central control & mirroring, and cloud control systems. → Explore all products