Android Automation Script HID Hardware Guide: Bluetooth HID vs OTG HID — Costs, Differences & Setup

1. What Is HID: Treating “Keyboard and Mouse” Devices as the Operation Source

When people hear “phone automation,” most first imagine “software tapping the screen for you in the background.” HID takes a completely different approach. HID stands for Human Interface Device — keyboards, mice, touchpads, and game controllers all belong to this category. What they share is this: they do not care about screen content; they only feed “human input” into the system. To the phone, they are just ordinary “peripherals.”

The core of HID automation is using a piece of hardware to disguise itself as a human interface device like a keyboard or mouse, making the phone believe “someone is operating it with a peripheral,” so clicks and swipes go through a hardware channel. In EasyClick, for example, the HID controller flow works like this: the phone connects to a computer (or HID mini-host) over USB, you launch the EasyClick HID controller program on the computer, and scripts on the phone perform operations through this channel (HID controller docs).

In one sentence: software injection “grabs” the screen; HID “plays the peripheral” — the former operates at the application layer, the latter at the hardware layer.

2. Why HID: No Accessibility Service, No USB Debugging, Fewer Software Traces

The common accessibility mode uses the system’s official accessibility service (AccessibilityService): scripts read the UI and inject operations, with the fullest feature set. But it has a “software trace” problem — a permanently resident accessibility service is itself observable, and many automation-sensitive apps check for it.

HID avoids software injection entirely: it does not depend on the accessibility service and does not require USB debugging to be enabled; all operations are carried out by hardware peripherals, leaving fewer software traces. EasyClick officially describes HID as “automation without the accessibility service or USB debugging.”

The EasyClick Android edition (no root required, supporting Android 5.0 through the latest systems; the current latest version is 12.4) has four running modes, which are clearest in a table (running modes doc):

Running Mode	Principle	Feature Scope
Accessibility mode	Operations injected via the system accessibility service	Full feature set
Proxy mode	Executed by connecting to a computer or proxy service	Full feature set
Bluetooth HID	ESP32 Bluetooth peripheral simulating a human interface device	Image/color, OCR, Bluetooth click/swipe only
OTG HID	HID device connected over wired USB	Image/color, OCR, OTG click/swipe only

Key conclusion: HID is not a “downgraded accessibility” but a trade-off — narrower functionality (only image/color recognition, OCR, and click/swipe) in exchange for fewer software traces and a cleaner deployment. What “narrower functionality” concretely means is covered in Section 6.

3. Bluetooth HID: ESP32 Dev Board + Free Firmware, Wireless Deployment

The Bluetooth HID idea is simple: flash an ESP32 dev board into a “Bluetooth keyboard/mouse,” pair the phone over Bluetooth, and scripts click and swipe through this Bluetooth channel (Bluetooth HID docs).

• Supported hardware: ESP32-S3, ESP32-C3
• Cost: firmware is free; the dev board is self-purchased — the official recommendation is to buy from Taobao, Pinduoduo, or 1688, at a few dozen CNY per board
• Firmware: download the firmware bin for your hardware from the official download area and flash it with the ESP32 flash_download_tool. The firmware comes in two variants, with keyboard and without keyboard: some apps detect keyboard emulation, so the two versions are kept separate; the no-keyboard firmware cannot use input keys such as Home
• Connection: after flashing and repowering, the device appears in the phone’s Bluetooth settings; once paired, scan and select it in the APP’s system settings under Bluetooth HID, run the test, and save
• Script calls: operations such as connect, click, swipe, Home/Back are handled by the bleEvent family of functions

Bluetooth HID’s biggest advantage is wireless: no cables on the phone, flexible deployment, ideal for temporary, mobile, or hard-to-wire scenarios. The trade-off is that Bluetooth itself is a wireless channel — too many Bluetooth devices nearby, a crowded 2.4 GHz Wi-Fi band, or physical obstruction can all cause interference, so stability needs on-site validation.

4. OTG HID: Wired USB Connection, More Stable, Immune to Bluetooth Interference

OTG HID works on the same idea but replaces wireless with a wire: an ESP32 dev board connects directly to the phone’s USB port through an OTG adapter, and the phone recognizes the board as an HID peripheral (OTG HID docs).

