GuidePublished: 4 min read

How to Build a Small Android Device Lab for Testing

A practical guide to building an Android device lab for QA. Choosing devices, USB hubs and power, keeping batteries healthy, networking, ADB at scale and test tools.

A device lab is a set of real Android phones and tablets you keep connected and ready for testing. It does not need to be big. Five to ten well-chosen devices on one desk catch most of the bugs that emulators miss. This guide covers the hardware, the setup and the habits that keep a lab reliable. For the difference between a test lab and an abusive "phone farm", see what a phone farm is.

1. Choose the devices

Pick devices to cover differences, not to have many of the same:

  • Android versions: your app's minimum supported version, the most common version among your users, and the newest.
  • Brands: Samsung, Xiaomi and the brands your users actually have. Vendor skins change permissions, notifications and battery behaviour.
  • Screens: a small phone, a large phone, a tablet, and a foldable if your app supports it.
  • Performance: at least one low-end phone with little RAM. That is where slow start-up and crashes show up first.

Your analytics or Play Console device reports tell you which models matter most. Used and refurbished phones are fine for a lab.

2. USB hubs and power

USB is the most reliable way to connect a lab.

  • Use powered USB hubs with their own power supply. Unpowered hubs cannot charge several phones and cause random disconnects.
  • Prefer short, good data cables. Many cheap cables only charge.
  • Spread devices over several hubs and several USB ports on the computer. Each USB controller has limited bandwidth, and screen streaming uses a lot of it.
  • Label every cable and device with the same name, so you can find the phone that is failing.

3. Keep batteries healthy

Phones that are charged to 100 percent all day, every day, age fast and can swell. That is a safety risk in a lab.

  • Turn on the phone's own battery protection where it exists. Many models offer a setting that stops charging at about 80 or 85 percent.
  • Keep the lab cool and give phones air around them. Do not stack them.
  • Check the batteries regularly and retire any phone whose back or screen starts to lift.

4. Device settings

Apply the same settings on every device:

  • Developer options on, USB debugging on, and the computer approved with "Always allow". See how to enable USB debugging.
  • Stay awake in Developer options, so the screen stays on while charging.
  • Screen lock off for test-only devices, so tests do not stop at the lock screen.
  • Window, transition and animator animation scale set to off or 0.5x to make UI tests faster and more stable.
  • Automatic system updates off, so the Android version does not change in the middle of a test cycle.
  • A dedicated test Google account, never a personal one.

5. Network

  • Put the lab on its own Wi-Fi network or VLAN, separate from office and guest networks.
  • Give each device a fixed IP in the router if you use ADB over the network.
  • Use network ADB for devices that cannot be cabled, such as TVs. See controlling an Android TV with ADB.

6. ADB with many devices

  • adb devices -l lists every device with its serial and model. Use adb -s <serial> to target one.
  • Run one ADB server per computer. Several tools each starting their own server is the most common cause of devices going "offline" or "busy". See fixing busy or unauthorized devices.
  • For scripts, loop over the serials:
for s in $(adb devices | awk 'NR>1 && $2=="device" {print $1}'); do
  adb -s "$s" install -r app-release.apk
done

7. Tools on top

  • Manual testing: ADBKit opens up to six devices in one browser tab, each with its live screen, logcat, shell and files, with nothing to install for USB. scrcpy is a good desktop option.
  • Automated tests: Espresso and UI Automator run inside your app's test build. Appium and Maestro drive any app from outside. All of them run over ADB.
  • CI: a small computer next to the lab can run your test suite on every build and keep logs and screenshots of failures.

8. Security and rules

  • Keep test devices free of personal accounts and real customer data.
  • Wipe devices before they leave the lab.
  • Use the lab for testing your own apps or apps you are allowed to test. Using a device lab for fake installs, reviews, clicks or accounts breaks platform rules and often the law.

Planning something bigger?

If your team is building a larger device lab and needs tools for many devices or repeatable workflows, tell us about it at cellhubsapp@gmail.com. We build multi-device and automation features from real workflows. Our approach is in where ADBKit is heading.