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

* changes:
  RootCanal: Properly determine link key type
  RootCanal: Move feature loader to features.rs
  RootCanal: Move link key notification to pairing

* Partially support P256 SC authentication
* Determine link key type from SC and IO capabilities

Tag: #feature
Test: atest liblmp_tests
Bug: 238092436
Change-Id: I00673f011d944ddf5ccce748cad2a4ac4770e6bc

Tag: #refactor
Bug: 235777894
Test: atest liblmp_tests
Change-Id: Iab535d7cb16550cd3ee4350602d4e79d919225d4

* Move link_key_notification to pairing because they are not a part of
  auth and pairing info is required to determine key type later.
* Properly return comb key in legacy pairing

Tag: #refactor
Test: atest liblmp_tests --host
Bug: 235777894
Change-Id: Iaee68ebe5d1525072e99bc1a7a55cfe5865d3a9b

This CL adds tests for following methods of BluetoothPbapObexServer:
- onConnect
- onDisconnect
- onAbort
- onPut
- onDelete
- onClose
- onAuthenticationFailure
- closeStream
- logHeader

Remaining ones will be handled in a different CL.

Bug: 237548430
Test: atest BluetoothPbapObexServerTest
Change-Id: I8813f812f7d4125eb0bdbef5953bc96fc2e0af7b
Merged-In: I8813f812f7d4125eb0bdbef5953bc96fc2e0af7b

Add bond state event parsing to map/match the ChromeOS libstructured
schema. Add debug logging before metrics submission.

BUG: 232098615
Tag: #floss
Test: emerge-${BOARD} floss
Test: ./build.py
BYPASS_LONG_LINES_REASON: Bluetooth likes 120 lines

Change-Id: I08d7b90ee98e63e31f1266653eac1162bcfa9806

This missing enforcement were spotted by the erroprone build

Bug: 236759221
Test: m RUN_ERROR_PRONE=true Bluetooth
Change-Id: I5285f0754775c56a73ad1b6eef4bdb7ec3d59757

Test: manual test file
Change-Id: I1a4e02387911b7e78bf1d3f5757f6e008a90388d

In btservice/AdapterService.java and IBluetooth.aidl a lot of method
have improper RequirePermission annotation

Bug: 236759221
Test: m RUN_ERROR_PRONE=true Bluetooth
Merged-In: Id2f2c1fbf1e172547fa60c567325730295cac99b
Change-Id: Id2f2c1fbf1e172547fa60c567325730295cac99b

PD#SWPL-87827
BUG=238433619

Problem:
Bluetooth LE Secure Server Test fail
Bluetooth LE CoC secure Client Test fail

Solution:
If public address type, mulit adv use public type.

The new unit test wasn't tested becasue bluetooth_test_gd was disabled.

Test: adt3
Bug: 238433619
Change-Id: Ib032bcc9500ed2dc1856b52d90d229bc2d9d1e54
Signed-off-by: hong.wang <hong.wang@amlogic.com>

Tag: #feature
Bug: 239437774
Test: atest pts-bot:SM/CEN/EKS -v

Change-Id: I28e02c7e1f87341b50e24f2d0488add779ccdde6

When we invoke bta_dm_remname_cback, if we are waiting for a response
from a request sent in the DM module, but instead got a response from
SEC, we want to ignore it entirely, rather than updating the state
machine but then continuing to accept other events.

Bug: 231150390
Tag: #stability
Test: manual
Change-Id: I416fd112c270cc5725aec378cc9698a10911f02e

This tool will plumb APIs with the given names from the
Topshim layer to the GD Controller layer.

 Topshim
  |
  v
 BTIF
  |
  v
 BTA
  |
  v
 BTM
  |
  v
 Controller Shim
  |
  v
 GD Controller

It doesn't account for arguments, you will need to manually add them.

It doesn't account for inband callbacks either, you will need to manuall add
those.

In some cases your code may not compile immediately, but it is usually
only 1 or 2 syntax errors in the controller shim/gd controller layer if
it happens at all.

The script will auto commit and rebase for comment editing to add things
like the following...

Bug: 235505882
Test: mma -j $(nproc)
Test: ./build.py
Change-Id: Iabe05192b8adbd0067d9146139f6b4a6efbdf20a

Fix the log.h missing dependency of init_flag for ChromeOS by adding
init_flags.h when building for Floss. In addition, update BUILD.gn
files to include init_flags_bridge_header wherever log utilities are
used.

BUG: 232098615
Tag: #floss
Test: emerge-${BOARD} floss
Test: ./build.py
Change-Id: Ieac199eece21444d79003382d2e33fe337162b06

Test: atest pts-bot:SDP/SR -v
Bug: 239469107
Change-Id: I75606064c67dac1406547db459b4fa17a78efd5e

The tBTM_REMOTE_DEV_NAME.bd_addr was never set but we do use it to
decide if we can remove the callback in bta_dm_remname_cback.
Without the fix we are triggering too many remote name request. They
will eventually conflict with each other and ends in the busy state.
At this point if the stack is performing a search, we could receive
delayed sdp_result that will end in a crash.

Repro steps:
 * Start a search on phone
 * Pair & connect from carkit
 * Crash should occur (1~4% repro).

Without any logs nor fix, crash is around 15%+ repro
With the fix, the 'crash situation' only appear around 1~2% and it no
longer crash
Crash situation as been identified to match with the following logs
    `BTM_ReadRemoteDeviceName is busy`

Bug: 231150390
Test: Execute repro step above
Change-Id: I317f5d689a9efb85d997a38470712ed3d8e0c531

Some HFP test need to start waiting for a connection BEFORE the test
start and we need the address to wait for it

Bug: 237447510
Test: atest pts-bot
Change-Id: I3df66abb2c5a99f14459beee93e7784fdc6caf19

This patch address review comments for the patch which is already merged
in internal branch.

Bug: 233975367
Test: atest BluetoothInstrumentationTests
Tag: #feature
Change-Id: I26b4deed716610b98cfd08cfd2ac43fd0ecfab65

Create the HFP layer inside pts-bot.

Add the following HFP test:
  * HFP/AG/HFI/BI-03-I
  * HFP/AG/HFI/BV-02-I
  * HFP/AG/SLC/BV-09-I
  * HFP/AG/SLC/BV-10-I

Bug: 237447510
Test: atest pts-bot:HFP/AG/HFI
Test: atest pts-bot:HFP/AG/SLC
Test: atest pts-bot
Change-Id: I410b9d3a9b73ba49c7743dac7fd3db0aaf31da93