I caught an interesting result
- Advertiser advertised its endpoint id 'wjys'
- Discoverer requested connection to 'wjys'
- Advertiser restarted (stopAllEndpoints, disconnect from GoogleApiClient)
- Advertiser advertised its new endpoint id 'PChU'
- Discoverer discovered Advertiser again (id=PChU)
- Discoverer gets onConnectionInitiated with the old id (wjys)
- Both devices accept
- Amazingly, the two devices could still communicate, even though Discoverer sent and received messages using old Advertiser id (wjys).
Is this behavior a bug?
That's a bug. I've filed a ticket internally to get it fixed. If you stop advertising, you should not be connectable by anyone who saw the old advertisement. Let us know if you catch any other weird edge cases like this! :)
To understand why this bug happens, the following is a small part about how Connections works:
The endpoint id is sent as a part of the advertisement, and it forms an id-mac address pair on the Discoverer side. When the Discoverer is told 'requestConnection', it tries to connect to the Mac address associated with the endpoint id. If the device has already stopped advertising, the discoverer will fail to connect, but the discoverer will retry internally a few times just to make sure. If the advertiser restarts advertising quickly enough, it becomes connectable again and the discoverer's retry may succeed (because the Bluetooth mac address never rotates). This is true even if the advertisement is different.
