บลูทูธพลังงานต่ำ
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
Android รองรับแพลตฟอร์มในตัวสำหรับบลูทูธพลังงานต่ำ (BLE) ในบทบาทหลักและมี API ที่แอปสามารถใช้เพื่อค้นหาอุปกรณ์ ค้นหาบริการ และส่งข้อมูล
Use Case ที่พบบ่อยมีดังนี้
- การโอนข้อมูลจำนวนเล็กน้อยระหว่างอุปกรณ์ที่อยู่ใกล้เคียง
- การโต้ตอบกับเซ็นเซอร์ตรวจหาบุคคลในบริเวณใกล้เคียงเพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ปรับแต่งตามตำแหน่งปัจจุบัน
BLE ได้รับการออกแบบให้ใช้พลังงานน้อยลงอย่างมากเมื่อเทียบกับบลูทูธคลาสสิก ซึ่งจะช่วยให้แอปสื่อสารกับอุปกรณ์ BLE ที่มีข้อกำหนดด้านพลังงานที่เข้มงวดมากขึ้นได้ เช่น เซ็นเซอร์ตรวจหาบุคคลในบริเวณใกล้เคียง เครื่องวัดอัตราการเต้นของหัวใจ และอุปกรณ์ออกกำลังกาย
ข้อควรระวัง: เมื่อผู้ใช้จับคู่อุปกรณ์กับอุปกรณ์อื่นโดยใช้ BLE แอปทั้งหมดในอุปกรณ์ของผู้ใช้จะเข้าถึงข้อมูลที่สื่อสารระหว่างอุปกรณ์ 2 เครื่องได้
ดังนั้น หากแอปของคุณเก็บข้อมูลที่ละเอียดอ่อน คุณควรใช้การรักษาความปลอดภัยระดับแอปเพื่อปกป้องความเป็นส่วนตัวของข้อมูลดังกล่าว
ข้อมูลเบื้องต้น
อุปกรณ์ที่เปิดใช้ BLE จะต้องสร้างช่องทางการสื่อสารก่อนจึงจะส่งข้อมูลระหว่างกันได้ การใช้ Bluetooth LE API กำหนดให้คุณต้องประกาศสิทธิ์หลายรายการในไฟล์ Manifest เมื่อแอปมีสิทธิ์ใช้บลูทูธแล้ว แอปจะต้องเข้าถึง BluetoothAdapter
และตรวจสอบว่าอุปกรณ์มีบลูทูธหรือไม่ หากมี อุปกรณ์จะสแกนหาอุปกรณ์ BLE ที่อยู่ใกล้เคียง
เมื่อพบอุปกรณ์แล้ว ระบบจะค้นหาความสามารถของอุปกรณ์ BLE โดยเชื่อมต่อกับเซิร์ฟเวอร์ GATT ในอุปกรณ์ BLE
เมื่อเชื่อมต่อแล้ว คุณจะโอนข้อมูลด้วยอุปกรณ์ที่เชื่อมต่อได้ โดยขึ้นอยู่กับบริการและลักษณะการทำงานที่มี
คำสำคัญและแนวคิด
ต่อไปนี้เป็นข้อมูลสรุปเกี่ยวกับคําศัพท์และแนวคิดสําคัญของ BLE
- โปรไฟล์แอตทริบิวต์ทั่วไป (GATT)
- โปรไฟล์ GATT เป็นข้อกำหนดทั่วไปสำหรับการส่งและรับข้อมูลสั้นๆ ที่เรียกว่า "แอตทริบิวต์" ผ่านลิงก์ BLE โปรไฟล์แอปพลิเคชัน BLE ปัจจุบันทั้งหมดอิงตาม GATT ดูข้อมูลเพิ่มเติมจากตัวอย่าง BluetoothLeGatt ของ Android บน GitHub
- โปรไฟล์
- Bluetooth SIG กำหนดโปรไฟล์มากมายสำหรับอุปกรณ์ BLE โปรไฟล์คือข้อกำหนดสำหรับวิธีการทำงานของอุปกรณ์ในแอปพลิเคชันหนึ่งๆ โปรดทราบว่าอุปกรณ์หนึ่งๆ สามารถใช้โปรไฟล์ได้มากกว่า 1 โปรไฟล์ เช่น อุปกรณ์อาจมีเครื่องวัดอัตราการเต้นของหัวใจและเครื่องตรวจระดับแบตเตอรี่
- Attribute Protocol (ATT)
- GATT สร้างขึ้นจากโปรโตคอลแอตทริบิวต์ (ATT) หรือที่เรียกว่า GATT/ATT ATT ได้รับการเพิ่มประสิทธิภาพให้ทำงานบนอุปกรณ์ BLE ได้ ด้วยเหตุนี้ จึงใช้ไบต์ให้น้อยที่สุด แอตทริบิวต์แต่ละรายการจะระบุด้วยตัวระบุที่ไม่ซ้ำกันแบบสากล (UUID) ซึ่งเป็นรูปแบบ 128 บิตมาตรฐานสำหรับรหัสสตริงที่ใช้ระบุข้อมูลโดยไม่ซ้ำกัน แอตทริบิวต์ที่ ATT ขนส่งจะจัดรูปแบบเป็นลักษณะและบริการ
- ลักษณะเฉพาะ
- ลักษณะประกอบด้วยค่าเดี่ยวและตัวระบุ 0-n ที่อธิบายค่าของลักษณะ คุณอาจคิดว่าลักษณะเป็นประเภทที่คล้ายกับคลาส
- ตัวระบุ
- ข้อบ่งชี้คือแอตทริบิวต์ที่กําหนดซึ่งอธิบายค่าลักษณะ ตัวอย่างเช่น ข้อบ่งชี้อาจระบุคำอธิบายที่มนุษย์อ่านได้ ช่วงค่าที่ยอมรับได้สำหรับค่าของลักษณะ หรือหน่วยวัดเฉพาะสำหรับค่าของลักษณะ
- บริการ
- บริการคือคอลเล็กชันลักษณะ เช่น คุณอาจมีบริการชื่อ "เครื่องวัดอัตราการเต้นของหัวใจ" ที่มีลักษณะ เช่น "การวัดอัตราการเต้นของหัวใจ" คุณสามารถดูรายการโปรไฟล์และบริการที่ใช้ GATT ที่มีอยู่ได้ใน bluetooth.org
บทบาทและความรับผิดชอบ
เมื่ออุปกรณ์โต้ตอบกับอุปกรณ์ BLE บทบาทและความรับผิดชอบจะแบ่งออกเป็น 2 วิธีดังนี้
ส่วนกลางกับอุปกรณ์ต่อพ่วง ซึ่งวิธีนี้ใช้กับการเชื่อมต่อ BLE เอง นั่นคืออุปกรณ์ในการสแกน มองหาโฆษณา และอุปกรณ์ในบทบาทอุปกรณ์ต่อพ่วงโฆษณา อุปกรณ์ 2 เครื่องที่รองรับบทบาทอุปกรณ์ต่อพ่วงเท่านั้นจะสื่อสารกันไม่ได้ และอุปกรณ์ 2 เครื่องที่รองรับบทบาทส่วนกลางเท่านั้นก็จะสื่อสารกันไม่ได้เช่นกัน
เซิร์ฟเวอร์ GATT กับไคลเอ็นต์ GATT ซึ่งจะกำหนดวิธีที่อุปกรณ์ 2 เครื่องสื่อสารกันหลังจากที่สร้างการเชื่อมต่อแล้ว อุปกรณ์ในบทบาทไคลเอ็นต์จะส่งคำขอข้อมูล และอุปกรณ์ในบทบาทเซิร์ฟเวอร์จะดำเนินการตามคำขอ
หากต้องการทำความเข้าใจความแตกต่างระหว่างส่วนบทบาทอุปกรณ์ต่อพ่วงส่วนกลางกับเซิร์ฟเวอร์-ไคลเอ็นต์ ให้ลองดูตัวอย่างพื้นที่ที่คุณมีโทรศัพท์ Android และเครื่องมือติดตามกิจกรรมที่เปิดใช้ BLE ซึ่งรายงานข้อมูลเซ็นเซอร์กลับไปยังโทรศัพท์
โทรศัพท์ซึ่งเป็นอุปกรณ์ส่วนกลางจะสแกนหาอุปกรณ์ BLE อย่างต่อเนื่อง เครื่องมือติดตามกิจกรรมซึ่งเป็นอุปกรณ์ต่อพ่วงจะโฆษณาและรอรับคำขอเชื่อมต่อ
หลังจากโทรศัพท์และอุปกรณ์ติดตามกิจกรรมสร้างการเชื่อมต่อแล้ว อุปกรณ์จะเริ่มโอนข้อมูลเมตา GATT ให้แก่กัน ในกรณีนี้ แอปที่ทำงานในโทรศัพท์จะส่งคำขอข้อมูล จึงทำหน้าที่เป็นไคลเอ็นต์ GATT อุปกรณ์ติดตามกิจกรรมจะตอบสนองต่อคําขอเหล่านั้น จึงทําหน้าที่เป็นเซิร์ฟเวอร์ GATT
การออกแบบแอปอีกแบบหนึ่งอาจเกี่ยวข้องกับการที่โทรศัพท์ทำหน้าที่เป็นเซิร์ฟเวอร์ GATT แทน ดูข้อมูลเพิ่มเติมที่ BluetoothGattServer
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 UTC
[[["เข้าใจง่าย","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-07-27 UTC"],[],[],null,["# Bluetooth Low Energy\n\nAndroid provides built-in platform support for Bluetooth Low Energy (BLE) in the\ncentral role and provides APIs that apps can use to discover devices, query for\nservices, and transmit information.\n\nCommon use cases include the following:\n\n- Transferring small amounts of data between nearby devices.\n- Interacting with proximity sensors to give users a customized experience based on their current location.\n\nIn contrast to [classic Bluetooth](/develop/connectivity/bluetooth),\nBLE is designed for significantly lower power consumption. This allows apps to\ncommunicate with BLE devices that have stricter power requirements, such as\nproximity sensors, heart rate monitors, and fitness devices. \n\n**Caution:** When a user pairs their device with another device\nusing BLE, the data that's communicated between the two devices is\naccessible to **all** apps on the user's device.\n\n\nFor this reason, if your app captures sensitive data, you should implement\napp-layer security to protect the privacy of that data.\n\nThe basics\n----------\n\nFor BLE-enabled devices to transmit data between each other, they must first\nform a channel of communication. Use of the Bluetooth LE APIs requires you to\n[declare several permissions](/develop/connectivity/bluetooth/bt-permissions)\nin your manifest file. Once your app has permission to use Bluetooth, your app\nneeds to access the `BluetoothAdapter` and\n[determine if Bluetooth is available on the device](/develop/connectivity/bluetooth/setup)\nIf Bluetooth is available, the device will\n[scan for nearby BLE devices](/develop/connectivity/bluetooth/ble/find-ble-devices).\nOnce a device is found, the capabilities of the BLE device are discovered by\n[connecting to the GATT server on the BLE device](/develop/connectivity/bluetooth/ble/connect-gatt-server).\nOnce a connection is made,\n[data can be transferred with the connected device](/develop/connectivity/bluetooth/ble/transfer-ble-data)\nbased on the available services and characteristics.\n\nKey terms and concepts\n----------------------\n\nThe following is a summary of key BLE terms and concepts:\n\n-\n\n **Generic Attribute Profile (GATT)**\n : The GATT profile is a general specification for sending and receiving short\n pieces of data known as \"attributes\" over a BLE link. All current BLE\n application profiles are based on GATT. Review the [Android BluetoothLeGatt\n sample](https://github.com/android/platform-samples/tree/main/samples/connectivity/bluetooth/ble/src/main/java/com/example/platform/connectivity/bluetooth/ble)\n on GitHub to learn more.\n-\n\n **Profiles**\n : The **Bluetooth SIG** defines many\n [profiles](https://www.bluetooth.org/en-us/specification/adopted-specifications)\n for BLE devices. A profile is a specification for how a device works in a\n particular application. Note that a device can implement more than one\n profile. For example, a device could contain a heart rate monitor and a\n battery level detector.\n-\n\n **Attribute Protocol (ATT)**\n : GATT is built on top of the Attribute Protocol (ATT). This is also referred to\n as GATT/ATT. ATT is optimized to run on BLE devices. To this end, it uses as\n few bytes as possible. Each attribute is uniquely identified by a Universally\n Unique Identifier (UUID), which is a standardized 128-bit format for a string\n ID used to uniquely identify information. The *attributes* transported by ATT\n are formatted as *characteristics* and *services*.\n-\n\n **Characteristic**\n : A characteristic contains a single value and 0-n descriptors that describe the\n characteristic's value. A characteristic can be thought of as a type,\n analogous to a class.\n-\n\n **Descriptor**\n : Descriptors are defined attributes that describe a characteristic value. For\n example, a descriptor might specify a human-readable description, an\n acceptable range for a characteristic's value, or a unit of measure that is\n specific to a characteristic's value.\n-\n\n **Service**\n : A service is a collection of characteristics. For example, you could have a\n service called \"Heart Rate Monitor\" that includes characteristics such as\n \"heart rate measurement.\" You can find a list of existing GATT-based profiles\n and services on [bluetooth.org](https://www.bluetooth.org/en-us/specification/adopted-specifications).\n\n### Roles and responsibilities\n\nWhen a device interacts with a BLE device, roles and responsibilities are\ndivided in two different ways:\n\n- **Central versus peripheral.** This applies to the BLE connection itself---the\n device in the central role scans, looking for advertisement, and the device in\n the peripheral role advertises. Two devices that only support the peripheral\n role can't talk to each other, and neither can two devices that only support\n the central role.\n\n- **GATT server versus GATT client.** This determines how the two devices talk\n to each other after they've established the connection. The device in the\n client role sends requests for data, and the device in the server role\n fulfills them.\n\nTo understand the distinction between the central-peripheral and server-client\nrole divisions, consider an example where you have an Android phone and a\nBLE-enabled activity tracker that reports sensor data back to the phone.\n\n- The phone---the *central* device---actively scans for BLE devices. The activity\n tracker---the *peripheral* device---advertises and waits to receive a request for\n connection.\n\n- After the phone and the activity tracker have established a connection, they\n start transferring GATT metadata to each other. In this case, the app running\n on the phone sends requests for data, so it acts as the *GATT client* . The\n activity tracker fulfills those requests, so it acts as the *GATT server*.\n\nAn alternative design of the app might involve the phone playing the GATT server\nrole instead. See\n[`BluetoothGattServer`](/reference/android/bluetooth/BluetoothGattServer) for\nmore information."]]