IssueTracker

It's easy to write a multithreaded benchmark that doesn't wait on all work to finish by the end of measureRepeated {}

This extra work can massively corrupt subsequent benchmark, and should be relatively easy to spot with atrace, once we have that in.

Not sure how to surface this - we could start with logcat/studio output, maybe escalate to test failure if we're confident about it.

Can sleep at the end of each affected test to try and recover, but it's possible to get into a very hosed state. E.g. if a test simply posts an expensive runnable to another thread - the test may finish in 500ms, but it could have scheduled hours of bg thread work.