Bluetooth עם צריכת אנרגיה נמוכה (BLE)
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
Android מספקת תמיכה מובנית בפלטפורמה ל-Bluetooth עם צריכת אנרגיה נמוכה (BLE) בתפקיד המרכזי, ומספקת ממשקי API שבהם אפליקציות יכולות להשתמש כדי לזהות מכשירים, לבצע שאילתות לשירותים ולהעביר מידע.
תרחישים נפוצים לדוגמה:
- העברת כמויות קטנות של נתונים בין מכשירים קרובים.
- אינטראקציה עם חיישני קירבה כדי לספק למשתמשים חוויה מותאמת אישית על סמך המיקום הנוכחי שלהם.
בניגוד ל-Bluetooth קלאסי, BLE תוכנן לצריכת אנרגיה נמוכה משמעותית. כך האפליקציות יכולות לתקשר עם מכשירי BLE שיש להם דרישות צריכת אנרגיה מחמירות יותר, כמו חיישני קרבה, מכשירי ניטור קצב הלב ומכשירי כושר.
זהירות: כשמשתמש מתאים את המכשיר שלו למכשיר אחר באמצעות BLE, הנתונים שמועברים בין שני המכשירים נגישים לכל האפליקציות במכשיר של המשתמש.
לכן, אם האפליקציה מתעדת מידע אישי רגיש, צריך להטמיע אבטחה בשכבת האפליקציה כדי להגן על הפרטיות של המידע הזה.
העקרונות הבסיסיים
כדי שמכשירים עם תמיכה ב-BLE יוכלו להעביר נתונים ביניהם, הם צריכים קודם ליצור ערוץ תקשורת. כדי להשתמש בממשקי ה-API של Bluetooth LE, צריך להצהיר על כמה הרשאות בקובץ המניפסט. אחרי שהאפליקציה מקבלת הרשאה להשתמש ב-Bluetooth, היא צריכה לגשת ל-BluetoothAdapter ולקבוע אם ה-Bluetooth זמין במכשיר. אם ה-Bluetooth זמין, המכשיר יסורק אחר מכשירי BLE בקרבת מקום.
אחרי שמוצאים מכשיר, מאתרים את היכולות של מכשיר ה-BLE על ידי התחברות לשרת ה-GATT במכשיר ה-BLE.
אחרי שתתחברו, תוכלו להעביר נתונים באמצעות המכשיר המחובר בהתאם לשירותים ולמאפיינים הזמינים.
מונחים ומושגים מרכזיים
בטבלה הבאה ריכזנו את המונחים והמושגים העיקריים ב-BLE:
- פרופיל מאפיינים גנרי (GATT)
- פרופיל ה-GATT הוא מפרט כללי לשליחה ולקבלה של קטעי נתונים קצרים שנקראים 'מאפיינים' דרך קישור BLE. כל הפרופילים הנוכחיים של אפליקציות BLE מבוססים על GATT. למידע נוסף, אפשר לעיין בקוד לדוגמה של Android BluetoothLeGatt ב-GitHub.
- פרופילים
- ה-Bluetooth SIG מגדיר הרבה פרופילים למכשירי BLE. פרופיל הוא מפרט של אופן הפעולה של מכשיר באפליקציה מסוימת. חשוב לזכור שאפשר להטמיע במכשיר יותר מפרופיל אחד. לדוגמה, מכשיר יכול להכיל מוניטור דופק וגלאי של רמת הטעינה של הסוללה.
- Attribute Protocol (ATT)
- פרוטוקול GATT מבוסס על פרוטוקול המאפיינים (ATT). הפרוטוקול הזה נקרא גם GATT/ATT. מדיניות ATT עברה אופטימיזציה לפעול במכשירי BLE. לשם כך, הוא משתמש בכמה שפחות בייטים. לכל מאפיין יש מזהה ייחודי (UUID) – פורמט סטנדרטי של מחרוזת מזהה באורך 128 ביט, המשמש לזיהוי ייחודי של מידע. המאפיינים שמועברים על ידי ATT מפורטים בתור מאפיינים ושירותים.
- מאפיין
- מאפיין מכיל ערך יחיד ומספר תיאורים (0 עד n) שמתארים את הערך של המאפיין. אפשר לחשוב על מאפיין בתור טיפוס, בדומה לכיתה.
- תיאור
- תיאורים הם מאפיינים מוגדרים שמתארים ערך מאפיין. לדוגמה, מתאר יכול לציין תיאור שקריא לבני אדם, טווח מקובל לערך של מאפיין או יחידת מידה ספציפית לערך של מאפיין.
- שירות
- שירות הוא אוסף של מאפיינים. לדוגמה, יכול להיות לכם שירות שנקרא 'מכשיר למדידת דופק' שכולל מאפיינים כמו 'מדידת דופק'. בכתובת bluetooth.org תוכלו למצוא רשימה של פרופילים ושירותים קיימים מבוססי GATT.
תפקידים ותחומי אחריות
כשמכשיר מקיים אינטראקציה עם מכשיר BLE, התפקידים והאחריות מתחלקים בשתי דרכים שונות:
מרכזי לעומת היקפי. זה רלוונטי לחיבור BLE עצמו – המכשיר בתפקיד המרכזי סורק ומחפש מודעות, והמכשיר בתפקיד ההיקפי מפרסם. שני מכשירים שתומכים רק בתפקיד ההיקפי לא יכולים לתקשר ביניהם, וגם שני מכשירים שתומכים רק בתפקיד המרכזי לא יכולים לתקשר ביניהם.
שרת GATT לעומת לקוח GATT הוא קובע איך שני המכשירים יתקשרו זה עם זה אחרי שהחיבור יתבצע. המכשיר בתפקיד הלקוח שולח בקשות לנתונים, והמכשיר בתפקיד השרת ממלא אותן.
כדי להבין את ההבדל בין חלוקת התפקידים 'מרכזי-פריפריאלי' לבין 'שרת-לקוח', נבחן דוגמה שבה יש לכם טלפון Android ומכשיר למעקב אחר פעילות עם תמיכה ב-BLE שמדווח על נתוני החיישן חזרה לטלפון.
הטלפון, שהוא המכשיר המרכז, סורק באופן פעיל מכשירי BLE. מכשיר מעקב הפעילות – הציוד ההיקפי – מפרסם את עצמו וממתין לקבלת בקשה להתחברות.
אחרי שנוצר חיבור בין הטלפון לבין המעקב אחר הפעילות, הם מתחילים להעביר מטא-נתונים של GATT זה לזה. במקרה כזה, האפליקציה שפועלת בטלפון שולחת בקשות לנתונים, כך שהיא פועלת בתור לקוח GATT. מכשיר מעקב הפעילות ממלא את הבקשות האלה, ולכן הוא פועל בתור שרת GATT.
עיצוב חלופי של האפליקציה עשוי לכלול במקום זאת את התפקיד של שרת GATT בטלפון. מידע נוסף זמין במאמר BluetoothGattServer.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[null,null,["עדכון אחרון: 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."]]
