Make tests wait correctly for Drawing to complete.
Some tests had followed a pattern in which they modified elements of a
view, and then wished to wait for the view to be drawn, after which
they wished to query side-effects of that drawing -- for example, the
bounds of a BitmapDrawable that had been stretched to fill a layout.
These tests had used Instrumentation.waitForIdleSync() to do this
waiting, but this turns out not to be correct -- drawing is not
guaranteed to be complete when this returns. Some of these tests had
then accomplished further waiting by using PollingChecks. This is
undesirable for a number of reasons: it involves an arbitrary timeout
value, failures are reported as timeouts rather than violations of the
desired predicate, and they are applied inconsistently.
With advice from John Reck, I was able to create another idiom that
did this waiting correctly. This CL introduces DrawWaiter, which
allows a test to wait for drawing to complete after modifications that
will induce a draw are made. It applies it in various cases where
previous code had used PollingWaits, and other cases where we had
previously determined that further PollingWaits would decrease test
flakiness.
This subsumes the work in
https://android-review.googlesource.com/#/c/255580
Notes to reviewer:
(1) In ListViewTest.java, I had initially applied this idiom much
more widely, and found that the test hung in some places. In the
first case I investigated, I determined that the state
modification was setting something to it's previous value, so it
wasn't causing a draw to be required. I fixed that, but then ran
into a further hang that I couldn't figure out. So I decided to
be more conservative in making use of this new idiom
(2) Also: I'm a little unclear on the mInstrumentation.runOnMainSync
idiom used in ListViewTest, and whether it's equivalent to
running on the UI thread wrt the correctness of DrawWaiter. Any
comment would be appreciated.
Change-Id: I79be2291f0b9f2511fb72c5bdb950faf8235c920
3 files changed