Add DisplayContent to hierarchy after stubbing.
doAnswer type of stubing doesn't completely eliminate race conditions. The failure happens because when answers are commited to InvocationContainerImpl it uses a local variable invocationForStubbing to save the stubbing method, which could be changed from a different thread by a natural call into the mock/spy before answers are added to InvocationContainerImpl. Sequence of events: 1) [testing thread] Commiting stubbing by calling method into the mock/spy. In this case it could be DisplayContent#supportsSystemDecoration() in line 159 in TestDisplayContent in this case. The call was intercepted by MockHandlerImpl#handle() and further handled by InvocationContainerImpl#setMethodForStubbing(), in which it already set invocationForTesting field and didn't clear doAnswerStyleStubbing yet. 2) Another thread calls into the same mock/spy regularly. In this case it is DisplayContent#getDisplay() as shown in the stack trace in the bug. It's intercepted by MockHandlerImpl#handle() as well and likely it thinks we're in the process of doAnswers style procssing and calls into setMethodForStubbing(). It then mistakenly think we're stubbing DisplayContent#getDisplay() and found the answer we offered isn't compatible in the return value. This is a caveat in Mockito thread safety, though it can be fixed in Mockito if they're willing to do so. However it's certainly a lot faster to fix it in our test code. Also check the caller holds global lock in lieu of synchronization clause because caller is supposed to be in tests with RunWith(WindowTestRunner.class) annotation. Bug: 144611135 Test: atest com.android.server.wm.AnimatingActivityRegistryTest Change-Id: I8cc4b6ce11ad6c205309476c9eeb4db315f558d6
Loading
Please register or sign in to comment