This document describes AVDs for Test Lab, including benefits and known limitations. We also provide recommendations about how to test your app throughout the development lifecycle.
While Test Lab AVDs are similar to AVDs for Android Studio, there are a few differences between the two. For example, AVDs in Test Lab have an emulated data connection rather than a Wi-Fi connection.
Test Lab AVDs with an
.arm or (ARM) suffix are advanced
emulators which provide the following benefits:
Faster test execution time
Screen sizes and densities aligned with Android Studio's AVDs for consistency
Using AVDs with an
.arm or (ARM) suffix provides the
following advantages over other types of physical devices:
|High availability||You can run tests and get test results more quickly when testing with virtual devices. Because virtual devices are created on demand, your tests start almost immediately, providing quick validation of your app.||Testing small updates to your app, or for regression testing.|
|Longer test durations||Tests on physical devices are limited to a test duration of 45 minutes on each device. Virtual devices support a test duration of up to 60 minutes.||Running longer tests.|
|Lower costs||Virtual devices are priced at $1 per hour for each virtual device used to test your app.||Daily testing using continuous integration systems, or before checking in code. To learn more, see Usage levels, quotas, and pricing for Test Lab.|
Test your app with virtual devices
You can test your app with virtual devices the same way that you test it with physical devices. Simply select virtual devices when you select test dimensions to configure a test matrix. To learn more about running tests with Test Lab, see Get started testing for Android with Firebase Test Lab.
View supported models and APIs
To view AVD models and APIs supported by Test Lab, run the following command:
gcloud firebase test android models list --filter=virtual
Best practices for testing your app
Virtual devices increase your range of options when you test your app with Test Lab. We recommend using the best practices in this section to test your app throughout the app development lifecycle.
Use the Android Studio emulator or an attached physical device
When developing your app, use the Android Studio emulator or an attached physical device to examine each build for initial validation. If you have instrumentation tests, you can also run these tests from Android Studio on either physical or virtual devices provided by Test Lab.
Use CI systems on each code change when working on shared projects
If you work on a large project, or if you contribute to projects that are shared using GitHub or a similar service, we recommend that you use continuous integration (CI) systems.
Test your apps on virtual devices each time that the CI system runs, or before each pull request. To learn more about using Test Lab with CI systems, see Using Test Lab for Android with Continuous Integration Systems.
Test your app on physical devices with Test Lab before you release significant app updates
Before you release app updates with significant UI and functionality changes, we recommend that you use Test Lab to test your app on physical devices. This will help to ensure that your app is stable and performant on a wide range of popular physical devices. Testing on physical devices also ensures test coverage for any app functionality that relies on physical device features that are not simulated by virtual devices. To learn more about these features, see Known limitations.
Virtual device updates
Periodically, the Android team adds new virtual device images, deprecates old ones, and updates existing ones. We apply these updates to our virtual device images to help ensure that you're testing against up-to-date Android versions that reflect your users' experiences.
In rare cases, these updates may cause tests to fail unexpectedly. When there is a known potentially breaking update, Test Lab will include information in release notes. As a best practice, we recommend you use test frameworks – for example, Espresso – that are robust to these changes whenever possible. When that is not possible, we recommend you target ARM virtual devices, which you can expect to update less frequently.
Some physical device features are not currently simulated by virtual devices, or are simulated with some limitations. The following table summarizes features that are currently unavailable on virtual devices, or that are available with certain limitations.
|Application Binary Interfaces (ABI)||Not all devices support all ABIs. If you
are developing with the Android NDK, be sure to generate code for the
ABIs supported by the devices you target. For more information, see
Available devices in Test Lab.
To learn more about ABI management, see Android ABIs.
To learn which ABIs are supported by a device, see
Check available test devices.
Note: If a test in your test matrix is marked Invalid, this might occur because your app has a dependency on native code unsupported by the device ABI.
|Graphics performance||Nexus and Pixel virtual devices use
software graphics rendering. Graphics-intensive applications will
experience lower performance. If your app is graphics-intensive,
|Screen recording||Screen recording on the Nexus and Pixel devices is 1 frame per second.|
|Graphics APIs||OpenGL ES 3.x is unsupported on devices below API level 29. Newer devices are not 100% compatible with OpenGL/Vulkan APIs. You may notice small differences in graphics.|