In this document
Android Connectivity Testing Suite (ACTS) tests fill the testing gap between Android’s framework APIs and chipset certifications. These tests validate the functionality of various aspects of the Bluetooth, Wi-Fi, and cellular radios as used by the Android framework.
Who should run ACTS tests?
ACTS tests should be run by developers and integrators who are working on connectivity (Bluetooth, Wi-Fi, and cellular) portions of the Android stack. If you are adding new features, integrating a chipset or driver changes, these tests are here to help you ensure that your changes are functional and stable and that they meet basic standards of performance.
These tests are optional and are not required for any Android device certification.
How to run ACTS
ACTS tests make use of privileged Android APIs to unlock a deeper level of testing than would otherwise be possible. Thus, only engineering and userdebug builds may be tested with ACTS.
ACTS tests are designed to run with minimal, mostly off-the-shelf hardware; however, they do require some equipment, which varies based on the type of testing. For many tests, two Android devices or a device and a WiFi access point is sufficient. Please consult documentation specific to one of the major test areas (Bluetooth, Wi-Fi, or cellular) to determine the specific setup requirements.
Scripting Layer for Android
Layer for Android, in
is a fork from an open source project of the same name. This tool provides a
thin RPC server to expose Android’s Java APIs. This allows tests to reside
off-device, which enables coordinated automation of devices and equipment for
richer more dynamic testing. Over the last 18 months, Google has trimmed,
updated, extended, and used this project to remotely exercise Android’s Java
APIs for testing wireless connectivity.
Scripting Layer for Native
Layer for Native, in
is a new internally-grown RPC server for exposing Android’s native APIs in the
same manner as the Scripting Layer for Android exposes the Java APIs. This tools
is currently being used to test Brillo, and we expect this project will expand
rapidly to meet the test needs of the increasingly-critical native wireless
Android Comms Test Suite
Comms Test Suite, in
is a lightweight Python-based automation tool set that is used to perform
automated testing of current and upcoming Android devices. It provides a simple
execution interface; a set of pluggable libraries for accessing devices such as
attenuators and Android devices; and a collection of utility functions to
further ease test development. We think it’s an ideal desktop tool for a
wireless stack developer or integrator whether exercising a new code path,
performing basic sanity testing, or running extended regression test suites.
The test suite also includes a bundle of tests, many of which can be run with as little as one or two Android devices with wifi, cellular, or bluetooth connectivity, including:
- Wifi tests for AP IOT, Enterprise Connection, WifiScanner, Autojoin, and RTT.
- Bluetooth tests for BLE, GATT, SPP, and Bonding.
- Cellular tests for CS and IMS calling, data connectivity, messaging, network switching, and hotspot.
We believe that the release of these tools will help developers, integrators, and testers alike by lowering the barriers to basic testing and serving as a rallying point around which the entire community can collaborate on improved system test.
Failures and contributions
ACTS tests are not a certification suite, and technically the tests do not need to pass in order to release an Android device, though failing tests are are likely to translate into a poor user experience. That said, if tests fail, do not despair. Some of the tests are intentionally hard. Their purpose is to help developers release high-performing devices.
ACTS is a relatively new undertaking, and involvement from the development community is crucial. To add tests, report issues, or ask questions, please start the conversation by opening a bug on the Android Issue Tracker with the template connectivity-testing.