Bluetooth Düşük Enerji
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Android, merkezi rolde Bluetooth Düşük Enerji (BDE) için yerleşik platform desteği sağlar ve uygulamaların cihazları keşfetmek, hizmet sorgulamak ve bilgi aktarmak için kullanabileceği API'ler sunar.
Yaygın kullanım alanları şunlardır:
- Yakındaki cihazlar arasında az miktarda veri aktarımı
- Kullanıcılara mevcut konumlarına göre özelleştirilmiş bir deneyim sunmak için yakınlık sensörleriyle etkileşimde bulunma.
Klasik Bluetooth'un aksine BDE, önemli ölçüde daha düşük güç tüketimi için tasarlanmıştır. Bu sayede uygulamalar, yakınlık sensörleri, nabız ölçerler ve fitness cihazları gibi daha katı güç gereksinimleri olan BLE cihazlarla iletişim kurabilir.
Dikkat: Kullanıcı, BLE'yi kullanarak cihazını başka bir cihazla eşlediğinde, iki cihaz arasında paylaşılan veriler kullanıcının cihazındaki tüm uygulamalar tarafından erişilebilir.
Bu nedenle, uygulamanız hassas verileri yakalarsa bu verilerin gizliliğini korumak için uygulama katmanı güvenliğini uygulamanız gerekir.
Temel bilgiler
BLE özellikli cihazların birbirleriyle veri aktarabilmesi için öncelikle bir iletişim kanalı oluşturmaları gerekir. Bluetooth LE API'lerinin kullanılması için manifest dosyanızda çeşitli izinleri beyan etmeniz gerekir. Uygulamanız Bluetooth kullanma iznine sahip olduktan sonra BluetoothAdapter erişmesi ve cihazda Bluetooth'un kullanılıp kullanılamadığını belirlemesi gerekir. Bluetooth kullanılabiliyorsa cihaz yakındaki BLE cihazları tarar.
Bir cihaz bulunduğunda BDE cihazındaki GATT sunucusuna bağlanarak BDE cihazının özellikleri keşfedilir.
Bağlantı kurulduktan sonra, mevcut hizmetlere ve özelliklere bağlı olarak veriler bağlı cihazla aktarılabilir.
Anahtar terimler ve kavramlar
Aşağıda, önemli BDE terimleri ve kavramlarının bir özeti verilmiştir:
- Genel Özellik Profili (GATT)
- GATT profili, BDE bağlantısı üzerinden "özellikler" olarak bilinen kısa veri parçalarını gönderip almaya yönelik genel bir spesifikasyondur. Mevcut tüm BLE uygulama profilleri, GATT'yi temel almaktadır. Daha fazla bilgi edinmek için GitHub'daki Android BluetoothLeGatt
örneğini inceleyin.
- Profiller
- Bluetooth SIG, BLE cihazlar için birçok profil tanımlar. Profil, bir cihazın belirli bir uygulamada nasıl çalıştığına dair bir özelliktir. Bir cihazın birden fazla profil uygulayabileceğini unutmayın. Örneğin, bir cihazda nabız monitörü ve pil seviyesi dedektörü bulunabilir.
- Özellik Protokolü (ATT)
- GATT, Özellik Protokolü (ATT) temel alınarak oluşturulmuştur. Buna GATT/ATT da denir. ATT, BDE cihazlarda çalışacak şekilde optimize edilmiştir. Bu doğrultuda, mümkün olduğunca
birkaç bayt kullanır. Her özellik, bilgileri benzersiz bir şekilde tanımlamak için kullanılan dize kimliği için standartlaştırılmış 128 bitlik bir biçim olan Evrensel Benzersiz Tanımlayıcı (UUID) ile benzersiz bir şekilde tanımlanır. ATT tarafından aktarılan özellikler özellikler ve hizmetler olarak biçimlendirilir.
- Özellik
- Bir özellik, tek bir değer ve özelliğin değerini açıklayan 0-n tanımlayıcıları içerir. Bir özellik, sınıfa benzer bir tür olarak düşünülebilir.
- Tanımlayıcı
- Tanımlayıcılar, bir karakteristik değeri tanımlayan tanımlanmış özelliklerdir. Örneğin bir tanımlayıcı, kullanıcılar tarafından okunabilen bir açıklama, bir özelliğin değeri için kabul edilebilir bir aralık veya bir özelliğin değerine özel bir ölçü birimini belirtebilir.
- Hizmet
- Hizmet, bir özellik koleksiyonudur. Örneğin, "nabız ölçümü" gibi özellikleri içeren "nabız monitörü" adlı bir hizmetiniz olabilir. Mevcut GATT tabanlı profillerin ve hizmetlerin listesini bluetooth.org adresinde bulabilirsiniz.
Roller ve sorumluluklar
Bir cihaz BLE cihazıyla etkileşime geçtiğinde roller ve sorumluluklar iki farklı şekilde bölünür:
Merkezi ve çevre birimi. Bu, BLE bağlantısı için geçerlidir. Merkezi roldeki cihaz, reklam arayışında taramalar yapar ve çevresel roldeki cihaz reklam yayınlar. Yalnızca çevre birimi rolünü destekleyen iki cihaz birbiriyle iletişim kuramaz. Yalnızca merkezi rolü destekleyen iki cihaz da iletişim kuramaz.
GATT sunucusu ve GATT istemcisi Bu, bağlantıyı kurduktan sonra iki cihazın
birbiriyle nasıl iletişim kurduğunu belirler. İstemci rolündeki cihaz, veri istekleri gönderir ve sunucu rolündeki cihaz bu istekleri yerine getirir.
Merkezi-çevre birimi ve sunucu-istemci rol bölümleri arasındaki farkı anlamak için bir Android telefonunuz ve sensör verilerini telefona bildiren BLE özellikli bir aktivite takip cihazınız olduğunu varsayalım.
Telefon (merkezi cihaz), BLE cihazlarını etkin olarak tarar. Etkinlik izleyici (çevre birimi cihazı) reklam yapar ve bağlantı isteği almayı bekler.
Telefon ve etkinlik izleyici bağlantı kurduktan sonra, GATT meta verilerini birbirine aktarmaya başlar. Bu durumda, telefonda çalışan uygulama veri istekleri gönderir ve bu nedenle GATT istemcisi olarak çalışır. Aktivite takip cihazı bu istekleri yerine getirdiği için GATT sunucusu olarak çalışır.
Uygulamanın alternatif bir tasarımında, telefon bunun yerine GATT sunucusu rolünü oynayabilir. Daha fazla bilgi için BluetoothGattServer bölümüne bakın.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[null,null,["Son güncelleme tarihi: 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."]]
