tree 130cc20321007b29fa7a9dd43897d7133b28fa54
parent b5776701117dad69e3db903af38bf3e8553dc31f
author Hall Liu <hallliu@google.com> 1468525988 -0700
committer Hall Liu <hallliu@google.com> 1468525988 -0700

Fix flaky tests that use startAndMakeActiveOutgoingCall

When startActiveOutgoingCall runs, it calls into Telecom to begin the
call setup process, which posts two messages to the handler in
android.telecom.ConnectionService on the main thread:
MSG_ADD_CONNECTION_SERVICE_ADAPTER and MSG_CREATE_CONNECTION, in that
order.

On the first run through, mAreAccountsInitialized in ConnectionService
will be set to false, so instead of calling straight into
handleCreateConnectionComplete in Telecom, the execution of
MSG_CREATE_CONNECTION will instead put it in a list of pending tasks.

This list of pending tasks eventually gets run by a runnable that is
posted to the handler during the execution of
MSG_ADD_CONNECTION_SERVICE_ADAPTER.

Meanwhile, the test continues to run, and executes waitForHandlerAction
in outgoingCallCreateConnectionComplete. If waitForHandlerAction posts
its latch to the looper before MSG_ADD_CONNECITON_SERVICE_ADAPTER
executes, the test will continue before the runnable that the execution
of MSG_ADD_CONNECTION_SERVICE_ADAPTER posts to the handler runs.

This is an undesirable outcome, as we may observe the call being set to
active from startAndMakeActiveOutgoingCall first, then being set back to
dialing from CSW.hCCC. This was causing the flakiness observed.

To fix this, another waitForHandlerAction was added immediately after
the first one. We know that MSG_ADD_CONNECTION_SERVICE_ADAPTER has
already executed after the first waitForHandlerAction returns, which
means that the runnable that it posted is already in the queue, so if we
post another latch, we can be sure that the runnable which calls
CSW.hCCC has run by the time the second waitForHandlerAction completes.

Change-Id: Iedd3c60b39a8bb185f1f2b0d0e064059f888312d