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.
Then delve into the precise technologies available to you in this section, such as the Vendor Test Suite (VTS) and its myriad video and codelab tutorials.
Also note the security-specific testing mechanisms available to detect and harden your devices against vulnerabilities.
For app testing, start with the Fundamentals of Testing and conduct the Android Testing Codelab using the samples provided.
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
Types 1 and 2 are typically written as instrumentation tests, while type 3 are usually written as native tests using the gtest framework.
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.
Debugging
The Debugging section summarizes useful tools and related commands for debugging, tracing, and profiling native Android platform code when developing platform-level features.