1These scripts help generate the libcore TEST_MAPPING smoke tests, i.e. a set of
2tests to run on every change, chosen to run as many as possible in less than
3some time limit.
4
5The process is as follows.
61. Do `source build/envsetup.sh` and `lunch <whatever>` as normal.
72. Run the CtsLibcoreTestCases tests to generate logs to extract timings from.
8   This can be done with `atest CtsLibcoreTestCases` as normal. Make sure to use
9   an appropriate device (virtual or physical).
103. Do that two more times. We'll use best-of-three timings, since sometimes a
11   test takes an unusual amount of time (perhaps because of GC pause or other
12   jank) and it should not be excluded for that.
134. Run the save_logs.py script to copy the logs from out/ to libcore/smoketest.
14   (Empty that directory if it exists already). This is interactive and allows
15   you to pick the runs you want. (If you prefer, you can run this after each
16   run, rather than once after all three runs.)
175. Run the gen_smoke_tests.py script to generate libcore/TEST_MAPPING.
186. Check stdout from the script looks okay (not too many warnings, sensible
19   numbers, etc.).
207. Check the generated TEST_MAPPING looks okay.
218. Do e.g. `time atest --test-mapping libcore` to check it runs okay.
229. Delete libcore/smoketest/ once you're happy.
2310. Submit the new TEST_MAPPING.
24
25The scripts take no options. There are some constants at the start you can
26adjust. (These could be converted to command-line options if convenient.)
27
28See comments in the scripts for more on how they work.
29
30At time of writing, with the current configuration, this generates a sensible
31number of classes to exclude, so the TEST_MAPPING looks reasonable. If this list
32becomes too long, we'll have to find a way to simplify it, by rolling up to a
33higher granularity. Given the way that atest et al are configured, that will
34probably mean excluding more things.
35
36TODO(peteg): What about PTS?
37