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