This content is geared toward Android platform developers. Before understanding how testing is done on the Android platform, please refer to the Android platform architecture for an overview.
Test development workflow
The Test Development Workflow subsection now contains introductory materials including end-to-end examples for all primary test types.
Simple test configuration
The Soong build system
was introduced in Android 8.0 (Oreo) with support for
android_test arriving in
Android Q, now available in the Android Open Source Project (AOSP) master
branch. Soong's Blueprint-based configuration is far simpler than the previous
Atest is a command line tool that allows users to build, install and run Android tests locally. It is the recommended standard for initial testing of your feature.
What and how to test
A platform test typically interacts with one or more of the Android system services, or Hardware abstraction layer (HAL) layers, exercises the functionalities of the subject under test, and asserts correctness of the testing outcome.
As such, a platform test may:
- exercise framework APIs via application framework; specific APIs being
exercised may include:
- public APIs intended for third-party applications
- hidden APIs intended for privileged applications, namely system APIs
- private APIs (@hide, or protected, package private)
- invoke Android system services via raw binder/IPC proxies directly
- interact directly with HALs via low-level APIs or IPC interfaces
To learn more, see our end-to-end examples:
Become familiar with these tools, as they are intrinsic to testing in Android.
Compatibility Test Suite (CTS)
Android Compatibility Test Suite is a suite of various types of tests, used to ensure compatibility of Android framework implementations across OEM partners, and across platform releases. The suite also includes instrumentation tests and native tests (also using gtest framework).
CTS and platform tests are not mutually exclusive, and here are some general guidelines:
- if a test is asserting correctness of framework API functions/behaviors, and it should be enforced across OEM partners, it should be in CTS
- if a test is intended to catch regressions during platform development cycle, and may require privileged permission to carry out, and may be dependent on implementation details (as released in AOSP), it should only be platform tests
Vendor Test Suite (VTS)
The Vendor Test Suite (VTS) automates HAL and OS kernel testing. To use VTS to test an Android native system implementation, set up a testing environment then test a patch using a VTS plan.
Trade Federation Testing Infrastructure
Trade Federation (tradefed or TF for short) is a continuous test framework designed for running tests on Android devices. TF can run functional tests locally, at your desk, within your platform checkout. There are two required files to run a test in TF, a java test source and an XML config. See RebootTest.java and reboot.xml for examples.
The Debugging section summarizes useful tools and related commands for debugging, tracing, and profiling native Android platform code when developing platform-level features.