# 附耳没有收到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\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\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\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\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\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\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\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\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\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\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\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