Snap for 6596975 from a9db589624fd48bd096562e82051c2800fa967a6 to rvc-release am: 9e68dc4523

Original change: https://googleplex-android-review.googlesource.com/c/platform/external/ltp/+/11888248

Change-Id: I0efe0a78698847a67ad85193c5ca680e293efc5d

1 files changed, 30 insertions, 35 deletions

diff --git a/android/README.md b/android/README.md
index 844583401..4f55d3906 100644
--- a/android/README.md
+++ b/android/README.md
@@ -33,12 +33,24 @@ test/vts-testcase/kernel/ltp. Some noteworthy directories/files:
 * `external/ltp/android/ltp_package_list.mk`: Lists all tests that will get pulled into VTS - VTS depends on this list. This file gets auto-generated by android/tools/gen_android_build.sh.
 * `external/ltp/android/tools/disabled_tests.txt`: Lists tests which cannot or should not be compiled for Android. This file is read by gen_android_build.sh during LTP upgrades to produce *.mk files required to build LTP for Android.
 * `external/ltp/testcases`: Source for LTP tests. Among the most important for the purposes of Treble are those in external/ltp/testcases/kernel/syscalls.
-* `test/vts-testcase/kernel/ltp/configs/disabled_tests.py`: Any test listed here will not be run in VTS, either in the staging or stable set, despite being compiled. If a test does not appear here then it at least runs as part of the VtsKernelLtpStaging module.
-* `test/vts-testcase/kernel/ltp/configs/stable_tests.py`: Any test listed here will run as part of the VtsKernelLtp (stable) module.
+* `test/vts-testcase/kernel/ltp/testcase/tools/configs/disabled_tests.py`: Any test listed here will not be run in VTS, despite being compiled.
+* `test/vts-testcase/kernel/ltp/testcase/tools/configs/stable_tests.py`: Any test listed here will run as part of the vts_ltp_test_arm/vts_ltp_test_arm_64 modules.
 
-New tests are run in the staging set for some time (a couple weeks or more) to
-ensure they are reliable prior to their being added to the stable set.
+Running LTP through atest
+-------------------------
+You can run LTP tests with atest, which handles all the setup and build steps.
 
+To run all 32 bit LTP tests:
+* `atest vts_ltp_test_arm`
+
+To run all 64 bit LTP tests:
+* `atest vts_ltp_test_arm_64`
+
+To run a single test:
+* `atest vts_ltp_test_arm:dio.dio13_32bit`
+
+Running LTP through VTS
+-----------------------
 To run VTS LTP it must first be built. VTS is not device specific, you need not
 compile it specifically for the device you wish to run it on, assuming it is
 the same architecture.
@@ -47,33 +59,19 @@ the same architecture.
 * `lunch`
 * `make -j vts`
 
-Before running VTS ensure your host has the required prerequisites (this need
-only be done once):
-* `. test/vts/script/setup.sh`
-
 Then open vts-tradefed and run the VTS stable set:
 * `vts-tradefed`
-* `vts-tf > run vts-kernel -m VtsKernelLtp`
+* `vts-tf > run vts-kernel -m vts_ltp_test_arm`
 
 If you regularly work with multiple devices it may be useful to specify the
 specific device you wish to run VTS on via the serial number:
-* `vts-tf > run vts-kernel -m VtsKernelLtp -s 000123456789`
-
-Or we can run the staging set:
-* `vts-tf > run vts-kernel -m VtsKernelLtpStaging`
+* `vts-tf > run vts-kernel -m vts_ltp_test_arm -s 000123456789`
 
 Or a specific test within the stable set:
-* `vts-tf > run vts-kernel -m VtsKernelLtp -t dio.dio13`
-
-Maybe several:
-* `vts-tf > run vts-kernel -m VtsKernelLtp -t dio.dio13,fs.stream04`
+* `vts-tf > run vts-kernel -m vts_ltp_test_arm -t dio.dio13_32bit`
 
-You may choose whether to specify bitness of the tests. This would run 4 tests - dio.dio13
-both 32-bit and 64-bit, fs.stream04 64-bit, and fs.lftest01 32-bit:
-* `vts-tf > run vts-kernel -m VtsKernelLtp -t dio.dio13,fs.stream04_64bit,fs.lftest01_32bit`
-
-Running LTP Faster
-------------------
+Running LTP Directly
+--------------------
 
 Running LTP tests within VTS can be quite cumbersome, especially if you are
 iterating a lot trying to debug something. Build and run LTP tests faster by
@@ -142,12 +140,8 @@ set, the staging set, or disabled. Note that being disabled in VTS does not
 affect whether the test is built, but rather determines whether it is run at
 all as part of the stable or staging sets.
 
-The file test/vts-testcase/kernel/ltp/configs/stable_tests.py lists tests that
-will run as part of VTS stable (VtsKernelLtp). The
-test/vts-testcase/kernel/ltp/configs/disabled_tests.py file lists tests that
-are runtime disabled in VTS. If a test is not listed in either of these files,
-but is enabled in the build in external/ltp, then it is in the staging set
-(VtsKernelLtpStaging).
+The file test/vts-testcase/kernel/ltp/testcase/tools/configs/stable_tests.py
+lists tests that will run as part of VTS (vts_ltp_test_arm/vts_ltp_test_arm_64).
 
 When a test is enabled for the first time in VTS it should be in the staging
 set. The behavior of the test will be observed over a period of time and ensure
@@ -164,14 +158,11 @@ If the runtime of LTP changes significantly be sure to update the runtime-hint
 and test-timeout parameters to VTS in
 `test/vts-testcase/kernel/ltp/stable/AndroidTest.xml`.
 
-How do I see or get notified about recent VTS LTP results?
+How do I see recent VTS LTP results?
 ----------------------------------------------------------
 
-The internal portal at go/vts-web shows results for the continuous VTS testing
-done on internal devices. By adding tests such as VtsKernelLtp or
-VtsKernelLtpStaging to your favorites you will get email notifications whenever
-failures are seen.  Be warned, the testing iterates continuously and the
-notification emails can generate a lot of traffic.
+The internal portal at go/vts11-dashboard shows results for the continuous VTS testing
+done on internal devices.
 
 Test results are also gathered by Linaro and may be seen
 [here](https://qa-reports.linaro.org/android-lkft/).
@@ -200,6 +191,10 @@ destabilize your box or cause data loss. If you need to run tests on an x86
 platform and are unsure if they are safe you should run them in emulation, in a
 virtualized environment, or on a dedicated development x86 platform.
 
+To run LTP tests for x86 platform, you can do:
+* `atest vts_ltp_test_x86`
+* `atest vts_ltp_test_x86_64`
+
 Sending Fixes Upstream
 ----------------------