• Supported hardware: ESP32-S2, ESP32-S3
• Firmware: equally free — download the matching firmware from the official download area and flash it, following the Bluetooth HID flashing tutorial
• Wiring: a regular adapter works; buy a 3-in-1 adapter if you need “charging + OTG” at the same time
• Two gotchas: the ESP32-S2 needs BOOT held down while briefly pressing RST to enter flashing mode; after flashing, the ESP32-S3 must be plugged into the phone’s USB-OTG port, not the COM port
• Authorization and testing: the first insertion triggers a USB authorization dialog — check “always use” and confirm; in the APP’s system settings under OTG HID, click “Connect OTG” and then “Test Home” — returning to the home screen means success
• Script calls: handled by the otgEvent family of functions

A wired connection means no Bluetooth interference and a more stable link, suitable for fixed workstations, long-running operation, and stability-sensitive scenarios.

The Bluetooth HID vs OTG HID decision, in one table:

Dimension	Bluetooth HID	OTG HID
Connection	Wireless Bluetooth	Wired USB
Supported hardware	ESP32-S3 / ESP32-C3	ESP32-S2 / ESP32-S3
Firmware cost	Free	Free
Interference	Affected by the Bluetooth channel	Immune to Bluetooth interference, more stable
Deployment	No cables on the phone, free to move	Phone must be wired, fixed deployment
Best for	Temporary, mobile, hard-to-wire setups	Fixed workstations, long-term stable operation

5. HID Mini-Host: Driver-Free, Around 100 CNY, Built for Stable Volume Deployment

When the device count grows (a dozen or dozens of phones running long-term), juggling individual dev boards starts to feel toy-like. EasyClick has officially recommended the HID mini-host approach since v3.0.0 (HID mini-host docs), and the official summary is three words: driver-free, low cost, more convenient.

• Price: around 100 CNY per unit (as confirmed by the product team) — a bit more than a dev board, but with far higher device capacity: per official testing, one mini-host can drive around 20 phones, so the per-phone cost is very low
• Driver-free: after installing Ubuntu Server on the mini-host, the Linux platform needs no drivers at all — just run the HID controller program directly; the central-control system supports one-click HID controller installation, auto-start after reboot, and ready-to-use on boot (on Windows, you instead replace the phone driver with libusbK using zadig; HID controller 4.0.0+ already supports winusb)
• Scripts and screen mirroring in one: a single mini-host supports both HID scripts and HID screen mirroring
• Strong networking: HID controller v3.5.0+ supports long-connection networking — the controller can sit on a cloud server while clients stay on the local LAN, with both sides communicating; controller and clients can also be networked within the same network. v2.2.0+ also supports advanced networking between multiple HID controllers (the official recommendation is a Windows controller with Ubuntu industrial-PC clients, which greatly cuts cost)
• Cross-network access: with intranet penetration, you can reach the local HID controller’s web page from the public network for remote management

In one sentence: dev boards are for “experimenting” and “small scale”; the HID mini-host is for “stable volume production” — and that is the officially promoted direction.

6. Capability Boundaries: What the HID Channel Can and Cannot Do

Before choosing HID, understand the boundaries — otherwise you will step on landmines. The HID channel’s capability scope is fixed (running modes doc):

What it can do:

• Image/color recognition: template matching, color finding, multi-point color finding, built on OpenCV template matching, with an officially claimed recognition rate of 95%+
• OCR text recognition: the full PPOCR-V4 / V5 / V6 model family, all free and recognized locally offline, no cloud dependency
• Basic operations: click, long-press, swipe, Home/Back, and similar

What it cannot do:

• Read UI structure: control-tree (node) reading is outside the HID channel’s capability
• Complex text input: HID mainly simulates clicks and swipes; and the no-keyboard firmware lacks input keys such as Home entirely
• Advanced capabilities that depend on the accessibility service: anything that goes through the accessibility channel is out of HID’s reach

Conclusion: HID is a “see the screen and act” channel, not a “full-featured” channel. If your automation mainly relies on “watching the screen, finding a button, tapping it,” HID fits very well; if scripts heavily depend on reading nodes and entering text, return to accessibility or proxy mode. When choosing, first ask yourself: is my script “tapping what I see,” or “writing what I read”?

7. Hardware List and Cost Comparison: Dev Board or Mini-Host?

