FastPairScanner::ScanningSession and ScannerBroker::ScanningSession separate
the lifetime of FastPairScanner/ScannerBroker from the lifetime of scanning
sessions. This simplifies the cleanup.
PiperOrigin-RevId: 535675988
Objective-C objects cannot be captured by reference in C++ lambdas and must always be captured by value.
This also takes a copy of the data returned from the Wi-Fi LAN reader, to prevent potential intermittent empty packet issues.
Fixes: #1702
PiperOrigin-RevId: 533925980
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
Changes in the compilers made it to where some includes would not be
included in some headers (see [this](https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes) for more info) and one of those includes were `cstdint` / `stdint.h`. This commit brings the dependancy abseil-cpp to a commit that fixes that issue and included the relavent files in internel headers to fix the problem.
This was causing the receiving device to consistently (~9/10 times) get stuck in the "waiting for other device to accept" state.
PiperOrigin-RevId: 531295543
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
Introduces a tested `GNCIPAddress` class to make it more explicit of which IP address format is being used at call sites to prevent similar issues in the future.
PiperOrigin-RevId: 528572993
During Fast pair handshake, the seeker writes to GATT characteristics, the
provider reads the value and sends the response.
We need callbacks for reading and writing GATT characteristics to test the
handshake. Static GATT DB entries are not sufficient.
PiperOrigin-RevId: 527958868
Janusz Sobczak