bdbb2527e6
Change-Id: I71e676b997159a141ca07d16f82a73b45f4b2410
7.9 KiB
1.耳机支援LEA,手机也支援LEA,测试fail
https://partnerissuetracker.corp.google.com/u/0/issues/419110816
hi Mark:
‘EIK Rotation’ test fail, can you help see the reason, thanks.
test fail screen: Wed May 21 2025 10:06:37 GMT+0800 (中国标准时间).png
20:01:31 phone rotating EIK and disconnect this ACL link,
when headsets receive disconnect command, The new EIK will take effect immediately after the BLE connection is terminated.
however headsets seems do not receive this disconnect command,
we check logs in phone set:
//20:01:31.628 BluetoothGatt.disconnect
Line 23078: 05-20 20:01:31.628 10290 14358 31585 I GattClientImpl: BluetoothGatt.disconnect() - B8:17:43:1C:C6:CD [CONTEXT service_id=284 ]
however headsets seems do not receive this disconnect command,
we also check air log, At 20:01:31, there was no disconnection command in the air log.
Is it because the cmd to terminate the connection on the mobile phone was not sent out?
Add the following information:
The disconnection at 20:01:53 was received by both the air log and the headphone log.
Line 24568: 05-20 20:01:53.076 10290 14358 31594 I GattClientImpl: BluetoothGatt.disconnect() - B8:17:43:1C:C6:CD [CONTEXT service_id=284 ]
thanks
\
add more information:
The headset supports LE audio.
When tested with a phone that does not support LE audio, EIK rotation test succeeds.
When tested with a phone that supports LE audio, EIK rotation test fails.
\
\
Reassigned to 
There seem to be another connection to the same device preventing the ACL from disconnecting. The connection is created a few seconds the Validator tests are run, perhaps during the pairing request which is the part of the test setup (logcat logs missing for that time)
36659 20:01:05.523604 controller host HCI_EVT 34 Rcvd LE Meta (LE Extended Advertising Report) worldeliteel_1c:c6:cd 00 Common Audio
36674 20:01:05.548200 host controller HCI_CMD 62 Sent LE Extended Create Connection [v1]
36676 20:01:05.592129 controller host HCI_EVT 34 Rcvd LE Meta (LE Enhanced Connection Complete [v1]) worldeliteel_1c:c6:cd
Connection Handle: 0x0041
LE Audio could be keeping this connection.
::le_audio 2025-05-20 20:01:14.743 CONN_STATE GID -1 CONNECTING_BY_USER (0x05) -> : xx:xx:xx:xx:c6:cd ->CONNECTED_BY_USER_GETTING_READY (0x06)
::le_audio 2025-05-20 20:01:17.869 CONN_STATE GID 1 CONNECTED_BY_USER_GETTING_READY (0x06) -> : xx:xx:xx:xx:c6:cd ->CONNECTED (0x01)
::le_audio 2025-05-20 20:01:53.104 CONN_STATE GID -1 CONNECTED (0x01) -> : xx:xx:xx:xx:c6:cd ->DISCONNECTING (0x03)
::le_audio 2025-05-20 20:01:53.104 CONN_STATE GID -1 DISCONNECTING (0x03) -> : xx:xx:xx:xx:c6:cd ->REMOVING (0x02)
All GATT connect/disconnect request via API don't trigger actual ACL connects/disconnects on the controller till this one:
05-20 20:01:31.628 I GattClientImpl: BluetoothGatt.disconnect() - B8:17:43:1C:C6:CD [CONTEXT service_id=284 ]
42909 20:01:53.102405 host controller HCI_CMD 7 Sent Disconnect
Connection Handle: 0x0041
@tonyysliu@google.com - do you know whether FP or LEA stack could be creating/holding this connection?
‘
’
\
gmark@google.com<gmark@google.com> #9May 28, 2025 06:11PM
Marked as fixed.
Per logs it indeed seems that the initial connection is created by Fast Pair, then while the link is open, profiles are connected and this link is kept used throught the test till profiles are disconnected due to removing the bond. Forcibly removing the bond is expected to fix this.
[bugreport-tokay-BP1A.250505.005-2025-05-28-14-25-36.zip]
05-28 14:22:32.091 I FastPair: FPDC: Starting to pair XX:XX:XX:XX:19:19: key[64], ...
// Device is being connected to.
05-28 14:22:32.110 D BluetoothGatt: connect() - device: XX:XX:XX:XX:19:19, auto: false
10535 14:22:32.155421 controller host HCI_EVT 34 Rcvd LE Meta (LE Enhanced Connection Complete [v1]) 19:22:77:19:19:19
14:22:38.931 xx:xx:xx:xx:19:19 bond_state_changed BOND_STATE_BONDED
05-28 14:22:40.198 D BluetoothAdapter: HEADSET connected
05-28 14:22:40.201 D BluetoothAdapter: LE_AUDIO connected
05-28 14:22:40.209 D CachedBluetoothDevice: onProfileStateChanged: profile LE_AUDIO, device XX:XX:XX:XX:19:19, newProfileState 1
05-28 14:22:40.217 D CachedBluetoothDevice: onProfileStateChanged: profile VCP, device XX:XX:XX:XX:19:19, newProfileState 1
05-28 14:22:40.261 D CachedBluetoothDevice: onProfileStateChanged: profile LE_AUDIO, device XX:XX:XX:XX:19:19, newProfileState 1
05-28 14:22:40.275 D CachedBluetoothDevice: onProfileStateChanged: profile VCP, device XX:XX:XX:XX:19:19, newProfileState 1
// Does not disconnect due to connected profiles
05-28 14:22:40.281 D BluetoothGatt: close()
// All following connect/close calls (skipped) do not affect the underlying connection, it's kept open.
// Validator closes the connection followed by unbonding, results in closing the underlying connection
05-28 14:23:15.878 I GattClientImpl: gatt.close() [CONTEXT service_id=284 ]
05-28 14:23:15.878 D BluetoothGatt: close()
14:23:15.895 xx:xx:xx:xx:19:19 btif_dm_remove_bond BOND_STATE_NONE
13261 14:23:15.909981 controller host HCI_EVT 7 Rcvd Disconnect Complete
The potential fix is submitted and expected to be included in the next Validator's version.