Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Signal de publicité du fournisseur
Publicité: quand elle est visible
Lorsque l'appareil du fournisseur est détectable par BR/EDR (c'est-à-dire en mode association), il doit diffuser les données d'ID de modèle Fast Pair via BLE, et l'adresse BLE ne doit pas être pivotée.
L'intervalle entre les annonces ne doit pas dépasser 100 ms (10 Hz). Un débit élevé permet au chercheur de trouver rapidement le fournisseur, même lors de la numérisation en mode basse consommation.
Charge utile publicitaire: données d'ID de modèle Fast Pair
L'annonce doit contenir le type de données "Données des services", ibid., § 1.11. L'UUID doit être l'UUID du service Fast Pair de 0xFE2C. Les données du service doivent contenir les éléments suivants:
Octet
Type de données
Description
Valeur
0-2
uint24
ID de modèle 24 bits
varie ;
Publicité: lorsque l'application n'est pas visible
Lorsqu'il n'est pas détectable (c'est-à-dire qu'il n'est pas en mode association), l'appareil du fournisseur doit diffuser les données de compte Fast Pair en suivant les consignes suivantes.
La diffusion des données du compte permet aux chercheurs à proximité de reconnaître quand un fournisseur appartient à leur compte et de lancer l'association sans avoir à forcer le fournisseur à revenir en mode association, ce qui est une cause courante de réclamations des utilisateurs. Les requêtes de recherche permettent aux utilisateurs d'ignorer cette diffusion s'ils n'attendent pas d'être associés au fournisseur ou si la diffusion n'est pas pertinente (par exemple, s'ils sont déjà associés).
Les chercheurs filtrent également automatiquement les diffusions manifestement incorrectes, par exemple lorsque les données du compte sont mal configurées.
Intervalle de diffusion des annonces: lorsque l'application n'est pas visible
L'intervalle entre les annonces doit être de 250 ms maximum (4 Hz).
Charge utile publicitaire: données du compte Fast Pair
L'annonce doit indiquer le type de données "Données des services", Ibid., § 1.11. L'UUID doit être l'UUID du service Fast Pair de 0xFE2C. Les données du service doivent contenir les éléments suivants:
Octet
Type de données
Description
Valeur
0
uint8
Version et indicateurs 0bVVVVFFFF
V = version
F = indicateurs
0x00 (réservé pour une utilisation ultérieure)
1 : varie
Données de clé de compte
varie
Les données de clé de compte contiennent les éléments suivants:
Octet
Type de données
Description
Valeur
0
uint8
Longueur et type de champ 0bLLLLTTTT
L = longueur du filtre de clé de compte en octets
T = type
0bLLLL0000
length = 0bLLLL = varie
type = 0b0000 (afficher l'indication dans l'UI) ou 0b0010 (masquer l'indication dans l'UI), filtre de clé de compte
Le filtre de clé de compte annoncé permet à un chercheur de vérifier rapidement si un fournisseur peut posséder une certaine clé de compte (avec une faible probabilité de faux positifs, en moyenne bien inférieure à 0,5%) avant d'autres interactions. Le chercheur peut se connecter automatiquement et tenter de démarrer la procédure lorsqu'il voit un filtre diffusé avec le type 0, c'est-à-dire qu'il affiche une indication d'interface utilisateur qui contient potentiellement l'une de ses clés de compte, afin de réduire davantage le taux de faux positifs. Dans certains cas, le fournisseur peut souhaiter être reconnu par le chercheur alors qu'il n'est pas prêt à l'association. Par exemple, lorsque les écouteurs sont remis dans l'étui, nous souhaitons arrêter d'afficher la notification d'association ultérieure, car cette association pourrait être refusée par le casque.
Le filtre de clé de compte est un filtre Bloom à longueur variable construit comme suit:
Supposons que s, la taille du filtre en octets, soit (1,2*n + 3) tronquée. Par exemple, si une seule clé est conservée, s = 4 octets. uint8_t s = (((uint8_t)(( float )1.2 * n)) + 3);
Initialisez le filtre F en tant que tableau d'octets s, chacun défini sur 0. uint8_t F[s] = {0};
// In the sample code, the size of salt is 2 bytes.#define SALT_SIZE 2uint8_tV[FASTPAIR_ACCOUNT_KEY_SIZE+SALT_SIZE];for(uint8_tkeyIndex=0;keyIndex < n;keyIndex++){// concat (K, Salt)fastpair_get_account_key_by_index(keyIndex,V);uint8_trandomSalt=(uint8_t)rand();V[FASTPAIR_ACCOUNT_KEY_SIZE]=randomSalt;...}
b. Hachez V à l'aide de SHA256, ce qui vous donne une valeur de 32 octets H = {H0, …, H31}.
uint8_tH[32]={0};SHA256_hash_function(V,H);
c. Divisez H en huit entiers non signés de 4 octets en big-endian, X = {X0, …, X7}, où X0 = 0xH0H1H2H3.
d. Pour chaque Xi:
i. Soit M la valeur Xi modulo le nombre de bits du filtre (s * 8).
ii. Récupère l'octet dans F à l'index (M / 8), arrondi à l'entier inférieur.
iii. Dans l'octet, définissez le bit à l'indice (M % 8) sur 1.
iv. Autrement dit:
// M = Xi % (s * 8)// F[M/8] = F[M/8] | (1 << (M % 8))for(index=0;index < 8;index++){uint32_tM=X[index]%(s*8);F[M/8]=F[M/8]|(1 << (M%8));}
Incluez le filtre F comme champ de filtre de clé de compte dans les données publicitaires.
Notez qu'il n'y a pas d'ordre de grandeur pour cette valeur, car il n'y a pas d'octet plus ou moins significatif. N'altérez pas l'ordre des octets.
Marais salant
Le sel est une valeur aléatoire qui est ajoutée aux clés de compte lors de la création du filtre Bloom. Ce sel doit être régénéré chaque fois que l'RPA est mis à jour pour le fournisseur afin d'éviter le suivi lors de la rotation des adresses.
Pour générer le filtre de clé de compte à l'aide du sel:
Générez un S de 2 octets aléatoire. Notez qu'il n'y a pas d'endianness pour cette valeur, car il n'y a pas d'octet plus ou moins significatif. N'altérez pas l'ordre des octets.
Utilisez S à deux octets comme sel.
Dans les données de compte Fast Pair annoncées, incluez le filtre généré dans le champ "Filtre de clé de compte" et S dans le champ "Salage".
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/13 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/08/13 (UTC)."],[[["\u003cp\u003eProvider devices advertise Fast Pair Model ID Data over BLE when in pairing mode to enable quick discovery by Seeker devices.\u003c/p\u003e\n"],["\u003cp\u003eWhen 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.\u003c/p\u003e\n"],["\u003cp\u003eThe 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.\u003c/p\u003e\n"],["\u003cp\u003eThe 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.\u003c/p\u003e\n"]]],[],null,["Provider Advertising signal\n---------------------------\n\n### Advertising: When discoverable\n\nWhen the Provider device is BR/EDR discoverable (that is, in pairing mode), it\nshall advertise Fast Pair Model ID Data over BLE, and the BLE address shall not\nbe rotated.\n\n#### Advertising interval: When discoverable\n\nThe interval between advertisements should be no larger than 100ms (10Hz). A\nfast rate allows the Seeker to quickly find the Provider, even when scanning in\nlow-power mode.\n\n#### Advertising payload: Fast Pair Model ID Data\n\nThe advertisement shall contain the Service Data data type, ibid., § 1.11. The\nUUID shall be the Fast Pair Service UUID of `0xFE2C`. The service data shall\ncontain the following:\n\n| Octet | Data type | Description | Value |\n|-------|-----------|-----------------|----------|\n| 0-2 | `uint24` | 24-bit model ID | *varies* |\n\n### Advertising: When not discoverable\n\nWhen not discoverable (that is, not in pairing mode), the Provider device shall\nadvertise Fast Pair Account Data, using the following guidelines.\n\nAdvertising the account data allows Seekers nearby to recognize when a provider\nbelongs to their account and initiate pairing without having to force the\nprovider back into pairing mode first, which is a common cause for user\ncomplaint. Seekers will provide the opportunity for users to be able to ignore\nthis broadcast in the case where they do not wait to pair with the provider or\nthe broadcast is not relevant (for example, if they have already paired).\nSeekers will also filter out obviously bad broadcasts automatically, such as\nwhen the account data is misconfigured.\n\n#### Advertising interval: When not discoverable\n\nThe interval between advertisements should be at most 250ms (4Hz).\n\n#### Advertising payload: Fast Pair Account Data\n\nThe advertisement shall contain the Service Data data type, Ibid., § 1.11. The\nUUID shall be the Fast Pair Service UUID of `0xFE2C`. The service data shall\ncontain the following:\n\n| Octet | Data type | Description | Value |\n|--------------|-----------|--------------------------------------------------------|----------------------------------|\n| 0 | `uint8` | Version and flags 0bVVVVFFFF - V = version - F = flags | `0x00` (reserved for future use) |\n| 1 - *varies* | | Account Key Data | *varies* |\n\n| **Note:** The provider shall advertise its Fast PairAccount Data only if the Account Key List has one or more entries.\n\nThe Account Key Data contains:\n\n| Octet | Data type | Description | Value |\n|-------------------|-----------|-----------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------|\n| 0 | `uint8` | Field length and type 0bLLLLTTTT - L = length of account key filter in bytes - T = type | 0bLLLL0000 - length = 0bLLLL = *varies* - type = 0b0000 (show UI indication) or 0b0010 (hide UI indication), Account Key Filter |\n| 1 - *s* | | Account Key Filter | *varies* |\n| *s* + 1 | `uint8` | Field length and type 0bLLLLTTTT - L = length in bytes - T = type | 0b00100001 - length = 0b0010 = 2 - type = 0b0001, [Salt](#SaltField) |\n| *s* + 2 - *s* + 3 | `uint16` | Salt | *varies* |\n\n#### Account Key Filter\n\n| **Note:** Google recommends implementing the [Cryptographic Test Cases](/nearby/fast-pair/specifications/appendix/cryptotestcases \"Link to the Cryptographic Test Cases.\") to ease verification of these requirements.\n\nThe advertised Account Key Filter allows a Seeker to quickly check whether a\nProvider might possess a certain account key (with a low false-positive\nprobability, on average much less than 0.5%), before further interactions. The\nSeeker may automatically connect and attempt to start the procedure when it sees\na filter being broadcast with type 0, i.e. showing UI indication, that\npotentially contains one of its account keys, so as to reduce the rate of false\npositives further. In some situations, the Provider may want to be recognized\nby the Seeker while not ready for pairing. One example is that when buds get put\nback into case, we want to stop showing the subsequent pairing notification\nsince that pairing could be rejected by the headset.\n\nThe Account Key Filter is a variable-length\n[Bloom filter](https://en.wikipedia.org/wiki/Bloom_filter) constructed as\nfollows:\n\n1. Let *n* be the number of account keys (*n* \\\u003e= 1) in the persisted [Account Key list](/nearby/fast-pair/specifications/configuration#AccountKeyList \"Account Key List\").\n2. 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. \n `uint8_t s = (((uint8_t)(( float )1.2 * n)) + 3);`\n3. Initialize the filter *F* as an array of *s* bytes, each set to 0. \n `uint8_t F[s] = {0};`\n4. For each account key *K* in the persisted [Account Key list](/nearby/fast-pair/specifications/configuration#AccountKeyList \"Account Key List\"): \n\n a. Let *V* be concat(*K* , [Salt](#SaltField)). \n\n // In the sample code, the size of salt is 2 bytes.\n #define SALT_SIZE 2\n\n uint8_t V[FASTPAIR_ACCOUNT_KEY_SIZE + SALT_SIZE];\n for (uint8_t keyIndex = 0; keyIndex \u003c n; keyIndex++)\n {\n // concat (K, Salt)\n fastpair_get_account_key_by_index(keyIndex, V);\n\n uint8_t randomSalt = (uint8_t)rand();\n V[FASTPAIR_ACCOUNT_KEY_SIZE] = randomSalt;\n ... }\n\n b. Hash *V* using SHA256, obtaining a 32-byte value *H* =\n {H~0~, ..., H~31~}. \n\n uint8_t H[32] = {0};\n SHA256_hash_function(V, H);\n\n c. Divide *H* into eight 4-byte unsigned integers in big-endian,\n X = {X~0~, ..., X~7~}, where\n X~0~ = 0xH~0~H~1~H~2~H~3~. \n\n uint32_t X[8];\n for (index = 0; index \u003c 8; index++)\n {\n X[index] = (((uint32_t)(H[index * 4])) \u003c\u003c 24) |\n (((uint32_t)(H[index * 4 + 1])) \u003c\u003c 16) |\n (((uint32_t)(H[index * 4 + 2])) \u003c\u003c 8) |\n (((uint32_t)(H[index * 4 + 3])) \u003c\u003c 0);\n }\n\n d. For each X~i~: \n\n i. Let *M* be *X~i~* modulo the number of bits in the filter,\n (*s* \\* 8). \n\n ii. Get the byte in *F* at index (*M* / 8), rounded down. \n\n iii. Within the byte, set the bit at index (*M* % 8) to 1. \n\n iv. In other words: \n\n // M = Xi % (s * 8)\n // F[M/8] = F[M/8] | (1 \u003c\u003c (M % 8))\n for (index = 0; index \u003c 8; index++)\n {\n uint32_t M = X[index] % (s * 8);\n F[M / 8] = F[M / 8] | (1 \u003c\u003c (M % 8));\n }\n\nInclude the filter *F* as the Account Key Filter field, in the advertising data.\nNote that there is no \"endianness\" to this value, since there is no more or less\nsignificant byte---don't alter the byte order.\n\n##### Salt field\n\nThe salt is a random value that is appended to account keys when building the\nbloom filter. This salt should be regenerated every time the RPA is updated for\nthe Provider to avoid tracking across address rotation.\n\nTo generate the Account Key Filter using the salt:\n\n1. 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.\n2. Use the 2-byte *S* as the Salt.\n3. In the advertised Fast Pair Account Data, include the generated filter in the Account Key Filter field, and *S* in the Salt field."]]
