gfps/附耳没有收到UUID+0x184E.md

附耳没有收到UUID 0x184E

[BBPRO3BUG-27045] [BBPRO3][EVB][E Cut][PEGA_HA_v1.0.4_20251106][24110 testbin][GFPS][FastPair][LEA phone]Personalized Name Update 测试 fail - Jira

https://partnerissuetracker.corp.google.com/u/0/issues/473688165

\

\

hi hao:

The provider is TWS earbuds and has two components.

primary address：20 24 19 97 88 00
secondary address： 19 00 17 17 00 19

17:07:47 Fast Pair validator show "Pairing process error: Reason: Only receive correct UUID from 1 address"
At this point, on the phone side,  is it to check if the UUID 0x184E has been received?

//maybe seeker already received 0x184E?
01-05 17:07:47.413 10186  2772  5000 I NearbyDiscovery: FastPairUtils: isBluetoothDeviceSupportingTargetUuid: Target profile found, profile=0000184e-0000-1000-8000-00805f9b34fb, mac=XX:XX:XX:XX:00:19 [CONTEXT service_id=265 ]
01-05 17:07:47.413 10186  2772  5000 I NearbyDiscovery: FastPairUtils: isBluetoothDeviceSupportingLeaUuid: Lea profile found, mac=XX:XX:XX:XX:00:19 [CONTEXT service_id=265 ]



can you help see the reason?


thanks

bugreport-caiman_beta-BP41.250916.015.A1-2026-01-05-17-08-27.zip
20 MBDownload

Tue Jan 06 2026 15:07:51 GMT+0800 (中国标准时间).png
869 KBViewDownload

Comments

All comments

haoho@google.com<haoho@google.com> #2Jan 6, 2026 05:58PM

Reassigned to danni_dong@realtek.corp-partner.google.com.

Hi Danni,

When a device has two components, the Validator expects to receive UUID events from both. The error message Pairing process error: Reason: Only receive correct UUID from 1 address indicates that we did not receive the UUID from the secondary component.

For future troubleshooting, it would be better if you could provide the full logcat (using adb logcat > log.txt). The current logs do not provide enough information for a detailed analysis.

Thanks!

Danni Dong<danni_dong@realtek.corp-partner.google.com> #3Jan 6, 2026 06:02PM

Reassigned to haoho@google.com.

hi  hao
XX:XX:XX:XX:00:19 is the secondary bud

//maybe seeker already received 0x184E?
01-05 17:07:47.413 10186  2772  5000 I NearbyDiscovery: FastPairUtils: isBluetoothDeviceSupportingTargetUuid: Target profile found, profile=0000184e-0000-1000-8000-00805f9b34fb, mac=XX:XX:XX:XX:00:19 [CONTEXT service_id=265 ]

haoho@google.com<haoho@google.com> #4Jan 6, 2026 06:09PM

Reassigned to danni_dong@realtek.corp-partner.google.com.

Hi Danni,

The UUID event arrival was significantly delayed.
Our test timed out at the exact same second the event was received.
Could you investigate why there was such a long latency for the UUID event?

01-05 17:07:47.413 10186  2772  5000 I NearbyDiscovery: FastPairUtils: isBluetoothDeviceSupportingTargetUuid: Target profile found, profile=0000184e-0000-1000-8000-00805f9b34fb, mac=XX:XX:XX:XX:00:19 [CONTEXT service_id=265 ]
01-05 17:07:47.413 10186  2772  5000 I NearbyDiscovery: FastPairUtils: isBluetoothDeviceSupportingLeaUuid: Lea profile found, mac=XX:XX:XX:XX:00:19 [CONTEXT service_id=265 ]

// Test timeout
01-05 17:07:47.612 10298  7314  9879 I BaseModuleTask: event=ModuleEvent{message=Pairing process error. Reason: Only receive correct UUID from 1 address
01-05 17:07:47.612 10298  7314  9879 I BaseModuleTask: , status=FAILURE}, callback=dzj@52da1a, executor=bah@ad7e9e8
01-05 17:07:47.616 10298  7314  9879 I BaseModuleTask: event=ModuleEvent{message=Test finished, status=FAILURE}, callback=dzj@52da1a, executor=bah@ad7e9e8
01-05 17:07:47.616 10298  7314  9879 W BaseModuleTask: Failed to finish test for PersonalizedNameUpdateTask

Danni Dong<danni_dong@realtek.corp-partner.google.com> #5Jan 7, 2026 10:09AM

