Creates the feature flag `enable_ble_v2_async_scanning_advertising` which
enables/disables the use of the async StartScanning, StopScanning,
StartAdvertising, StopAdvertising, etc methods over the soon-to-be deprecated
synchronous versions of those methods. Opted for feature flag over NearbyFlag,
as ChromeOS is the only current consumer and doesn't use Mendel.
Also sets the feature flag to enabled in the ServiceControllerRouter, which
is where ChromeOS sets NC feature flags at startup.
This CL also fully links up the asynchronous Scanning methods. Advertising
will be addressed in a follow up CL.
PiperOrigin-RevId: 608158273
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
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
Previously reading from an empty, closed Pipe returned:
* IO exception if there were no writes to the pipe,
* Empty byte array if there were writes to the pipe.
With this change, we return an empty byte array on both paths.
This also fixes a subtle race condition in the following flow:
1. Pipe is empty
2. Thread A is reading from the pipe (blocking call).
3. Thread B writes to the pipe and immediately closes it.
4. Thread A is unblocked and returns IO error. The data written by thread B is
ignored!
The new test in bluetooth_classic_test triggered that defect consistently.
PiperOrigin-RevId: 518107700
Suet-Fei Li