קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
אות פרסום של ספק
פרסום: מתי המודעות גלויות
כשמכשיר הספק גלוי ל-BR/EDR (כלומר, במצב התאמה), הוא צריך לפרסם נתונים של מזהה דגם של התאמה מהירה דרך BLE, ולא תתבצע רוטציה של כתובת ה-BLE.
מרווח הזמן לפרסום: כשהמודעות גלויות
המרווח בין המודעות לא יכול להיות ארוך מ-100 אלפיות השנייה (10Hz). קצב מהיר מאפשר למכשיר המחפש למצוא במהירות את הספק, גם כשהסריקה מתבצעת במצב צריכת אנרגיה נמוכה.
נתוני עומס פרסום: נתוני מזהה הדגם של התאמה מהירה
המודעה צריכה לכלול את סוג הנתונים 'נתוני שירות', שם, 1.11. ה-UUID יהיה ה-UUID של שירות ההתאמה המהירה של 0xFE2C. נתוני השירות צריכים לכלול את הפרטים הבאים:
אוקטט
סוג הנתונים
תיאור
ערך
0-2
uint24
מזהה דגם של 24 סיביות
משתנה
פרסום: כשהחשבון לא גלוי
כשהמכשיר של הספק לא גלוי (כלומר, לא במצב התאמה), הוא צריך לפרסם את נתוני החשבון של התאמה מהירה לפי ההנחיות הבאות.
פרסום נתוני החשבון מאפשר לחפשים בסביבה לזהות מתי ספק מסוים שייך לחשבון שלהם ולהתחיל את ההתאמה בלי שתצטרכו לאלץ את הספק לחזור למצב התאמה קודם, מה שגורם לתלונות נפוצות מצד המשתמשים. מודעות ה-Seeker יאפשרו למשתמשים להתעלם מהשידור במקרה שהם לא ממתינים להתאמה עם הספק או שהשידור לא רלוונטי (לדוגמה, אם הם כבר התאימו). המערכת תסנן באופן אוטומטי גם שידורים ברורים שהם לא טובים, למשל במקרים שבהם נתוני החשבון מוגדרים באופן שגוי.
מרווח הזמן להצגת מודעות: כשהסרטון לא גלוי
המרווח בין המודעות צריך להיות 250 אלפיות השנייה (4Hz) לכל היותר.
נתוני תשתית הפרסום: נתוני חשבון של התאמה מהירה
המודעה צריכה לכלול את סוג הנתונים Service Data, שם, 1.11. ה-UUID יהיה ה-UUID של שירות ההתאמה המהירה של 0xFE2C. נתוני השירות צריכים לכלול את הפרטים הבאים:
אוקטט
סוג הנתונים
תיאור
ערך
0
uint8
גרסה ודגלים 0bVVVVFFFF
V = גרסה
F = דגלים
0x00 (שמור לשימוש עתידי)
1 – משתנה
נתוני מפתח החשבון
משתנה
נתוני מפתח החשבון מכילים את הפרטים הבאים:
אוקטט
סוג הנתונים
תיאור
ערך
0
uint8
אורך השדה וסוג השדה 0bLLLLTTTT
L = האורך של מסנן מפתח החשבון בבייטים
T = type
0bLLLL0000
length = 0bLLLL = varies
type = 0b0000 (הצגת אינדיקציה בממשק המשתמש) או 0b0010 (הסתרת אינדיקציה בממשק המשתמש), מסנן של מפתח חשבון
הסינון של מפתח החשבון שמוצג במודעה מאפשר למחפש לבדוק במהירות אם לספק מסוים יש מפתח חשבון מסוים (עם הסתברות נמוכה לזיהוי שגוי של תוצאה חיובית, בממוצע פחות מ-0.5%), לפני אינטראקציות נוספות. כדי לצמצם עוד יותר את שיעור הזיהויים השגויים, החיפוש עשוי להתחבר באופן אוטומטי ולנסות להתחיל את התהליך כשהוא מזהה מסנן שמשודר עם סוג 0, כלומר עם אינדיקציה בממשק המשתמש, שעשוי להכיל אחד ממפתחות החשבון שלו. במקרים מסוימים, יכול להיות שהספק ירצה להימצא במצב שבו הוא מזוהה על ידי המכשיר המחפש, גם אם הוא לא מוכן להתאמה. דוגמה לכך היא כשהאוזניות מוחזרות למארז. אנחנו רוצים להפסיק להציג את ההתראה הבאה על ההתאמה, כי יכול להיות שהיא תידחה על ידי אוזניות ההשתלה.
מסנן מפתח החשבון הוא מסנן Bloom באורך משתנה שנוצר באופן הבא:
נניח ש-s, הגודל של המסנן בבייטים, הוא (1.2*n + 3) חתוך. לדוגמה, אם מפתח אחד נשמר, הערך של s הוא 4 בייטים. uint8_t s = (((uint8_t)(( float )1.2 * n)) + 3);
מאתחלים את המסנן F כמערך של s בייטים, שכל אחד מהם מוגדר ל-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;...}
ב. מבצעים גיבוב (hash) של V באמצעות SHA256, ומקבלים ערך של 32 בתים H = {H0, …, H31}.
uint8_tH[32]={0};SHA256_hash_function(V,H);
ג. מחלקים את H לשמונה מספרים שלמים לא חתומים באורך 4 בייטים בפורמט big-endian, X = {X0, …, X7}, כאשר X0 = 0xH0H1H2H3.
ד. לכל Xi: i. מגדירים את M כ-Xi modulo מספר הביטים במסנן, (s * 8). 2. אחזור הבייט ב-F במדד (M / 8), מעוגל כלפי מטה. 3. בתוך הבייט, מגדירים את הבייט באינדיקציה (M % 8) לערך 1. 4. במילים אחרות:
// 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));}
כוללים את המסנן F בתור השדה Account Key Filter (מסנן מפתח החשבון) בנתוני הפרסום. שימו לב שאין לערכים האלה 'סדר ביטים', כי אין בייט משמעותי יותר או פחות – אל תשנו את סדר הבייטים.
שדה מלח
המלח הוא ערך אקראי שמצורף למפתחות החשבון בזמן יצירת מסנן ה-Bloom. צריך ליצור מחדש את המלח הזה בכל פעם ש-RPA מתעדכן, כדי שהספק לא יעקוב אחרי רוטציית כתובות.
כדי ליצור את המסנן של מפתח החשבון באמצעות המלח:
יוצרים S אקראי באורך 2 בייטים. שימו לב שאין לערכים האלה 'endianness', כי אין בייט משמעותי יותר או פחות – אל תשנו את סדר הבייטים.
משתמשים ב-S בן 2 בייטים בתור המלח.
בנתוני החשבון של Fast Pair שמוצגים, צריך לכלול את המסנן שנוצר בשדה Account Key Filter ואת הערך S בשדה Salt.
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 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\nAdvertising: 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\nAdvertising 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\nAdvertising 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\nAdvertising: 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\nAdvertising interval: When not discoverable\n\nThe interval between advertisements should be at most 250ms (4Hz).\n\nAdvertising 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\nAccount Key Filter **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\nSalt 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."]]