Reassigned to haoho@google.com.

hi hao:

Does the seeker determine whether it has received UUID 0x184E by checking if it has received UUID 0x184e from the LE Audio Advertising data?
Wed Jan 07 2026 10:04:20 GMT+0800 (中国标准时间).png

Wed Jan 07 2026 10:04:20 GMT+0800 (中国标准时间).png
226 KBViewDownload

Danni Dong<danni_dong@realtek.corp-partner.google.com> #6Jan 7, 2026 10:26AM

We observed that the phone accessed the 0x184e service around 17:06:51.
Therefore, we would like to ask how the phone determines whether it has received the 0x184E service UUID.
thanks
Wed Jan 07 2026 10:23:39 GMT+0800 (中国标准时间).png

Wed Jan 07 2026 10:23:39 GMT+0800 (中国标准时间).png
180 KBViewDownload

haoho@google.com<haoho@google.com> #7Jan 7, 2026 10:47AM

Reassigned to danni_dong@realtek.corp-partner.google.com.

Hi Danni,

In the Android, there is a UUID broadcast mechanism where the Bluetooth stack sends an ACTION_UUID intent to the app layer. Upon receiving this broadcast, the Validator checks for 0x184e (for LE Audio cases) or verifies A2DP and HFP (for Classic Bluetooth cases).

According to the Android Developers website, this intent is only triggered when the remote device's UUIDs are fetched via the Service Discovery Protocol.

Danni Dong<danni_dong@realtek.corp-partner.google.com> #8Jan 8, 2026 11:00AM

hi hao:
provider has GATT caching enabled,  and the seeker seems to be using a cached service table,  so seeker doesn't start to  do  Service Discovery again?

GFPS_spec_gattcaching.png
285 KBViewDownload

Danni Dong<danni_dong@realtek.corp-partner.google.com> #9Jan 8, 2026 11:17AM

Reassigned to haoho@google.com.

here is the new log with logcat （103820）fail

bugreport-caiman_beta-BP41.250916.015.A1-2026-01-07-10-38-33.zip
19 MBDownload

FILENAME7.log
27 MBViewDownload

20260107 27045.zip
1.9 MBDownload

haoho@google.com<haoho@google.com> #10Jan 8, 2026 12:39PM

Reassigned to danni_dong@realtek.corp-partner.google.com.

Hi Danni,

Looks like you succeeded the first time.

[FILENAME7.log]
01-07 10:36:40.025  9477  9555 D BaseModuleTask: Succeed to finish test for PersonalizedNameUpdateTask

In failed case, we only receive UUID from XX:XX:XX:XX:88:00, but not XX:XX:XX:XX:00:19.

01-07 10:37:24.296  9477  9477 I BaseModuleTask: event=ModuleEvent{message=Received UUID from XX:XX:XX:XX:88:00, status=SUCCESS}, callback=dzj@cabcee2, executor=bah@a20c9cc
01-07 10:37:24.297  9477  9477 D FeatureTestActivity: ModuleEvent{message=Received UUID from XX:XX:XX:XX:88:00, status=SUCCESS}
01-07 10:38:20.067  9477 10309 I BaseModuleTask: event=ModuleEvent{message=Pairing process error. Reason: Only receive correct UUID from 1 address

If the earbuds didn't receive the SDP, I suspect it might be due to a Bluetooth cache issue.
If that's the case, I think we can disregard this instance, especially since you’ve successfully passed the test before.
Do you have any other concerns regarding this?

Danni Dong<danni_dong@realtek.corp-partner.google.com> #11Jan 8, 2026 02:09PM

Reassigned to haoho@google.com.

hi hao:

it's not 100% reproducible, but the probability of reproduction is very high 5/10.
Do you mean that if we fail 5 out of 10 times, is that acceptable? Or is it acceptable as long as we pass 1 out of 10 times?
Don't certification labs use Fast Pair Validator testing? What should we do if the certification lab encounters a similar problem?

If it's a Bluetooth cache issue, how can we clear the cache?

thanks

haoho@google.com<haoho@google.com> #12Jan 8, 2026 05:04PM

Reassigned to danni_dong@realtek.corp-partner.google.com.

Hi Danni,

According to your test results, the UUID event is not related to the naming feature. Therefore, you can safely ignore it.

Regarding the certification labs, they do not use the Validator app. Since they perform testing manually, you won't encounter the same issue there.

I hope this clears up your doubts.

Add comment