بلوتوث کم انرژی
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
Android پشتیبانی پلت فرم داخلی برای بلوتوث کم انرژی (BLE) را در نقش مرکزی ارائه می دهد و API هایی را ارائه می دهد که برنامه ها می توانند از آنها برای کشف دستگاه ها، جستجو برای خدمات و انتقال اطلاعات استفاده کنند.
موارد استفاده رایج شامل موارد زیر است:
- انتقال مقادیر کمی از داده ها بین دستگاه های نزدیک.
- تعامل با حسگرهای مجاورت برای ارائه تجربه شخصی سازی شده بر اساس مکان فعلی کاربران.
برخلاف بلوتوث کلاسیک ، BLE برای مصرف انرژی کمتر طراحی شده است. این به برنامهها اجازه میدهد تا با دستگاههای BLE که الزامات انرژی سختتری دارند، مانند سنسورهای مجاورت، مانیتورهای ضربان قلب و دستگاههای تناسب اندام، ارتباط برقرار کنند.
احتیاط: وقتی کاربر با استفاده از BLE دستگاه خود را با دستگاه دیگری جفت میکند، دادههایی که بین دو دستگاه ارسال میشود برای همه برنامههای دستگاه کاربر قابل دسترسی است.
به همین دلیل، اگر برنامه شما داده های حساسی را ضبط می کند، باید امنیت لایه برنامه را برای محافظت از حریم خصوصی آن داده ها پیاده سازی کنید.
اصول اولیه
برای اینکه دستگاه های دارای BLE بتوانند داده ها را بین یکدیگر انتقال دهند، ابتدا باید یک کانال ارتباطی تشکیل دهند. استفاده از APIهای Bluetooth LE مستلزم آن است که چندین مجوز را در فایل مانیفست خود اعلام کنید . هنگامی که برنامه شما مجوز استفاده از بلوتوث را دریافت کرد، برنامه شما باید به BluetoothAdapter
دسترسی داشته باشد و تعیین کند که آیا بلوتوث در دستگاه موجود است یا خیر . هنگامی که دستگاهی پیدا شد، قابلیت های دستگاه BLE با اتصال به سرور GATT در دستگاه BLE کشف می شود. پس از برقراری اتصال، داده ها را می توان با دستگاه متصل بر اساس خدمات و ویژگی های موجود منتقل کرد .
اصطلاحات و مفاهیم کلیدی
در زیر خلاصه ای از اصطلاحات و مفاهیم کلیدی BLE آمده است:
- نمایه ویژگی عمومی (GATT)
- نمایه GATT یک مشخصات کلی برای ارسال و دریافت قطعات کوتاه داده است که به عنوان "ویژگی ها" از طریق پیوند BLE شناخته می شوند. همه پروفایل های برنامه فعلی BLE بر اساس GATT هستند. برای کسب اطلاعات بیشتر، نمونه Android BluetoothLeGatt را در GitHub مرور کنید.
- پروفایل ها
- بلوتوث SIG پروفایل های زیادی را برای دستگاه های BLE تعریف می کند. نمایه مشخصاتی برای نحوه عملکرد یک دستگاه در یک برنامه خاص است. توجه داشته باشید که یک دستگاه می تواند بیش از یک نمایه را پیاده سازی کند. به عنوان مثال، یک دستگاه می تواند دارای یک مانیتور ضربان قلب و یک آشکارساز سطح باتری باشد.
- پروتکل ویژگی (ATT)
- گات بر روی پروتکل ویژگی (ATT) ساخته شده است. به این GATT/ATT نیز گفته می شود. ATT برای اجرا در دستگاه های BLE بهینه شده است. برای این منظور، تا حد امکان از بایت های کمتری استفاده می کند. هر ویژگی به طور منحصر به فرد توسط یک شناسه منحصر به فرد جهانی (UUID) شناسایی می شود، که یک فرمت 128 بیتی استاندارد شده برای شناسه رشته ای است که برای شناسایی منحصر به فرد اطلاعات استفاده می شود. ویژگی های منتقل شده توسط ATT به عنوان ویژگی ها و خدمات قالب بندی می شوند.
- مشخصه
- یک مشخصه حاوی یک مقدار واحد و توصیفگرهای 0-n است که مقدار مشخصه را توصیف می کند. یک مشخصه را می توان به عنوان یک نوع، مشابه با یک کلاس در نظر گرفت.
- توصیفگر
- توصیفگرها ویژگی های تعریف شده ای هستند که یک مقدار مشخصه را توصیف می کنند. برای مثال، یک توصیفگر ممکن است یک توصیف قابل خواندن برای انسان، یک محدوده قابل قبول برای مقدار یک مشخصه، یا یک واحد اندازه گیری که مختص مقدار یک مشخصه است را مشخص کند.
- خدمات
- یک سرویس مجموعه ای از ویژگی ها است. به عنوان مثال، میتوانید سرویسی به نام «نمایشگر ضربان قلب» داشته باشید که شامل ویژگیهایی مانند «اندازهگیری ضربان قلب» است. میتوانید فهرستی از پروفایلها و خدمات مبتنی بر گات را در bluetooth.org پیدا کنید.
نقش ها و مسئولیت ها
هنگامی که یک دستگاه با یک دستگاه BLE در تعامل است، نقش ها و مسئولیت ها به دو روش مختلف تقسیم می شوند:
مرکزی در مقابل محیطی این امر در مورد خود اتصال BLE صدق می کند - دستگاه در نقش مرکزی اسکن می کند، به دنبال تبلیغات است، و دستگاه در نقش محیطی تبلیغ می کند. دو دستگاهی که فقط نقش جانبی را پشتیبانی می کنند نمی توانند با یکدیگر صحبت کنند و همچنین دو دستگاهی که فقط نقش مرکزی را پشتیبانی می کنند.
سرور گات در مقابل کلاینت گات. این تعیین می کند که چگونه دو دستگاه پس از برقراری ارتباط با یکدیگر صحبت کنند. دستگاهی که در نقش کلاینت قرار دارد درخواست هایی برای داده ارسال می کند و دستگاه در نقش سرور آنها را برآورده می کند.
برای درک تمایز بین بخشهای نقش مرکزی-پیرامونی و سرور-کلاینت، مثالی را در نظر بگیرید که در آن یک تلفن Android و یک ردیاب فعالیت با قابلیت BLE دارید که دادههای حسگر را به تلفن گزارش میدهد.
تلفن - دستگاه مرکزی - به طور فعال دستگاه های BLE را اسکن می کند. ردیاب فعالیت - دستگاه جانبی - تبلیغ می کند و منتظر دریافت درخواست اتصال است.
پس از برقراری ارتباط تلفن و ردیاب فعالیت، آنها شروع به انتقال ابرداده های GATT به یکدیگر می کنند. در این حالت، برنامه در حال اجرا بر روی تلفن درخواستهایی برای داده ارسال میکند، بنابراین به عنوان مشتری گات عمل میکند. ردیاب فعالیت آن درخواست ها را برآورده می کند، بنابراین به عنوان سرور GATT عمل می کند.
یک طراحی جایگزین برنامه ممکن است شامل این باشد که تلفن به جای آن نقش سرور گات را بازی کند. برای اطلاعات بیشتر به BluetoothGattServer
مراجعه کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]