Mobly is the test framework for the case where one device is not enough

Written for the case where one device is not enough

Mobly is a Python-based test framework that specialises in test cases requiring multiple devices, complex environments or custom hardware setups. That sentence is the whole pitch, and the example use cases in the documentation show what it means. P2P data transfer between two devices, conference calls across three phones, a wearable interacting with a phone, internet-of-things devices interacting with each other, testing RF characteristics of devices with special equipment, and testing an LTE network by controlling phones, base stations and eNBs. Every one of those is a test where the interesting assertion involves a relationship between two things, and where the framework has to own the lifecycle of hardware that is not the device under test. The documentation also says that Mobly can support many different types of devices and equipment, and that it is easy to plug in your own device or custom equipment or service. That is the design constraint that makes it different from a general purpose UI test harness. The library ships with a set of libs to control common devices such as Android devices, and the extension point is the part you will use if your setup is unusual. One note on provenance, because it matters for how much you should expect of support: Mobly was developed by Googlers but is not an official Google product.

Python 3.14 and adb are the real prerequisites

The compatibility section is short and worth reading twice. Mobly requires Python 3.14 or newer, and the package metadata says the same with requires-python of >=3.14. The tests can run on Ubuntu 14.04 and later, macOS 10.6 and later, and Windows 7 and later. The system dependencies are adb, with 1.0.40 or newer recommended, and Python 3.14 or newer. That Python floor is the most consequential line in the documentation, because a framework pinned to a brand new interpreter release is a framework that will not run on the older interpreters many CI images still carry. The trade-off goes the other way too, since starting from a current interpreter means the framework is not carrying compatibility shims for long dead versions, and the dependency list in the package metadata is correspondingly small: portpicker, pyyaml, and pywin32 on Windows only. The Windows marker is there because Mobly needs to talk to Windows specific facilities there. The optional testing extra adds pytest, and the pytest configuration in the manifest is set up for a specific layout, with test discovery limited to the tests/mobly directory, python_classes matching names ending in Test and python_files matching names ending in _test.py.

Install from pip or work against a checkout

Installation is either the released package or the source tree, and the documentation gives both. The released package comes straight from pip:

pip install mobly

The source route is for people who want the bleeding edge:

git clone https://github.com/google/mobly.git
cd mobly
pip install -e .

The documentation adds a warning that you may need sudo for these commands if your system has certain permission restrictions, which is a hint about the kind of environment the framework expects. Given the use cases, that makes sense. A test that controls base stations or drives a wearable through a phone session is not running in a sandbox, and the adb side of the work in particular often needs local access to a USB-attached device. The package metadata also records a download tarball URL pinned to the current version, 1.13.1, and a maintainer entry pointing at a public group address rather than an individual, which is the shape you would expect from a project that is maintained by a team rather than a person.

Snippets are the bridge to device-side code

The part of Mobly most likely to matter to an Android team is the Snippet mechanism, and it lives in companion projects rather than in this repository. The Mobly Snippet Lib is used for triggering custom device-side code from host-side Mobly tests, and the documentation notes that you could use existing Android libraries such as UI Automator and Espresso for that. The Mobly Bundled Snippets project is a set of Snippets that let Mobly tests control Android devices by exposing a simplified version of the public Android API suitable for testing. The word simplified is doing real work in that sentence. A bundled snippet gives a test a narrow, stable handle onto a piece of platform behaviour, which is much easier to write a cross-version test against than the full API surface. There is also a helper script in the package, tools/snippet_shell.py, installed as a script file, which is the kind of entry point that suggests interactive work against a device while developing a snippet.

Your own equipment becomes a service

The extension mechanism is documented in a tutorial of its own, the Mobly AndroidDevice Service, whose subject is creating a custom service to attach to Mobly's AndroidDevice controller. The pattern generalises past Android. The stated capability is that it is easy to plug in your own device or custom equipment or service into Mobly, and the model is a controller for the device under test with services attached to it. A piece of lab equipment or a service on the network becomes a service object the test can talk to, in the same way the framework talks to a phone. That is the architectural idea worth taking away, because it is what lets one test body cover a wearable talking to a phone talking to a base station. The risk of that design is that the framework's value is concentrated in the services you write for it, and each custom service is code you own and must maintain. The tutorials are the entry point for that work, with Mobly 101 for simple test examples, the instrumentation runner tutorial for Android instrumentation tests, and the AndroidDevice service tutorial for attaching your own code.

Apache-2.0, an active project, and a moving Python floor

The licence is Apache-2.0, recorded in the package metadata as a licence text of Apache2.0 with a LICENSE file in the repository, which is a permissive licence that includes an explicit patent grant. The project is clearly alive. The release history runs 1.12.4 on 2024-08-29, 1.13 on 2025-05-07 with the note SL4A Removal and Test Suite Improvements, and 1.13.1 on 2026-08-07 described as minor improvements and bug fixes, and the last push was on 2026-10-17. That 1.13 release is worth understanding as a compatibility signal as much as a feature one. Removing SL4A, the Android Scripting Layer for Automating and Testing, changes what older test suites can rely on, so a team upgrading across that boundary will have work beyond a version bump. The repository also carries a CHANGELOG.md, CONTRIBUTING.md, a tox.ini for the test matrix and a docs directory published through readthedocs, which is a reasonable amount of scaffolding for a project that other teams build test infrastructure on top of. The one thing to keep an eye on is the Python floor. Requiring 3.14 while the rest of your tooling may not is the constraint most likely to slow an adoption.

Editorial conclusion

Adopt Mobly if your test cases need two or more devices, real network equipment or a custom service in the loop, since the framework is built for exactly that coordination rather than for single device app tests. Do not adopt it for ordinary unit or single device UI testing, where a lighter harness will do less work. Before you start, confirm that your environment can run Python 3.14, which the package requires, and that adb is available for the Android paths, then read the Mobly 101 tutorial to see how the controller and service model fits your equipment before you write a custom service.

Frequently asked questions

Official sources

1. google/mobly on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases