Project: /_project.yaml Book: /_book.yaml

{% include “_versions.html” %}

Android Platform Testing

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.

What's new

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 Make solution.

Atest

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:

1. 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)
2. invoke Android system services via raw binder/IPC proxies directly
3. 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{: .external} framework.

To learn more, see our end-to-end examples:

• instrumentation targeting an application
• self-instrumentation
• native test

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{: .external} and reboot.xml{: .external} 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.