تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
الإعداد
الأدوار
يحدّد الملف الشخصي دورَين: الباحث عن الإقران السريع وموفّر الإقران السريع. عادةً ما يكون
الباحث هاتفًا يبحث عن جهاز لإقرانه به. الموفّر هو جهاز يعلن عن توفّره وجاهزيته للإقران (مثل سمّاعات رأس يمكن اكتشافها).
يجب أن يستخدم تطبيق Fast Pair Seeker دور GAP Central. يجب أن يستخدم موفّر Fast Pair دور GAP Peripheral.
رصد الأجهزة
لتسهيل عملية اكتشاف الأجهزة، يجب أن يعلن موفّر خدمة "الإقران السريع" عن حمولة تشير إلى التوافق مع خدمة "الإقران السريع" من Google (مع البيانات الموضّحة أدناه). يجب أن يبحث جهاز Fast Pair Seeker بشكل دوري عن إطارات إعلانات Fast Pair Provider ويراقبها، وأن يتّخذ إجراءً إذا كان مهتمًا.
رقم تعريف الطراز
يحتوي كل طراز من "موفّر" على معرّف طراز مكوّن من 24 بت، وتقدّمه Google أثناء تسجيل الطراز.
قوة الإرسال
يجب أن تعلن أجهزة مقدّم الخدمة عن نفسها بمستوى منخفض من طاقة الإرسال (TxPower) للحدّ من
التعرّض للجهاز المُعلن عنه. ومع ذلك، يجب أن تكون الطاقة عالية بما يكفي
ليتمكّن أي هاتف على بُعد متر واحد على الأقل من رؤية الإعلان.
لتحديد مدى القرب، يجب أن يعرف Fast Pair Seeker مستوى طاقة الإرسال لدى Fast Pair Provider. لأغراض هذا الملف الشخصي، يتم تعريف TxPower على أنّه قوة الإشارة المستلَمة عند المصدر (0 متر)، ويتم قياسها بوحدة ديسيبل ميللي واط (وهذه هي الطريقة نفسها التي يحدّدها بها
Eddystone
).
يجب إرسال القيمة المقاسة باستخدام إحدى الطرق التالية:
المعلومات المضمّنة في سجلّ الإعلان
يتضمّن الجهاز نوع البيانات مستوى طاقة الإرسال، المرجع نفسه، § 1.5، في إعلانه.
المعلومات المقدَّمة أثناء تسجيل النموذج
تزوّد الشركة المصنّعة Google بقدرة الإرسال وطراز الجهاز
المستخدَم لقياسها أثناء عملية تسجيل الطراز.
يجب أن يحافظ الجهاز على ثبات طاقة الإرسال لجميع عمليات البث عند استخدام هذا الخيار لضمان دقة قياسات المسافة.
بعد تسجيل النموذج، ستوزّع Google، بالإضافة إلى رقم تعريف النموذج،
مفتاحًا خاصًا مضادًا للانتحال يبلغ 256 بت (عدد صحيح في [1,n–1] على المنحنى البيضاوي secp256r1). يجب أن يظل هذا المفتاح محفوظًا على جهاز مقدّم الخدمة، ويُفضّل أن يتم تخزينه داخل عنصر آمن (SE). يُرجى العِلم أنّه يُنصح بشدة باستخدام عنصر آمن، وفي حال عدم توفّره، لا يمكن ضمان عدم انتحال المخترقين لدور الموفّر، لأنّه قد يتم تسريب المفتاح الخاص. يؤدي تسريب المفتاح إلى إتاحة إمكانية تنفيذ هجمات الوسيط، لذا في حال رصد انتحال هوية أو إساءة استخدام، قد يتم إيقاف ميزات "الإقران السريع" التي تستخدم هذا المفتاح (على سبيل المثال، الإشعار "النقر للإقران" عندما يكون مقدّم الخدمة في وضع الإقران).
لا يستخدم مقدّم الخدمة حاليًا المفتاح العام الخاص بميزة "مكافحة التزييف". يستخدمه جهاز Seeker لتشفير رسالة لإرسالها إلى جهاز Provider (راجِع الإقران المستند إلى المفتاح).
المفاتيح: قائمة مفاتيح الحساب
يجب أن يخصّص "مقدّم الخدمة" مساحة لتخزين قائمة دائمة من مفاتيح الحسابات التي تبلغ 128 بت. يسمح كل مفتاح حساب بالتعرّف على مقدّم الخدمة على أنّه تابع لحساب مستخدم معيّن.
يجب أن تكون القائمة قادرة على تخزين خمسة مفاتيح على الأقل (أي يجب أن تتوفّر مساحة لا تقل عن 80 بايت مخصّصة لهذه القائمة). يمكن للمزوّدين تخزين أكثر من ذلك بشكل اختياري، ولكن عليهم التأكّد من أنّ المفاتيح ستناسب حزمة الإعلانات. يعتمد العدد الدقيق الذي يمكن تخزينه على عدد وحدات البايت المجانية المتاحة في حزمة الإعلانات. راجِع قسم فلتر مفتاح الحساب لمزيد من المعلومات حول تحديد عدد وحدات البايت التي سيشغلها كل مفتاح. على سبيل المثال، للإعلان عن 10 مفاتيح حسابات، يجب توفير 15 بايت في الحزمة، ولكن بالنسبة إلى الأجهزة الشخصية (مثل سماعات الرأس)، يجب ألا يزيد عدد مفاتيح الحسابات عن 5. ويتم ذلك لتجنُّب أن يصبح عدد مفاتيح الحساب كبيرًا جدًا، وبالتالي يمكن أن يكون فريدًا وقابلاً للتتبُّع.
تكون هذه القائمة فارغة في البداية، ويجب محوها إذا تمت إعادة ضبط موفّر الخدمة على الإعدادات الأصلية (إذا محا المستخدم قائمة الأجهزة المقترنة). يتم ملء القائمة
على النحو الموضّح في قسم سمة مفتاح الحساب.
معلومات عنوان BLE
لمنع التتبُّع، يجب أن تستخدم إعلانات BLE عنوانًا خاصًا عشوائيًا يمكن حله (RPA). يجب تدوير العنوان كل 15 دقيقة على الأقل أثناء إعلان الجهاز بشكل نشط، وفي كل مرة تتغير فيها الحالة من عدم الإعلان إلى الإعلان. يجب استخدام إزاحة عشوائية لتغيير الفاصل الزمني لعشوائية العناوين.
التفاوض على حجم وحدة النقل القصوى (MTU) لبروتوكول السمات (ATT)
يجب استخدام قيمة 83 لوحدة الإرسال القصوى (MTU) في بروتوكول ATT كلما أمكن ذلك، ولكن يُسمح بالقيمة التلقائية 23.
تاريخ التعديل الأخير: 2025-08-13 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eFast Pair uses Bluetooth Low Energy (BLE) and defines two roles: Seeker (typically a phone) and Provider (a device like headphones).\u003c/p\u003e\n"],["\u003cp\u003eProvider devices advertise their presence and support for Fast Pair, allowing Seekers to discover them.\u003c/p\u003e\n"],["\u003cp\u003eEach Provider model has a unique Model ID and transmits at a low power while ensuring discoverability within 1 meter.\u003c/p\u003e\n"],["\u003cp\u003eSecurity is emphasized through anti-spoofing keys and an Account Key list to link the Provider to user accounts.\u003c/p\u003e\n"],["\u003cp\u003ePrivacy is maintained by using random, rotating BLE addresses to minimize tracking.\u003c/p\u003e\n"]]],[],null,["Configuration\n-------------\n\n### Roles\n\nThe profile defines two roles: *Fast Pair Seeker* , and *Fast Pair Provider*. The\nSeeker is normally a phone, looking for a device to pair with. The Provider is a\ndevice that is advertising its presence and readiness to pair (e.g. a\ndiscoverable pair of headphones).\n\nThe Fast Pair Seeker shall use the GAP Central role. The Fast Pair Provider\nshall use the GAP Peripheral role.\n\n### Device discovery\n\nTo facilitate device discovery, the Fast Pair Provider shall advertise a payload\nindicating support for the Google Fast Pair Service (with data as described\nbelow). The Fast Pair Seeker shall periodically scan for and observe the\npresence of Fast Pair Provider advertising frames, and take action if\ninterested.\n\n### Model ID\n\nEach Provider model has a 24-bit model ID, which is provided by Google during\n[Model Registration](/nearby/fast-pair/specifications/service/modelregistration \"Model Registration\").\n\n### Transmit power\n\nProvider devices should advertise at a low transmit power (*TxPower*) to limit\nexposure of the advertised device. However, the power shall be high enough such\nthat the advertisement is visible by any phone at least 1 meter away.\n\nTo determine proximity, the Fast Pair Seeker must know the Fast Pair Provider's\ntransmit power. For the purposes of this profile, TxPower is defined as the\nreceived signal strength at source (0 meters), measured in dBm (this is the same\nway that\n[Eddystone](https://github.com/google/eddystone/tree/master/eddystone-uid#tx-power)\ndefines it).\n| **Note:** The best way to determine the value is to measure the actual output of the device using an Android phone at 1 meter away, and then add 41 dBm to that. 41 dBm is the average signal strength loss that occurs over 1 meter.\n\nThis measured value shall be transmitted using one of these methods:\n\n**Included in the Advertisement Record**\n: The device includes the *Tx Power Level* data type, **ibid.**, § 1.5, in its\n advertisement.\n\n**Provided during model registration**\n: The manufacturer provides Google with the transmit power, and the device model\n used to measure it, during Model Registration.\n: The device must keep its transmit power constant for all broadcasts when\n using this option so that distance measurements are accurate.\n\n### Keys: Anti-Spoofing Public/Private Key Pair\n\nAfter model registration, along with the Model ID, Google will distribute a\n256-bit Anti-Spoofing Private Key (an integer in \\[1,n--1\\] on the secp256r1\nelliptic curve). This key shall be persisted on the Provider device, and ideally\nstored inside a Secure Element (*SE*). Note that a Secure Element is strongly\nrecommended---in the absence of one, there is no guarantee that attackers could\nnot spoof the provider role, because the private key could leak. This key\nleaking opens up the possibility of man in the middle attacks; therefore, if\nimpersonation or abuse is detected, Fast Pair features that use this key may be\ndisabled (for example, the \"Tap to pair\" notification when the Provider is in\npairing mode).\n\nThe corresponding Anti-Spoofing Public Key is not currently used by the\nProvider. It is used by the Seeker, to encrypt a message to send to the Provider\n(see [Key-based Pairing](/nearby/fast-pair/specifications/characteristics#KeyBasedPairing \"Key Based Pairing\")).\n\n### Keys: Account Key List\n\nThe Provider shall allocate space to store a persisted list of 128-bit Account\nKeys. Each Account Key allows the Provider to be recognized as belonging to a\ncertain user account.\n\nThe list must be able to store at least five keys (that is, there must be at\nleast 80 bytes of space dedicated to this list). Providers can optionally store\nmore than this, they just must make sure that the keys will fit inside of their\nadvertising packet. The exact number that can be stored will depend on how many\nfree bytes are available in the advertising packet; see the [Account Key\nFilter](/nearby/fast-pair/specifications/service/provider#AccountKeyFilter \"Account Key Filter\") section for more information on determining how many\nbytes each key will take up. For example, to advertise 10 account keys, 15 bytes\nneed to be available in the packet.But for personal devices (e.g. headphones),\nthe number of account keys should not be greater than 5. This is to avoid the\nnumber of account keys becoming too large, and hence it could be unique and\ntrackable.\n\nThis list is initially empty, and must be cleared if the Provider is\nfactory-reset (if the user clears its paired device list). The list is populated\nas described in the [Account Key characteristic](/nearby/fast-pair/specifications/characteristics#AccountKey \"Account Key\") section.\n\n### BLE address information\n\nTo prevent tracking, BLE advertising shall use the random resolvable private\naddress (*RPA*). The address shall be rotated at minimum every 15 minutes while\nthe device is actively advertising, and every time the state changes from not\nadvertising to advertising. A randomized offset should be used to alter the\naddress randomization interval.\n\n### Attribute Protocol (ATT) MTU Size Negotiation\n\nAn ATT maximum transmission unit (MTU) value of 83 should be used whenever\npossible, but the default value of 23 is allowed."]]
