【读书笔记】https://source.android.google.cn/compatibility/tests?hl=en

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.

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.

Finally, note basic presubmit testing is available to you through Repo Hooks that can run linters, check formatting, and trigger unit tests before proceeding, such as uploading a commit. Note these hooks are disabled by default. See the Repo Hooks introduction for more details.
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:

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