Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

An endpoint that never goes away (Low-Level) #2472

Open
Droppix opened this issue Apr 22, 2024 · 13 comments
Open

An endpoint that never goes away (Low-Level) #2472

Droppix opened this issue Apr 22, 2024 · 13 comments
Labels
P2 Priority 2 issue (the default for issues we're likely to work on after P0/P1 issues) platform: android An issue with the Android implementation platform: apple An issue with the macOS or iOS implementation type: bug Something is broken or not working as intended

Comments

@Droppix
Copy link

Droppix commented Apr 22, 2024

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

@Droppix Droppix added needs-triage Issue still needs to be assigned, labeled and deduplicated type: bug Something is broken or not working as intended labels Apr 22, 2024
@bourdakos1
Copy link
Collaborator

@RemiNVG can you take a look at this?

@bourdakos1 bourdakos1 added P2 Priority 2 issue (the default for issues we're likely to work on after P0/P1 issues) platform: apple An issue with the macOS or iOS implementation platform: android An issue with the Android implementation and removed needs-triage Issue still needs to be assigned, labeled and deduplicated labels Apr 22, 2024
@Droppix
Copy link
Author

Droppix commented Apr 22, 2024

Sorry...I don't understand??

@yerzhant
Copy link

yerzhant commented Jun 30, 2024

I guess the same is here

@yerzhant
Copy link

Yep, looks like some caching issue.

@yerzhant
Copy link

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.

@yerzhant
Copy link

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

@yerzhant
Copy link

yerzhant commented Jun 30, 2024

@bourdakos1 @RemiNVG could you please advise us what may be the cause of that?

@yerzhant
Copy link

yerzhant commented Jun 30, 2024

… 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)

@yerzhant
Copy link

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

@RemiNVG
Copy link

RemiNVG commented Jul 1, 2024

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.

@yerzhant
Copy link

yerzhant commented Jul 1, 2024

@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!

@yerzhant
Copy link

yerzhant commented Jul 1, 2024

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?

@RemiNVG
Copy link

RemiNVG commented Jul 5, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 Priority 2 issue (the default for issues we're likely to work on after P0/P1 issues) platform: android An issue with the Android implementation platform: apple An issue with the macOS or iOS implementation type: bug Something is broken or not working as intended
Projects
None yet
Development

No branches or pull requests

4 participants