Starting March 27, 2025, we recommend using android-latest-release instead of aosp-main to build and contribute to AOSP. For more information, see Changes to AOSP.
Stay organized with collections
Save and categorize content based on your preferences.
The Android Vendor Test Suite (VTS) provides
extensive testing on the following:
Kernel
Hardware abstraction layer (HAL)
VTS runs on a
desktop machine and executes test cases directly on attached devices or
on the emulators. Similar to CTS, VTS is
an automated test suite that uses the following major software components:
The VTS Trade Federation
test harness runs on your host machine and manages test
execution. It offers the ability to
Configure sharding
across multiple devices under test (DUTs). You can also use
the Suite Retry
feature to retry only the failures rather than the entire test suites,
which greatly reduces the re-run time.
Individual test cases are executed on the DUT. The test cases
can be GTest-style tests, kernel tests, or JUnit-style tests written in
Java.
Types of tests
The various types of VTS tests are described in the following sections.
GTest-style tests
Most tests in VTS are GTest-style tests that check the HAL
implementation. The test is
written in C++ and runs on the device. A typical VTS GTest iterates through
each instance of a given interface, and runs all the test cases
against it. Refer to VtsHalHealthStorageV1_0TargetTest
for an example.
Linux kernel tests
Kselftest (external/linux-kselftest)
is a collection of tests included within the Linux kernel repository
at tools/testing/selftests, of which 23 are included in VTS to run on ARM.
Linux Test Project (external/ltp)
tests validate the reliability, robustness, and stability of the Linux kernel.
JUnit-style tests
A small set of host-driven tests in VTS are JUnit-style tests, for example,
KernelApiSysfsTest.
The Java tests are implemented as
BaseHostJUnit4Test,
which is associated with a test device and can run shell
commands to perform validation.
Standalone Python3 tests
Some VTS tests, such as
vts_treble_sys_prop_test
are written in Python3. The
Python-based tests are implemented as unittest.TestCase and each test
case can interact with the device through shell commands.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2025-06-26 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-06-26 UTC."],[],[],null,["# Vendor Test Suite (VTS) and infrastructure\n\nThe Android Vendor Test Suite (VTS) provides\nextensive testing on the following:\n\n- Kernel\n- Hardware abstraction layer (HAL)\n\nVTS runs on a\ndesktop machine and executes test cases directly on attached devices or\non the emulators. Similar to [CTS](/docs/compatibility/cts), VTS is\nan automated test suite that uses the following major software components:\n\n- The VTS [Trade Federation](/docs/core/tests/tradefed) test harness runs on your host machine and manages test execution. It offers the ability to [Configure sharding](/docs/core/tests/tradefed/testing/through-suite/android-test-tuning) across multiple devices under test (DUTs). You can also use the [Suite Retry](/devices/tech/test_infra/tradefed/testing/through-suite/suite-retry) feature to retry only the failures rather than the entire test suites, which greatly reduces the re-run time.\n- Individual test cases are executed on the DUT. The test cases can be GTest-style tests, kernel tests, or JUnit-style tests written in Java.\n\nTypes of tests\n--------------\n\nThe various types of VTS tests are described in the following sections.\n\n### GTest-style tests\n\nMost tests in VTS are GTest-style tests that check the HAL\nimplementation. The test is\nwritten in C++ and runs on the device. A typical VTS GTest iterates through\neach instance of a given interface, and runs all the test cases\nagainst it. Refer to [`VtsHalHealthStorageV1_0TargetTest`](https://cs.android.com/android/platform/superproject/+/android-latest-release:hardware/interfaces/health/storage/1.0/vts/functional/)\nfor an example.\n\n### Linux kernel tests\n\n- Kselftest ([external/linux-kselftest](https://github.com/torvalds/linux/tree/master/tools/testing/selftests/kselftest))\n is a collection of tests included within the Linux kernel repository\n at `tools/testing/selftests`, of which 23 are included in VTS to run on ARM.\n\n- Linux Test Project ([external/ltp](https://cs.android.com/android/platform/superproject/+/android-latest-release:external/ltp/))\n tests validate the reliability, robustness, and stability of the Linux kernel.\n\n### JUnit-style tests\n\nA small set of host-driven tests in VTS are JUnit-style tests, for example,\n[`KernelApiSysfsTest`](https://cs.android.com/android/platform/superproject/+/android-latest-release:test/vts-testcase/kernel/api/sysfs/src/com/android/tests/sysfs/KernelApiSysfsTest.java).\nThe Java tests are implemented as\n[`BaseHostJUnit4Test`](https://cs.android.com/android/platform/superproject/+/android-latest-release:tools/tradefederation/core/test_framework/com/android/tradefed/testtype/junit4/BaseHostJUnit4Test.java),\nwhich is associated with a test device and can run shell\ncommands to perform validation.\n\n### Standalone Python3 tests\n\nSome VTS tests, such as\n[`vts_treble_sys_prop_test`](https://cs.android.com/android/platform/superproject/+/android-latest-release:test/vts-testcase/security/system_property/vts_treble_sys_prop_test.py)\nare written in Python3. The\nPython-based tests are implemented as `unittest.TestCase` and each test\ncase can interact with the device through shell commands.\n| **Caution:** The Python tests aren't recommended due to limited support in the Android tree. We highly recommend writing the VTS tests as GTest, or at least as JUnit-style tests."]]
