Avoid invalid state in search/discovery queue state machine
The sequence of events in the state machine that causes the bug is as follows: - We start a search, and move from the IDLE state to the SEARCH_ACTIVE state. - We initiate a pairing request, that sets pairing_cb.state to BT_BOND_STATE_BONDING. - We cancel the search, returning to the IDLE state. - We then try to start a second search. In BTA_DmSearch, we check if we are bonding, and if so enqueue the request. - But we remain in the IDLE state! So we never dequeue the search request, getting us into the stuck state. This CL fixes the issue by removing the *_QUEUE_* events, making the state machine the single arbiter for whether a request should be executed or queued. In particular, for the above scenario, the SDP request will queue behind the second search request, if it arrives afterwards, *even if* bonding has already begun. This prevents us from getting in a stuck state. I believe that this is safe since we preserve the invariant of only ever have one request going through at a time, but manual testing is needed to be certain. The preservation of this invariant also means that we should not regress b/237352700, though I am unable to test that. Bug: 230277335 Test: Manual, using the repro steps from the bug thread. Tag: #stability Change-Id: I74e83964995b10f4bee35bae3182ec482bdedb39 (cherry picked from commit d197ce9a) Merged-In: I74e83964995b10f4bee35bae3182ec482bdedb39
Loading
Please register or sign in to comment