تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
إشارة الإعلانات المقدَّمة من مقدّم الخدمة
الإعلانات: الحالات التي يمكن فيها العثور على التطبيق
عندما يكون جهاز الموفِّر قابلاً للاكتشاف عبر بروتوكول BR/EDR (أي في وضع الإقران)، يجب أن يُعلِن عن بيانات معرّف طراز "الإقران السريع" عبر تقنية BLE، ويجب عدم تبديل عنوان BLE.
الفاصل الزمني للإعلانات: عندما تكون الإعلانات قابلة للاكتشاف
يجب ألا يزيد الفاصل الزمني بين الإعلانات عن 100 ملي ثانية (10 هرتز). تسمح السرعة العالية للمستكشف بالعثور على الموفِّر بسرعة، حتى عند البحث في
وضع الطاقة المنخفضة.
الحمولة الإعلانية: بيانات معرّف طراز "الإقران السريع"
يجب أن يحتوي الإعلان على نوع البيانات "بيانات الخدمة"، راجع المصدر نفسه. § 1.11. يجب أن يكون
المعرّف الفريد العام هو المعرّف الفريد العام لخدمة "الإقران السريع" في 0xFE2C. يجب أن تحتوي بيانات الخدمة
على ما يلي:
وحدة ثمانيّة البت
نوع البيانات
الوصف
القيمة
0-2
uint24
معرّف الطراز بسعة 24 بت
تختلف
الإعلانات: الحالات التي لا يمكن فيها العثور على الإعلانات
عندما لا يكون الجهاز مرئيًا (أي ليس في وضع الإقران)، يجب أن يُعلِن جهاز الموفِّر عن "بيانات حساب الإقران السريع" باستخدام الإرشادات التالية.
من خلال عرض بيانات الحساب، يمكن للباحثين القريبين منك معرفة ما إذا كان مقدّم الخدمة تابعًا لحسابك وبدء عملية الإقران بدون الحاجة إلى إجبار المقدّم على العودة إلى وضع الإقران أولاً، وهو سبب شائع لتلقّي شكاوى من المستخدمين. ستتيح ميزة "البحث عن الأجهزة" للمستخدمين إمكانية تجاهل
هذا البث في حال عدم انتظار الإقران مع مقدّم الخدمة أو
إذا لم يكن البث ذا صلة (على سبيل المثال، إذا سبق أن تم إقران الجهاز).
ستتم أيضًا فلترة البثّات السيئة بشكل تلقائي من قِبل الباحثين، مثل
في حال ضبط بيانات الحساب بشكل غير صحيح.
الفاصل الزمني للإعلانات: عندما لا تكون قابلة للاكتشاف
يجب ألا تزيد الفترة الزمنية بين الإعلانات عن 250 ملي ثانية (4 هرتز).
الحمولة الإعلانية: بيانات حساب "الإقران السريع"
يجب أن يحتوي الإعلان على نوع البيانات Service Data، راجع المصدر نفسه. § 1.11. يجب أن يكون
المعرّف الفريد العام هو المعرّف الفريد العام لخدمة "الإقران السريع" في 0xFE2C. يجب أن تحتوي بيانات الخدمة
على ما يلي:
وحدة ثمانيّة البت
نوع البيانات
الوصف
القيمة
0
uint8
الإصدار والعلامات 0bVVVVFFFF
V = الإصدار
F = flags
0x00 (محجوزة للاستخدام في المستقبل)
1 - تختلف
بيانات مفتاح الحساب
تختلف
تحتوي بيانات مفتاح الحساب على ما يلي:
وحدة ثمانيّة البت
نوع البيانات
الوصف
القيمة
0
uint8
طول الحقل ونوعه 0bLLLLTTTT
L = طول فلتر مفتاح الحساب بالبايت
T = type
0bLLLL0000
الطول = 0bLLLL = يختلف
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;...}
ب- تجزئة V باستخدام SHA256، والحصول على قيمة H =
{H0, …, H31} من 32 بايت
uint8_tH[32]={0};SHA256_hash_function(V,H);
ج. قسِّم H إلى ثمانية أعداد صحيحة غير موقَّتة بسعة 4 بايت بترتيب كبار السن،
X = {X0, …, X7}، حيث
X0 = 0xH0H1H2H3.
د- لكل قيمة Xi:
1- لنفترض أنّ M هو Xi modulo عدد وحدات البت في الفلتر،
(s * 8).
2- احصل على البايت في F في الفهرس (M / 8)، مع التقريب للأسفل.
3- ضمن البايت، اضبط القيمة 1 على النقطة في الفهرس (M % 8).
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 كسمة "فلتر مفتاح الحساب" في البيانات الإعلانية.
يُرجى العِلم أنّ هذه القيمة لا تتبع ترتيب "endianness"، لأنّه لا يوجد بايت أكثر أو أقل
أهمية، لذا لا تغيِّر ترتيب البايت.
حقل ملح
الملح هو قيمة عشوائية يتم إلحاقها بمفاتيح الحساب عند إنشاء
فلتر Bloom. يجب إعادة إنشاء هذه الملح في كل مرة يتم فيها تعديل RPA لتجنُّب التتبُّع على مستوى تبديل العناوين.
لإنشاء فلتر مفتاح الحساب باستخدام الملح:
أنشئ S عشوائيًا مكوّنًا من بايتين. يُرجى العِلم أنّه لا يوجد ترتيب "endianness" لهذه القيمة، لأنّه لا يوجد أيّ بايت أكثر أهمية أو أقل أهمية، لذا لا تغيِّر ترتيب البايت.
استخدِم الرمز S المكوّن من بايتين كقيمة الملح.
في بيانات حساب "الإقران السريع" المُعلَن عنها، أدرِج الفلتر الذي تم إنشاؤه في حقل
فلتر مفتاح الحساب، و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."]]