Open Droppix opened 2 months ago
@reminvg can you take a look at this?
Sorry...I don't understand??
Yep, looks like some caching issue.
May it be connected somehow with the latest update of Google Play Services to 24.23.35? As before that I didn't observe such an issue.
Actually I do not know whether GPS has been updated or not but update came from Samsung: One UI version: 6.1 Android version: 14 Versions: G99.../../... Size: 2157.27 MB Security fix level: 1st may of 2024
@bourdakos1 @RemiNVG could you please advise us what may be the cause of that?
… and let us know the reason behind this:
E/NearByService(31054): com.google.android.gms.common.api.ApiException: 13: ERROR
E/NearByService(31054): at com.google.android.gms.internal.nearby.zzdo.setFailedResult(com.google.android.gms:play-services-nearby@@19.2.0:1)
E/NearByService(31054): at com.google.android.gms.internal.nearby.zzce.zzb(com.google.android.gms:play-services-nearby@@19.2.0:4)
E/NearByService(31054): at com.google.android.gms.internal.nearby.zzfr.zza(com.google.android.gms:play-services-nearby@@19.2.0:3)
E/NearByService(31054): at com.google.android.gms.internal.nearby.zzb.onTransact(com.google.android.gms:play-services-nearby@@19.2.0:3)
E/NearByService(31054): at android.os.Binder.execTransactInternal(Binder.java:1380)
E/NearByService(31054): at android.os.Binder.execTransact(Binder.java:1311)
On trying to discover a second time one can see in logs these errors:
2024-06-30 19:56:52.776 15057-7489 NearbyMediums com.google.android.gms.persistent E MEDIUM_ERROR [SYSTEM][WIFI_LAN][CONNECT][ESTABLISH_CONNECTION_FAILED][UNKNOWN], service-id=com.example.nbs
2024-06-30 19:56:52.797 15057-7489 NearbyMediums com.google.android.gms.persistent E MEDIUM_ERROR [SYSTEM][WIFI_LAN][CONNECT][ESTABLISH_CONNECTION_FAILED][UNKNOWN], service-id=com.example.nbs
2024-06-30 19:56:52.807 15057-7489 NearbyMediums com.google.android.gms.persistent E MEDIUM_ERROR [SYSTEM][WIFI_LAN][CONNECT][ESTABLISH_CONNECTION_FAILED][UNKNOWN], service-id=com.example.nbs
DNS-SD services have some TTL for caching, generally 2min, so if a service disappears (for example the remote device disconnecting from the network), it will still appear to be there when restarting discovery, for the duration of the TTL. To avoid such issues it would be best for the Nearby layer to double-check a device is still connectable.
There was also an issue with services being kept in the cache for too long that could make the problem worse, but should get fixed via google play system update soon.
@RemiNVG Thanks for the reply! Could you please let us know when the update will be released? Or, at least, at what date the fix is scheduled to be available?
Thanks in advance!
And will the fix update address just a second issue, i.e. keeping a service for a long period, or TTL decreasing/zeroing as well?
I'm not sure it addresses everything in this issue (in particular it's expected that a service may still be found within its TTL if the advertising device just disconnected), but the fix I'm mentioning is https://r.android.com/2440004. Before, TTL-expired services would only be removed periodically (due to migration from an older design), so it was possible they stick around for longer than they should, but that change ensures expired services never get returned.
Most devices should have it enabled in a later Google Play System Update, but that will likely take a small number of months (the change to enable it was merged later in AOSP). You should be able to see the fixed behavior on Pixel devices with a recent update already as they opted in to a feature flag rollout including this fix.
Project
Nearby Connections
Language
Other
OS Platform
Other
What happened?
I set up a connection between Android (startDiscovery) and Swift (startAdvertising), and then after accepting the connection (iOS side), a connection is established. When I call stopDiscovery on Android, and "cleanly" stop the process on iOS (stopAdvertising + disconnect), if I restart startDiscovery on the Android side, it still sees the old EndPoint (event -> onEndpointFound), while the connections on the iOS side are all cut...
Impossible to clean up properly, the only solution is to restart the Android device.
What did you expect to happen?
explain above
How can we reproduce it (as minimally and precisely as possible)?
1/ StartDiscovery on Android 2/ StartAdvertising on iOS 3/ Android: Connect to EndPoint (requestConnection) 4/ iOS: AcceptConnection 5/ Android: StopDiscovery 6/ iOS: StopAdvertising 7/ iOS: Disconnect
How often does this bug happen?
Every time
Standalone code to reproduce the issue
...
Relevant log output
No response
Anything else we need to know?
No response