The two hardware paths side by side (HID controller docs, HID mini-host docs):

Dimension	ESP32 Dev Board (Bluetooth/OTG HID)	HID Mini-Host
Cost	A few dozen CNY per board	Around 100 CNY per unit
Firmware / drivers	Firmware free, self-flashing required	Driver-free; install Ubuntu Server + one-click HID controller
Stability	Per-device solution; wireless has interference, wired needs a cable	Host-level stability, suited for long-running operation
Device capacity	One board, one phone	Around 20 phones per unit per official testing
Learning curve	Flash firmware, pair/authorize	Install OS and controller, auto-start on reboot
Best for	Individuals, few devices, mobile deployment	Volume, fixed sites, stable production

Buying advice (by scenario):

• Personal experimentation / a few devices / mobility needed: choose an ESP32 dev board — Bluetooth HID if you dislike cables, OTG HID if you want stability; a few dozen CNY is a very cheap way to try
• A dozen-plus devices, fixed site, long-term operation: go straight to the HID mini-host — around 100 CNY per unit, driver-free, high device capacity, the officially recommended path
• Cross-network, multi-site deployment: use long-connection networking (controller can run on a cloud server) plus intranet penetration for unified remote management

Hardware is only the “channel”; what actually does the work is the scripts and recognition capabilities, and the EasyClick ecosystem has all the supporting pieces: image/color recognition and OCR are fully local and offline (recognition works without a network); scripts are written in JavaScript and can call all Java class libraries; local offline packaging, offline (standalone) execution, and hot code updates are supported; and there are commercial extras such as JS obfuscation + secondary compilation and network-verified card keys. On the development side, the new IDEA version (2026.2+) needs no activation; combined with AI editors like Cursor/Trae and ec-android-cli, you can generate, compile, and run scripts conversationally, and install AI DOCS with one click. At scale, central-control screen mirroring (around 100 devices per machine) and cloud control (around 500 devices per machine) can be added. In other words, from a dev board that costs a few dozen CNY to the managed operation of hundreds of devices, it is one continuous product path (official docs).

8. Connection and Setup Flow at a Glance

Three routes, with their setup steps summarized (details follow the official docs).

Route 1: Bluetooth HID (ESP32-S3/C3)

1. Buy an ESP32-S3/C3 dev board; download the matching firmware (with-keyboard / no-keyboard) and the flash_download_tool
2. Flash the firmware, repower, then scan and pair in the phone’s Bluetooth settings
3. Open the APP’s system settings → Bluetooth HID, scan and select the Bluetooth name, tap “Test,” and save once it succeeds
4. Call the bleEvent family of functions in scripts to perform operations

Route 2: OTG HID (ESP32-S2/S3)

1. Buy an ESP32-S2/S3 dev board and an OTG adapter (a 3-in-1 if you need charging + OTG); download and flash the firmware
2. Plug the board into the phone’s USB-OTG port; when the authorization dialog appears, check “always use” and confirm
3. Open the APP’s system settings → OTG HID, tap “Connect OTG,” then tap “Test Home” — returning to the home screen means success
4. Call the otgEvent family of functions in scripts to perform operations

Route 3: HID controller (phone plugged into a computer / HID mini-host)

