Bluetooth à basse consommation
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Android offre une compatibilité intégrée avec la plate-forme Bluetooth à basse consommation (BLE) dans le rôle central et fournit des API que les applications peuvent utiliser pour détecter des appareils, rechercher des services et transmettre des informations.
Voici quelques cas d'utilisation courants:
- Transfert de petites quantités de données entre des appareils à proximité.
- Interagir avec les capteurs de proximité pour offrir aux utilisateurs une expérience personnalisée en fonction de leur position actuelle
Contrairement au Bluetooth classique, la technologie BLE est conçue pour consommer beaucoup d'énergie. Cela permet aux applications de communiquer avec les appareils BLE qui ont des besoins d'alimentation plus stricts, tels que les capteurs de proximité, les moniteurs de fréquence cardiaque et les appareils de fitness.
Attention:Lorsqu'un utilisateur associe son appareil à un autre appareil à l'aide de la technologie BLE, les données communiquées entre les deux appareils sont accessibles à toutes les applications de l'appareil de l'utilisateur.
C'est pourquoi, si votre application collecte des données sensibles, vous devez implémenter une sécurité au niveau de la couche application pour protéger la confidentialité de ces données.
Principes de base
Pour que les appareils compatibles avec le BLE puissent transmettre des données entre eux, ils doivent d'abord former un canal de communication. L'utilisation des API Bluetooth LE nécessite de déclarer plusieurs autorisations dans votre fichier manifeste. Une fois que votre application est autorisée à utiliser le Bluetooth, elle doit accéder à BluetoothAdapter et déterminer si le Bluetooth est disponible sur l'appareil. Si le Bluetooth est disponible, l'appareil recherche les appareils BLE à proximité.
Une fois un appareil détecté, les fonctionnalités de l'appareil BLE sont découvertes en se connectant au serveur GATT de l'appareil BLE.
Une fois la connexion établie, les données peuvent être transférées avec l'appareil connecté en fonction des services et des caractéristiques disponibles.
Termes et concepts clés
Vous trouverez ci-dessous un récapitulatif des principaux termes et concepts BLE:
- Profil d'attribut générique (GATT)
- Le profil GATT est une spécification générale permettant d'envoyer et de recevoir de courtes données appelées "attributs" via un lien BLE. Tous les profils d'application BLE actuels sont basés sur GATT. Pour en savoir plus, consultez l'exemple Android BluetoothLeGatt sur GitHub.
- Profils
- Le Bluetooth SIG définit de nombreux profils pour les appareils BLE. Un profil est une spécification du fonctionnement d'un appareil dans une application donnée. Notez qu'un appareil peut implémenter plusieurs profils. Par exemple, un appareil peut contenir un cardiofréquencemètre et un détecteur de niveau de batterie.
- Attribute Protocol (ATT)
- GATT repose sur le protocole d'attributs (ATT). Ce protocole est également appelé GATT/ATT. La fonctionnalité ATT est optimisée pour fonctionner sur les appareils BLE. À cette fin, elle utilise le moins
d'octets possible. Chaque attribut est identifié de manière unique par un identifiant universel unique (UUID), qui est un format standardisé de 128 bits pour un ID de chaîne utilisé pour identifier de manière unique des informations. Les attributs transportés par ATT sont au format caractéristiques et services.
- Caractéristique
- Une caractéristique contient une seule valeur et 0 à n descripteurs qui décrivent la valeur de la caractéristique. Une caractéristique peut être considérée comme un type, semblable à une classe.
- Décriteur
- Les descripteurs sont des attributs définis qui décrivent une valeur caractéristique. Par exemple, un descripteur peut spécifier une description lisible par l'utilisateur, une plage acceptable pour la valeur d'une caractéristique ou une unité de mesure spécifique à la valeur d'une caractéristique.
- Service
- Un service est un ensemble de caractéristiques. Par exemple, vous pouvez avoir un service appelé "Cardiofréquencemètre" qui inclut des caractéristiques telles que "mesure de la fréquence cardiaque". Vous trouverez la liste des profils et services basés sur GATT sur bluetooth.org.
Rôles et responsabilités
Lorsqu'un appareil interagit avec un appareil BLE, les rôles et les responsabilités sont répartis de deux manières différentes:
Central et périphérique Cela s'applique à la connexion BLE elle-même : l'appareil dans le rôle central effectue une analyse à la recherche d'annonces, et l'appareil dans le rôle périphérique diffuse des annonces. Deux appareils qui ne prennent en charge que le rôle de périphérique ne peuvent pas communiquer entre eux, pas plus que deux appareils qui ne prennent en charge que le rôle de central.
Serveur GATT par rapport au client GATT Cela détermine la façon dont les deux appareils communiquent entre eux une fois la connexion établie. L'appareil dans le rôle de client envoie des requêtes de données, et l'appareil dans le rôle de serveur les traite.
Pour comprendre la distinction entre les rôles de central-périphérique et de serveur-client, prenons l'exemple d'un téléphone Android et d'un moniteur d'activité compatible avec la technologie BLE qui renvoie les données des capteurs au téléphone.
Le téléphone (l'appareil central) recherche activement les appareils BLE. Le traceur d'activité (l'périphérique) annonce et attend de recevoir une demande de connexion.
Une fois la connexion établie entre le téléphone et le suivi d'activité, ils commencent à se transférer les métadonnées GATT. Dans ce cas, l'application exécutée sur le téléphone envoie des requêtes de données. Elle agit donc en tant que client GATT. Le moniteur d'activité répond à ces requêtes et agit donc en tant que serveur GATT.
Une autre conception de l'application peut impliquer que le téléphone joue le rôle de serveur GATT à la place. Pour en savoir plus, consultez BluetoothGattServer.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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."]]
