Where ADBKit Is Heading: Multi-Device, Automation and Trust

ADBKit started from a simple annoyance. Checking something on a real Android device meant installing platform-tools, remembering commands and switching between a mirroring app, a terminal for logcat and a file manager. We wanted all of that in one browser tab, with nothing to install and no device data leaving the computer.

The idea

Three principles shape every feature:

1. Open a tab and work. Over USB, Chrome and Edge talk to the phone directly with WebUSB. Over your network, a small agent on your own computer does the part a browser cannot. No account, no desktop app.
2. Local first. Screens, logs, files, APKs and serial numbers stay between your browser, your computer and your device. ADBKit has no server that receives them. The agent's source code is public.
3. Show what is happening. Connecting is a guided set of steps, errors say what to do next, and destructive actions such as reboot or overwrite ask first.

What ADBKit does today

• Live screen with mouse and keyboard control
• Screenshots with a markup editor, and screen recording with trimming
• APK install, live logcat with filters, ADB shell and a file manager
• Reboot, power off and boot modes
• USB, TCP/IP and Wireless debugging with code or QR pairing
• Up to six devices at once, one tab each, with only the visible one streaming video

All of it is free.

Where we are going

The most common request we hear is about many devices and repeating work: running the same steps on every phone in a test lab, preparing a batch of devices with the same apps and settings, or checking the same screens after every build. That is where ADBKit is heading, with automation workflows that you define once and run again on connected devices.

Why we build these features carefully

Tools that drive many phones at once serve two very different groups. Device labs use them to test apps, set up company devices and support customers. Abusive phone farms use the same kind of tools for fake engagement, ad fraud and fake accounts. Those hurt real people and break the rules of every major platform.

So we follow one rule: we only build multi-device and automation features once we understand the workflow behind them. In practice that means:

• We talk to teams before we build. We want to know what they test, on which devices, and what a normal day looks like.
• We design each feature around a specific job, such as running a test checklist, installing a build on every device or collecting logs from a failing run, rather than a generic "do anything on 100 phones" tool.
• We do not build features whose main use would be fake installs, reviews, clicks, views or accounts, and we decline requests aimed at that.
• Manual control of your own devices stays free.

This takes longer than shipping everything at once, but it means the features that do ship fit real work and are harder to misuse.

Talk to us

If you run a device lab, a QA team, a kiosk or signage fleet, or another setup with many Android devices, we would like to understand your workflow. Write to cellhubsapp@gmail.com and tell us:

• How many devices, which models and Android versions
• What you do on them every day or every release
• What takes the most time or breaks most often

You can also try the current workspace at adbkit.com/app. For background, read what a phone farm is and how to build an Android device lab.