There’s still a stack of Android phones from last year in the corner of the storeroom, and this year’s HarmonyOS phones on the desk — and the same colleague manages both. Two tool sets installed, two ledgers kept, two interfaces to switch between during inspections. That’s what a mixed matrix looks like when it shows up.
Here’s the thing: nobody designed it. It piles up naturally out of purchasing rhythm and business change. And the hard part isn’t whether you can manage it — it’s whether you manage it cleanly. Two tools, two ledgers, two scripts sounds like one extra piece of software. What it really means is double the operational work. Below we’ll lay out the path to unified management, and also draw the line for when you shouldn’t bother unifying at all.
1. How a Mixed Matrix Happens
Break it down and a mixed device situation usually comes from three directions:
One: devices replace themselves naturally. Existing Android phones aren’t due for retirement yet, and HarmonyOS has a rising share of new purchases. The pool isn’t replaced, it’s layered — and the system versions inside it get steadily messier.
Two: the business needs to cover both device types. For teams doing content distribution, the same task may need to run on different device types. For teams doing app testing, the compatibility matrix has an Android row and a HarmonyOS row by definition.
Three: management costs get scattered. One tool for Android, one for HarmonyOS. Two device ledgers, two inspection routines, two interfaces to check logs in. With a handful of devices you can tolerate it. Once you’re at dozens, the person responsible spends most of their time switching tools rather than managing devices.
Stack those three together and the conclusion is clear: the devices are mixed, but the way you manage them shouldn’t split with them.
2. Three Layers of Unified Management: Devices, Tasks, Assets
“Unified management” is easy to say vaguely. Broken down into something executable, it’s three separate things that each get unified.
Device layer: unified access, unified naming, unified grouping.
This is the most basic layer and also the easiest to get messy. The actions are: give every device the same naming rule (model + number + owner), build groups by platform and business line, and inspect online status and battery on one board. There’s one hard rule here — grouping has to split by platform first. Mix devices in one group and task dispatch, log collection and result sorting all go wrong.
Version ownership for HarmonyOS devices needs particular care: HarmonyOS 1.0 to 4.0 devices use the Android-side channels, while HarmonyOS 5.0.0 and above, the Next generation, use the HarmonyOS plan. Fail to split along that line and you can’t even say clearly which channel a device belongs to, and scripts get attached to the wrong devices.
Task layer: unified orchestration, scripts maintained per platform.
What the task layer unifies is “what to send, to whom, and when” — not “how it executes.” At the management level, a batch publishing task should be one definition: target device group, bound script, incoming parameters, execution time. Whether the group is Android or HarmonyOS, and how the script works internally, is each script’s own business.
In other words: unified task entry point, platform-specific execution layer. This boundary is the one most often misread as “so the scripts get merged too.”
Asset layer: one asset library, one parameter entry point.
Assets, copy, hashtags and covers — whatever device they eventually go to — should live in the same asset library with a consistent naming rule, and a traceable mapping between assets and tasks. Parameters are pulled from the library; scripts only handle the flow.
Leave the asset layer un-unified and the same content gets maintained in two places. Change it once and you have to change it twice, and mistakes creep in.
3. A Workable Path: One Central Control, Two Platforms
The path itself isn’t complicated. Central control supports unified access, grouping and mirroring across platforms; the key is handling the platform differences at each stage.
| Stage | Android devices | HarmonyOS devices |
|---|---|---|
| Access method | USB mirroring, ADB over Wi-Fi, LAN Wi-Fi mirroring, WAN mirroring | Data cable to real device (Developer Mode + USB debugging); wireless debugging supported |
| Input channel | Accessibility service, ADB, plus USB-HID / Bluetooth HID / OTG-HID | Driven by central control mirroring |
| Script system | JavaScript + smart IDE | JavaScript / TypeScript + smart IDE |
| Grouping | Grouping by platform and business line, batch rename, online inspection | Same, with grouping and script sidebar from 3.0.0+ |
| Mirroring board | Central control mirroring UI | New mirroring UI from 3.1.0+, integrating PPOCR-v6 OCR |
Four things to handle up front:
- Leave headroom on the central control computer. Mirroring two platforms at once adds up on CPU, memory and network bandwidth. Stress test at real scale before you add devices, and don’t hand the job to an old office machine.
- Don’t write scripts assuming one shared set of channels. Android has three channels — accessibility, ADB and HID — while HarmonyOS goes through the mirroring driver. Their location methods and operation interfaces differ. When you write a script, be explicit about which device type it serves.
- Handle licensing and drivers separately. Android licensing is one-off; a new computer or a system reset means re-licensing. HarmonyOS licensing is bound more tightly to the device, and status can change after you switch connection methods. The two ledger types can live together, but the recorded fields need to be separate.
- Keep a version ledger. System versions in the pool keep changing, so which devices run which channel and which version a script supports has to be lookupable. Otherwise every troubleshooting session starts by re-confirming the same facts.
The full principles behind Android’s three channels are in Android No-Root Automation Scripts Explained and the HarmonyOS side is covered in How to Do HarmonyOS Cluster Control.
4. Rules to Set Before You Scale
Whether unified management holds up long term depends on whether the rules get set while the device count is still small. Think these five through now:
| Rule | What it says | Why it matters |
|---|---|---|
| Group naming | platform_business-line_batch, for example harmony_shortvideo_0924 |
Dispatching a task no longer requires deciding whether a given device should be included |
| Script ownership | One script per platform; never share across platforms | Prevents the hidden failure mode where things look like they run but elements locate wrongly |
| Assets and parameters | Stored in one asset library with consistent naming; parameters read from it | Change content without touching scripts; both platforms share one content source |
| Execution records | Where logs and failure screenshots are kept, how often they’re reviewed, how failures are made up | Without records, the more devices you have the harder maintenance gets |
| Expansion check | What a new device must clear before joining a group (channel verification, licensing, version registration) | Prevents devices joining the pool in a broken state whose problems only surface at scale |
Of the five, the one most often skipped and least safe to skip is the script ownership rule. The most common failure in a mixed matrix is someone taking a shortcut and running an Android script directly on HarmonyOS devices. The device connects, the script starts, and the element locations are completely wrong — and the failure is not easy to diagnose.
Once the rules are set, there’s one more operational suggestion: write them into the onboarding checklist. Rules maintained from memory degrade. Rules enforced by a checklist stay stable.
5. Unified vs Separate: Where the Cost Difference Really Is
The two routes have different cost structures. The difference sits mainly in people and maintenance, not in the software itself.
| Cost item | Unified management (one central control) | Separate management (two tool sets) |
|---|---|---|
| Tooling | One central control, one licence | Two tools, two licences |
| Device ledger | One ledger with fields split by platform | Two ledgers that drift out of sync |
| Inspection routine | One board covering every device | Two interfaces inspected separately |
| Script maintenance | Still one script per platform | Also two scripts |
| Troubleshooting | Logs and mirroring in one interface, comparable side by side | Interfaces don’t match, so troubleshooting means switching back and forth |
| Computer requirements | Needs headroom, so slightly higher cost | Lower load per platform, lower spec needed |
Two things fall out of that table.
First, script maintenance costs land in a similar place either way. However many tool sets you run, the HarmonyOS script and the Android script each need their own copy. That’s decided by the platform difference, and unifying the tools doesn’t solve it.
Second, unified management removes duplicated operational work — ledgers, inspections, troubleshooting, expansion. When you have few devices, there isn’t much of that work to begin with, so the benefit is limited. Once you’re at dozens of devices and inspection becomes a daily routine, the advantage shows up clearly.
So the decision line can be drawn concretely:
- One platform only, or fewer than ten devices on the other: running two setups is fine. Get the plan you already have on solid footing first.
- Both platforms at twenty-plus devices, maintained by the same team: unified management pays off clearly, and it’s worth merging devices and processes together.
- Devices spread across sites and needing remote management: unified management is basically mandatory, because otherwise the ledgers for off-site devices simply won’t line up.
6. Deployment Advice
Take deployment in three steps; the pace matters more than the plan.
Step one: take inventory. List every device and sort by system version: which are Android, which are HarmonyOS 1.0 to 4.0 (Android side), and which are HarmonyOS 5.0.0 and above. Then pick out your three highest-frequency batch tasks — usually content publishing, device initialisation and status inspection. Once the inventory is done, device count and task count are both obvious, and only then does a cost estimate have a basis.
Step two: pilot. Choose one task that covers both platforms and run it on 3 to 5 devices from each. The thing most often missed here is that the point of a pilot isn’t efficiency — it’s validating the chain: do the channels connect, is the script stable, can the logs localise a failure.
Step three: scale. When you expand, add devices by group and fill in the ledger, inspection and failure-handling processes as you go. The most common mistake at this stage is adding devices without adding process — inconsistent group naming, a stale ledger — and sliding back into managing everything in one mixed pile.
Teams that already have mature batch scenarios can borrow the task breakdown from Mobile Batch Automation for Cross-Border E-Commerce and Mobile Batch Automation for Short-Video Matrices and Livestream Operations. A mixed matrix orchestrates tasks the same way; it just adds a grouping constraint by platform.
7. A Few Misconceptions
Misconception one: thinking unified management means unified scripts. What’s unified is devices, task orchestration and assets. Scripts must be maintained separately per platform, and mixing them is the most hidden source of failure.
Misconception two: throwing devices from both platforms into one group. When a group holds devices on two different channels, dispatch produces tangled logs and failure localisation is basically guesswork.
Misconception three: grabbing any old machine for central control. Mirroring two platforms at once stacks resource usage, and an underpowered machine shows it first as a laggy picture, then as script timeouts — which sends troubleshooting in the wrong direction.
Misconception four: unifying the tools without unifying the process. Installing the tool solves half the problem. If naming rules, ledger updates and failure handling stay inconsistent, things get messy again before long.
Misconception five: ignoring where older HarmonyOS belongs. Planning HarmonyOS 1.0 to 4.0 devices as if they were Next leads to the wrong channel and the wrong script, and troubleshooting burns a lot of time.
8. FAQ
Q1: Does a mixed matrix really need unified management? A: It depends on your device mix. With one platform and a few dozen devices, two separate setups work. If you run both Android and HarmonyOS under one team, unifying saves you a second ledger, a second set of inspections and a second troubleshooting path.
Q2: Can one central control manage Android and HarmonyOS at the same time? A: Yes. Central control supports unified access and grouping across platforms — Android through the no-root channels, HarmonyOS 5.0.0 and above through the HarmonyOS channel — and both can be managed online together.
Q3: Does unified management mean the scripts get unified too? A: No. Scripts must be maintained per platform, because HarmonyOS and Android differ in element location and operation interfaces. What’s unified is the device, task orchestration and asset layers.
Q4: Which side manages older HarmonyOS 1.0 to 4.0 devices? A: The Android side. Those versions have a compatibility relationship with the Android ecosystem and use the Android no-root channels; only HarmonyOS 5.0.0 and above uses the HarmonyOS plan.
Q5: What does unified management require from the central control computer? A: Leave headroom. Mirroring two platforms at once stacks CPU, memory and bandwidth usage, so stress test against your real device count before scaling and don’t hand the job to an old office machine.
Q6: Which rules should a mixed matrix set in advance? A: At least five: group naming, script ownership, a storage convention for assets and parameters, a retention and failure-handling flow for execution records, and a checklist for new devices joining a group.
Q7: Where does the cost difference between unified and separate actually sit? A: In people and maintenance. Separate management means two tool sets, two ledgers and two inspection routines; unifying removes that duplicated work, and script maintenance costs end up similar.
Q8: What is the first step for a mixed matrix? A: Take inventory. Sort devices by system version, mark which channel each one uses, then pick one high-frequency cross-platform task and pilot it on 3 to 5 devices per platform.
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
Ready to build it for real?
Every approach in this article can be built on the EasyClick phone automation platform — full documentation, developer tools and cluster/cloud-control products, free to try.