Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://developers.google.com/nearby/fast-pair/specifications/service/provider below:

Fast Pair | Google for Developers

Stay organized with collections Save and categorize content based on your preferences.

When the Provider device is BR/EDR discoverable (that is, in pairing mode), it shall advertise Fast Pair Model ID Data over BLE, and the BLE address shall not be rotated.

The interval between advertisements should be no larger than 100ms (10Hz). A fast rate allows the Seeker to quickly find the Provider, even when scanning in low-power mode.

The advertisement shall contain the Service Data data type, ibid., § 1.11. The UUID shall be the Fast Pair Service UUID of 0xFE2C. The service data shall contain the following:

When not discoverable (that is, not in pairing mode), the Provider device shall advertise Fast Pair Account Data, using the following guidelines.

Advertising the account data allows Seekers nearby to recognize when a provider belongs to their account and initiate pairing without having to force the provider back into pairing mode first, which is a common cause for user complaint. Seekers will provide the opportunity for users to be able to ignore this broadcast in the case where they do not wait to pair with the provider or the broadcast is not relevant (for example, if they have already paired). Seekers will also filter out obviously bad broadcasts automatically, such as when the account data is misconfigured.

The interval between advertisements should be at most 250ms (4Hz).

The advertisement shall contain the Service Data data type, Ibid., § 1.11. The UUID shall be the Fast Pair Service UUID of 0xFE2C. The service data shall contain the following:

• V = version
• F = flags

The Account Key Data contains:

• L = length of account key filter in bytes
• T = type

• length = 0bLLLL = varies
• type = 0b0000 (show UI indication) or 0b0010 (hide UI indication), Account Key Filter

• L = length in bytes
• T = type

• length = 0b0010 = 2
• type = 0b0001, Salt

The advertised Account Key Filter allows a Seeker to quickly check whether a Provider might possess a certain account key (with a low false-positive probability, on average much less than 0.5%), before further interactions. The Seeker may automatically connect and attempt to start the procedure when it sees a filter being broadcast with type 0, i.e. showing UI indication, that potentially contains one of its account keys, so as to reduce the rate of false positives further. In some situations, the Provider may want to be recognized by the Seeker while not ready for pairing. One example is that when buds get put back into case, we want to stop showing the subsequent pairing notification since that pairing could be rejected by the headset.

The Account Key Filter is a variable-length Bloom filter constructed as follows:

1. Let n be the number of account keys (n >= 1) in the persisted Account Key list.
2. Let s, the size of the filter in bytes, be (1.2*n + 3) truncated. For example, if 1 key is persisted, s = 4 bytes.
   uint8_t s = (((uint8_t)(( float )1.2 * n)) + 3);
3. Initialize the filter F as an array of s bytes, each set to 0.
   uint8_t F[s] = {0};

4. For each account key K in the persisted Account Key list:
   a. Let V be concat(K, Salt).
   

   // In the sample code, the size of salt is 2 bytes.
   #define SALT_SIZE 2
   
   uint8_t V[FASTPAIR_ACCOUNT_KEY_SIZE + SALT_SIZE];
   for (uint8_t keyIndex = 0; keyIndex < n; keyIndex++)
     {
        // concat (K, Salt)
         fastpair_get_account_key_by_index(keyIndex, V);
   
         uint8_t randomSalt = (uint8_t)rand();
         V[FASTPAIR_ACCOUNT_KEY_SIZE] = randomSalt;
         ... }
   

   b. Hash V using SHA256, obtaining a 32-byte value H = {H₀, …, H₃₁}.

   uint8_t H[32] = {0};
   SHA256_hash_function(V, H);
   

   c. Divide H into eight 4-byte unsigned integers in big-endian, X = {X₀, …, X₇}, where X₀ = 0xH₀H₁H₂H₃.

        uint32_t X[8];
        for (index = 0; index < 8; index++)
        {
           X[index] = (((uint32_t)(H[index * 4])) << 24) |
                       (((uint32_t)(H[index * 4 + 1])) << 16) |
                       (((uint32_t)(H[index * 4 + 2])) << 8) |
                       (((uint32_t)(H[index * 4 + 3])) << 0);
        }
   

   d. For each X_i:
   i. Let M be X_i modulo the number of bits in the filter, (s * 8).
   ii. Get the byte in F at index (M / 8), rounded down.
   iii. Within the byte, set the bit at index (M % 8) to 1.
   iv. In other words:
   

       // M = Xi % (s * 8)
       // F[M/8] = F[M/8] | (1 << (M % 8))
       for (index = 0; index < 8; index++)
       {
           uint32_t M    = X[index] % (s * 8);
           F[M / 8] = F[M / 8] | (1 << (M % 8));
       }
   

Include the filter F as the Account Key Filter field, in the advertising data. Note that there is no "endianness" to this value, since there is no more or less significant byte—don't alter the byte order.

The salt is a random value that is appended to account keys when building the bloom filter. This salt should be regenerated every time the RPA is updated for the Provider to avoid tracking across address rotation.

To generate the Account Key Filter using the salt:

1. Generate a random 2-byte S. Note that there is no "endianness" to this value, since there is no more or less significant byte — don't alter the byte order.
2. Use the 2-byte S as the Salt.
3. In the advertised Fast Pair Account Data, include the generated filter in the Account Key Filter field, and S in the Salt field.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-01-16 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-01-16 UTC."],[[["Provider devices advertise Fast Pair Model ID Data over BLE when in pairing mode to enable quick discovery by Seeker devices."],["When not discoverable, Provider devices advertise Fast Pair Account Data, allowing Seekers to recognize them and initiate pairing without requiring the Provider to re-enter pairing mode."],["The Account Key Filter, a Bloom filter included in the Account Key Data, helps Seekers quickly assess the potential presence of a specific account key on the Provider, reducing false positives and unnecessary pairing attempts."],["The salt, a random value appended to account keys during Bloom filter construction, is regenerated with each Provider RPA update to prevent tracking across address rotations, enhancing privacy."]]],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3