Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Ghi khoá tài khoản theo cách hồi tố
Nếu Người tìm kiếm thực hiện ghép nối theo cách truyền thống (ví dụ: thông qua phần cài đặt Bluetooth) thay vì thông qua điểm truy cập Ghép nối nhanh, thì sẽ không có khoá tài khoản nào được ghi vào Nhà cung cấp. Trong trường hợp này, người dùng sẽ không thể thấy hoặc sử dụng bất kỳ tính năng nào của Ghép nối nhanh, mặc dù sở hữu một thiết bị có tính năng Ghép nối nhanh. Để người dùng có thể hưởng lợi từ tính năng Ghép nối nhanh, Nhà cung cấp sẽ cho phép Thiết bị tìm kiếm tự động ghi khoá tài khoản ngay sau khi quá trình ghép nối diễn ra.
- Nếu Nhà cung cấp được liên kết mà không thông qua quy trình Ghép nối nhanh, hãy cho phép ghi khoá tài khoản mới thông qua phương thức Ghép nối dựa trên khoá trong tối đa một phút. Chỉ chấp nhận một khoá tài khoản được ghi trong thời gian này.
- Sau khi thiết lập kênh RFCOMM, Nhà cung cấp sẽ gửi Mã nhận dạng mô hình và địa chỉ BLE cho Người tìm kiếm thông qua Luồng thông báo, Người tìm kiếm sẽ thiết lập kết nối GATT và bắt đầu quy trình Ghép nối dựa trên khoá.
- Nếu nhận được một Raw Request có Flags bit 3 được đặt, thì Nhà cung cấp phải xác minh địa chỉ BR/EDR của thiết bị được liên kết có giống với địa chỉ trong yêu cầu hay không. Nếu không, hãy từ chối yêu cầu.
- Vì các thiết bị đã được liên kết, nên quá trình liên kết BR/EDR và xác minh bằng khoá truy cập (các bước 8 – 17 trong quy trình) sẽ bị bỏ qua và Seeker sẽ trực tiếp ghi khoá tài khoản vào Provider sau khi thiết lập một khoá bí mật dùng chung.
Trừ phi có lưu ý khác, nội dung của trang này được cấp phép theo Giấy phép ghi nhận tác giả 4.0 của Creative Commons và các mẫu mã lập trình được cấp phép theo Giấy phép Apache 2.0. Để biết thông tin chi tiết, vui lòng tham khảo Chính sách trang web của Google Developers. Java là nhãn hiệu đã đăng ký của Oracle và/hoặc các đơn vị liên kết với Oracle.
Cập nhật lần gần đây nhất: 2025-08-13 UTC.
[null,null,["Cập nhật lần gần đây nhất: 2025-08-13 UTC."],[[["\u003cp\u003eIf a Fast Pair device is paired traditionally (e.g., via Bluetooth settings), it won't have Fast Pair features until an account key is written.\u003c/p\u003e\n"],["\u003cp\u003eProviders should allow Seekers to write an account key for up to a minute after traditional pairing using Key-based Pairing.\u003c/p\u003e\n"],["\u003cp\u003eThis process involves the Provider sending its Model ID and BLE address, the Seeker establishing a GATT connection, and initiating Key-based Pairing.\u003c/p\u003e\n"],["\u003cp\u003eFor security, the Provider verifies the bonded device's address before accepting the account key write request.\u003c/p\u003e\n"],["\u003cp\u003eSince devices are already bonded, the process skips some steps and the Seeker directly writes the account key after a shared secret is established.\u003c/p\u003e\n"]]],[],null,["Retroactively Writing Account Key\n---------------------------------\n\nIf a Seeker performs a pairing through the traditional way (for example, through\nBluetooth settings) instead of through the Fast Pair entrypoint, there will be\nno account key written into the Provider. In this case, the user will not be\nable to see or use any of the Fast Pair features, despite owning a Fast Pair\ndevice. To let users be able to get the benefits of Fast Pair, the Provider\nshall allow the Seeker silently writing account key right after pairing has\noccurred.\n\n1. If the Provider is bonded without going through the Fast Pair flow, allow a new account key to be written through the Key-based Pairing method for up to one minute. Only accept one account key to be written during this time.\n2. After the RFCOMM channel is established, the Provider should send the Model ID and BLE address to the Seeker via [Message Stream](/nearby/fast-pair/specifications/extensions/messagestream#MessageStream \"Message Stream\"), the Seeker will build GATT connection and start [Key-based Pairing procedure](/nearby/fast-pair/specifications/service/gatt#procedure \"GATT Procedure\").\n3. If an [Raw Request](/nearby/fast-pair/specifications/characteristics#table1.2.1 \"Table 1.2.1 Raw Request\") with Flags bit 3 set is received, the Provider should verify the bonded device's BR/EDR address is the same as what is included in the request. If not, reject the request.\n4. Because the devices are already bonded, BR/EDR bonding and Passkey verification (steps 8 - 17 in the [procedure](/nearby/fast-pair/specifications/service/gatt#procedure \"GATT Procedure\")) will be skipped and the Seeker will directly write an [account key](/nearby/fast-pair/specifications/characteristics#AccountKey \"Account Key\") to the Provider after a shared secret is established."]]
