Add CancellationFlag::Uncancel and on calls to ClientProxy::AddCancellationFlag, if a flag is already in the map, uncancel it. This will address the case when users use NC to share/receive a file, then cancel in the middle because the wrong file was selected, and then re-do right after. Without this change, the second share/receive process will be seen as cancelled with cancellation flags enabled. However this change will uncancel the flag which is added in RequestConnection and OnConnectionInitiated in the NS flow.
PiperOrigin-RevId: 540633470
CancellationFlags will be used to prevent crashes during the shutdown of Nearby Connections from pending tasks taking too long during the shutdown period. By using CancellationFlags, we can prevent the retries occuring during the Shutdown by short-circuiting an in flight AttemptToConnect, and checking for Cancellation before retries.
Because BluetoothClassic does not use futures, the short circuit only requires a check after ConnectToService, and returning an empty
socket.
PiperOrigin-RevId: 539755631
CancellationFlags will be used to prevent crashes during the shutdown of Nearby Connections from pending tasks taking too long during the shutdown period. WebRTC using 3 x 10s retries to connect, which means we are potentially waiting for 30 seconds of retries to execute during shutdown (which is longer than the 10s duration alloted for Core shutdown).
By using CancellationFlags, we can prevent the retries occuring during the Shutdown by short-circuiting an in flight AttemptToConnect, and checking for Cancellation before retries.
PiperOrigin-RevId: 539690403
To prevent invalid access of already destroyed CancellationFlag pointers, do not erase the map entry of a CancellationFlag in ClientProxy::CancelEndpoint. Crashes were caused by consumers accessing CancellationFlag::Cancelled to check if the flags were cancelled, however since the flags was destroyed by erasing the map entry in ClientProxy::CancelEndpoint, consumers are calling gabrage memory.
PiperOrigin-RevId: 536470187
To prevent invalid access of already destroyed CancellationFlag pointers, do not clear the map of CancellationFlags in ClientProxy::CancelAllEndpoints. Crashes
were caused by consumers accessing CancellationFlag::Cancelled to check if the flags were cancelled, however since the flags were destroyed by erasing the map in ClientProxy::CancelAllEndpoints, consumers are calling gabrage memory.
PiperOrigin-RevId: 535284214
During the destruction of NearbyConnections, Core (which owns ClientProxy) is destructed before ServiceController (which owns EndpointManager), which means any pending tasks on the EndpointManager executor that use ClientProxy will be using
garbage memory. To fix this issue, EndpointManager::DiscardEndpoint will check
for an `is_shutdown` boolean set during ~EndpointManager before accessing
ClientProxy. The assumption is that any accessing of ClientProxy after the
destruction will be invalid.
PiperOrigin-RevId: 532581122
Added:
nearby::api::ble_v2::BlePeripheral::GetUniqueId()
nearby::api::ble_v2::BleMedium::GetRemotePeripheral(...)
Moved BlePeripheral implementation from bluetooth_adapter_* to ble_v2.*
Added G3 (test) implementation for the new methods.
PiperOrigin-RevId: 531023568
Anay Wadhera