1. On Windows, download the EasyClick HID controller program and install the driver with zadig (choose libusbK; HID controller 4.0.0+ supports winusb). On Linux, no driver is needed — run the binary directly
2. Connect the phone to the computer / mini-host over USB, tap “Activate HID,” and when the phone shows the USB accessory authorization, check “use by default for this USB accessory” and confirm
3. Seeing the device serial number in the EC system settings → HID settings means success; the phone’s VID/PID changes after activation, which is normal — if the controller does not recognize the device, replace the driver again with zadig
4. Set the HID controller URL in scripts (LAN: http://ip:8988; cross-network: use intranet penetration such as frp)
5. Devices on the same subnet can tap “Network Scan” to connect to the controller automatically; use “Advanced Networking” (v2.2.0+) for multiple controllers, and long-connection networking (v3.5.0+, controller can run on a cloud server) across networks

Two extra notes: the HID controller approach is independent of ADB — with USB debugging on, HID can be used at the same time (the official docs state the two can coexist); and if the phone is on cellular data while the HID controller is on Wi-Fi and the networks cannot reach each other, the v2.2.0+ USB communication mode solves it (just confirm the authorization dialog when activating HID).

9. Compliance Note and FAQ

Compliance note: the accessibility service, HID, and ADB are all officially exposed system capabilities — the capabilities themselves are completely legal. The real red line has never been “which approach” but “what you do with these capabilities” — once any automation tool is used for gray-market purposes, every approach is dangerous. Using HID for testing, efficiency, and compliant operations is the normal use of official capabilities.

Q1: What is HID, and why does it need neither the accessibility service nor USB debugging? A: HID stands for Human Interface Device — keyboards, mice, and touchpads belong to this category of “peripherals.” HID automation uses hardware to disguise itself as a peripheral, so clicks and swipes travel through a hardware channel: no accessibility service, no USB debugging, and fewer software traces.

Q2: What is the difference between Bluetooth HID and OTG HID? How do I choose? A: Bluetooth HID works wirelessly (ESP32 Bluetooth peripheral): flexible deployment and no cables on the phone, but it can be affected by Bluetooth channel interference. OTG HID connects over a wired USB link: more stable and immune to Bluetooth interference. Choose Bluetooth HID for temporary or mobile scenarios, and OTG HID for fixed, long-running setups.

Q3: What is the functional difference between HID mode and accessibility mode? A: Accessibility mode supports the full feature set but leaves the software trace of a resident accessibility service. HID mode only supports image/color recognition, OCR, and basic click/swipe operations, but leaves fewer software traces. Pick accessibility mode when you need complete functionality, and HID when you are sensitive to software traces.

Q4: How much do the HID hardware options cost? A: Very little. An ESP32-S3/C3 dev board costs a few dozen CNY with free firmware; an HID mini-host costs around 100 CNY per unit, is driver-free, and per official testing one unit can drive around 20 phones. OTG setups additionally need an adapter (a 3-in-1 if you need charging plus OTG).

Q5: Is the ESP32 firmware paid? Do I need to solder or program it myself? A: The firmware is completely free and downloaded from the official download area; the dev board is self-purchased (available on Taobao, Pinduoduo, and 1688). Flashing uses the official flash_download_tool — just follow the tutorial. No soldering and no firmware coding are needed; the script side simply calls the ready-made functions.

Q6: How do I choose between an HID mini-host and an ESP32 dev board? A: For personal experiments, a few devices, or mobile deployment, pick a dev board (a few dozen CNY). For a dozen-plus devices, fixed sites, and long-term stable operation, pick an HID mini-host (around 100 CNY, driver-free, high device capacity — the officially recommended path).

Q7: Bluetooth HID connection is unstable or cannot be scanned. What should I do? A: Common troubleshooting: restart the Bluetooth hardware (power off or press the RST button on the board), kill and restart the APP process, and unpair then re-pair in the phone Bluetooth settings. For background scanning issues, grant the APP the floating-window permission, set location permission to “always allow,” allow background pop-ups, and on newer Android versions also allow the “scan nearby devices” permission while keeping the APP alive.

Q8: Can HID input text or read the UI structure? A: The HID channel mainly covers image/color recognition, OCR, and click/swipe. Reading UI nodes and complex text input are not provided by the HID channel — they require accessibility or proxy mode. For reading on-screen text, use the local offline OCR (PPOCR-V4/V5/V6, all free).

Q9: Does HID support batch management of many phones? A: Yes. HID controller v3.5.0+ supports long-connection networking (the controller can run on a cloud server while clients stay on the local LAN, with both sides communicating), and v2.2.0+ supports advanced networking between multiple HID controllers. At larger scale, central-control screen mirroring (around 100 devices per machine) and cloud control (around 500 devices per machine) can be added.

Q10: Is HID automation compliant? A: HID is an officially exposed human interface capability of the system, and the capability itself is legal. Compliance depends on how it is used — testing, efficiency, and legitimate operations are normal uses of official capabilities; gray-market use is dangerous under any approach.

---

About EasyClick: a mobile phone automation AI agent platform covering Android (no root), iOS (no jailbreak), and HarmonyOS Next ecosystems, offering script development, Apple cluster control, local central-control screen mirroring, and cloud control systems. → Explore all products