mirror of
https://github.com/kidfromjupiter/nearby.git
synced 2026-09-14 22:56:12 -04:00
Anay Wadhera
f26d25ed01
The `RandBytes` functions were being placed in the `crypto` namespace, which collides with Chromium's namespace of the same name. Within, `RandBytes` was defined with almost-the-same API. Then in Chromium builds, the Chromium header would be used instead (though somewhat inconsistently). This creates a lot of pain for Chromium development as there's a third-party repository directly depending on headers from Chromium's source tree, and is against the third-party policies for that reason. There are a number of other headers that mirror Chromium and are swapped out in the Chromium build that will cause similar pain, such as: ``` include "crypto/aead.h" include "crypto/ec_private_key.h" include "crypto/hkdf.h" ``` This CL provides a template for how to get rid of these header swaps and give a platform abstraction in nearby instead. We provide a platform abstraction in `platform/crypto.h` (really in `platform/implementation/crypto.h`) which is implemented in `platform/implementation/shared/crypto.cc`. However that implementation is removed by `#ifdef` when in the Chromium build. Then, in the Chromium repo, we will add (separately) an implementation of the same abstraction in `//third_party/nearby/platform_impl` with GN rules to include it in the build. It will replace the implementation from the nearby repo. Copybara import of the project: -- 6ca8099 by danakj <danakj@chromium.org>: Provide a platform abstraction for RandBytes instead of swapping headers The `RandBytes` functions were being placed in the `crypto` namespace, which collides with Chromium's namespace of the same name. Within, `RandBytes` was defined with almost-the-same API. Then in Chromium builds, the Chromium header would be used instead (though somewhat inconsistently). This creates a lot of pain for Chromium development as there's a third-party repository directly depending on headers from Chromium's source tree, and is against the third-party policies for that reason. There are a number of other headers that mirror Chromium and are swapped out in the Chromium build that will cause similar pain, such as: ``` include "crypto/aead.h" include "crypto/ec_private_key.h" include "crypto/hkdf.h" ``` This CL provides a template for how to get rid of these header swaps and give a platform abstraction in nearby instead. We provide a platform abstraction in `platform/crypto.h` (really in `platform/implementation/crypto.h`) which is implemented in `platform/implementation/shared/crypto.cc`. However that implementation is removed by `#ifdef` when in the Chromium build. Then, in the Chromium repo, we will add (separately) an implementation of the same abstraction in `//third_party/nearby/platform_impl` with GN rules to include it in the build. It will replace the implementation from the nearby repo. -- 9c2654b by danakj <danakj@chromium.org>: Remove CryptoSpan, use absl::Span The header swapping of Chromium crypto libraries is problematic, but absl::Span will convert to base::span so there's no need for the typedef even without removing the header swapping yet. -- df1135d by danakj <danakj@chromium.org>: Add missing files -- ab18a15 by danakj <danakj@chromium.org>: Remove the random_unittest.cc from Swift build The file moved, so the Swift package needs its path updated. -- 2038f78 by danakj <danakj@chromium.org>: Combine crypto unittests into crypto_test.cc -- f7ad176 by danakj <danakj@chromium.org>: Add stdint and stddef includes for uint8_t and size_t -- 9f04590 by danakj <danakj@chromium.org>: Mark the shared crypto implementation compatable_with non_prod -- 18eeafd by danakj <danakj@chromium.org>: Add IWYU pragma for crypto implementation PiperOrigin-RevId: 632150866
Nearby
Nearby is a collection of projects focused on connectivity that enable building cross-device experiences.
This is not an officially supported Google product.
Projects
Nearby Connections
A peer-to-peer networking API that allows apps to easily discover, connect to, and exchange data with nearby devices in real-time, regardless of network connectivity.
Fast Pair
Utilizes Bluetooth Low Energy (BLE) to discover nearby Bluetooth devices without using significant phone battery, enabling "magical" scenarios based on device proximity.
Nearby Presence
An extension to Nearby Connections that features an extensible identity model for authentication and restricted visibility, resource management for system health, and proximity detection through sensor fusion.
Nearby for Embedded Systems
A lightweight implementation of Fast Pair intended for embedded systems.
Contributing
We encourage you to contribute to Nearby! Please check out the Contributing to Nearby guide for guidelines about how to proceed.
License
Nearby is released under the Apache License 2.0