[[["容易理解","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."]]
