با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
سیگنال تبلیغاتی ارائه دهنده
تبلیغات: زمانی که قابل کشف باشد
هنگامی که دستگاه ارائه دهنده BR/EDR قابل شناسایی است (یعنی در حالت جفت شدن)، باید داده های شناسه مدل جفت سریع را روی BLE تبلیغ کند و آدرس BLE نباید چرخانده شود.
فاصله زمانی تبلیغات: زمانی که قابل کشف باشد
فاصله بین تبلیغات نباید بیشتر از 100 میلی ثانیه (10 هرتز) باشد. نرخ سریع به جستجوگر اجازه می دهد تا به سرعت ارائه دهنده را پیدا کند، حتی زمانی که در حالت کم مصرف اسکن می کند.
محموله تبلیغاتی: داده های شناسه مدل جفت سریع
آگهی باید شامل نوع داده سرویس، همان، § 1.11 باشد. UUID باید UUID سرویس جفت سریع 0xFE2C باشد. داده های سرویس باید شامل موارد زیر باشد:
اکتت
نوع داده
توضیحات
ارزش
0-2
uint24
شناسه مدل 24 بیتی
متفاوت است
تبلیغات: زمانی که قابل کشف نباشد
هنگامی که قابل کشف نباشد (یعنی در حالت جفت شدن نیست)، دستگاه ارائه دهنده باید داده های حساب جفت سریع را با استفاده از دستورالعمل های زیر تبلیغ کند.
تبلیغ دادههای حساب به جستجوگران نزدیک امکان میدهد تشخیص دهند که ارائهدهنده متعلق به حساب آنها است و جفتسازی را بدون نیاز به وادار کردن ارائهدهنده به حالت جفتسازی ابتدا آغاز کنند، که یک دلیل رایج برای شکایت کاربر است. جستجوگرها این فرصت را برای کاربران فراهم میکنند که بتوانند این پخش را در مواردی که منتظر جفت شدن با ارائهدهنده نیستند یا پخش مرتبط نیست (مثلاً اگر قبلاً جفت شدهاند) را نادیده بگیرند. جستجوگرها همچنین پخشهای بدیهی بدیهی را بهطور خودکار فیلتر میکنند، مانند زمانی که دادههای حساب به درستی پیکربندی نشده است.
فاصله زمانی تبلیغات: زمانی که قابل کشف نباشد
فاصله بین تبلیغات باید حداکثر 250 میلی ثانیه (4 هرتز) باشد.
بار تبلیغاتی: داده های حساب جفت سریع
آگهی باید شامل نوع داده خدمات، همان، § 1.11 باشد. UUID باید UUID سرویس جفت سریع 0xFE2C باشد. داده های سرویس باید شامل موارد زیر باشد:
اکتت
نوع داده
توضیحات
ارزش
0
uint8
نسخه و پرچم ها 0bVVVVFFFF
V = نسخه
F = پرچم
0x00 (برای استفاده در آینده رزرو شده است)
1 - متفاوت است
داده های کلیدی حساب
متفاوت است
داده های کلید حساب شامل:
اکتت
نوع داده
توضیحات
ارزش
0
uint8
طول و نوع میدان 0bLLLLTTTT
L = طول فیلتر کلید حساب بر حسب بایت
T = نوع
0bLLLL0000
طول = 0bLLLL = متفاوت است
نوع = 0b0000 (نمایش نشانگر رابط کاربری) یا 0b0010 (پنهان کردن نشانگر رابط کاربری)، فیلتر کلید حساب
فیلتر کلید حساب تبلیغ شده به جستجوگر اجازه می دهد تا به سرعت بررسی کند که آیا یک ارائه دهنده ممکن است دارای یک کلید حساب خاص (با احتمال مثبت کاذب کم، به طور متوسط بسیار کمتر از 0.5٪) قبل از تعاملات بعدی باشد. جستجوگر ممکن است به طور خودکار متصل شود و زمانی که فیلتری را با نوع 0 در حال پخش میبیند، یعنی نشاندهنده UI را نشان میدهد که احتمالاً یکی از کلیدهای حسابش را در بر میگیرد، بهطور خودکار وصل شده و تلاش میکند تا نرخ مثبت کاذب را بیشتر کاهش دهد. در برخی شرایط، ارائه دهنده ممکن است بخواهد توسط جستجوگر شناسایی شود در حالی که برای جفت شدن آماده نیست. یک مثال این است که وقتی جوانهها دوباره در جعبه قرار میگیرند، میخواهیم نشان دادن اعلان جفتسازی بعدی را متوقف کنیم، زیرا این جفتسازی ممکن است توسط هدست رد شود.
فیلتر کلید حساب یک فیلتر بلوم با طول متغیر است که به شرح زیر ساخته شده است:
اجازه دهید s ، اندازه فیلتر بر حسب بایت، (1.2* n + 3) کوتاه شود. به عنوان مثال، اگر 1 کلید ثابت است، s = 4 بایت. uint8_t s = (((uint8_t)(( float )1.2 * n)) + 3);
فیلتر F را به صورت آرایه ای از s بایت، هر کدام روی 0 تنظیم کنید. uint8_t F[s] = {0};
برای هر کلید حساب K در لیست کلید حساب باقی مانده: الف فرض کنید V concat باشد ( K ، نمک ).
// 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;...}
ب هش V با استفاده از SHA256، به دست آوردن یک مقدار 32 بایتی H = {H 0 , …, H 31 }.
uint8_tH[32]={0};SHA256_hash_function(V,H);
ج H را به هشت عدد صحیح بدون علامت 4 بایتی در big-endian تقسیم کنید، X = {X 0 , …, X 7 }، که در آن X 0 = 0xH 0 H 1 H 2 H 3 .
د برای هر X i : من فرض کنید M باشد X i مدول تعداد بیتهای موجود در فیلتر، ( s * 8). ii بایت را در F در شاخص ( M / 8)، گرد به پایین دریافت کنید. III. در داخل بایت، بیت را در شاخص ( M % 8) روی 1 تنظیم کنید. IV به عبارت دیگر:
// 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 را به عنوان قسمت فیلتر کلید حساب، در داده های تبلیغاتی وارد کنید. توجه داشته باشید که هیچ "Edianness" برای این مقدار وجود ندارد، زیرا بایت کم و بیش قابل توجهی وجود ندارد - ترتیب بایت ها را تغییر ندهید.
مزرعه نمک
نمک یک مقدار تصادفی است که هنگام ساخت فیلتر شکوفه به کلیدهای حساب اضافه می شود. این نمک باید هر بار که RPA برای ارائه دهنده به روز می شود، بازسازی شود تا از ردیابی در چرخش آدرس جلوگیری شود.
برای ایجاد فیلتر کلید حساب با استفاده از salt:
یک S تصادفی 2 بایتی تولید کنید. توجه داشته باشید که هیچ "Edianness" برای این مقدار وجود ندارد، زیرا بایت کم و بیش قابل توجهی وجود ندارد - ترتیب بایت ها را تغییر ندهید.
از S 2 بایتی به عنوان Salt استفاده کنید.
در داده های حساب جفت سریع تبلیغ شده، فیلتر ایجاد شده را در قسمت فیلتر کلید حساب و S را در قسمت نمک قرار دهید.
تاریخ آخرین بهروزرسانی 2025-08-13 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-08-13 بهوقت ساعت هماهنگ جهانی."],[[["\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."]]