Bluetooth de bajo consumo
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Android proporciona compatibilidad de plataforma integrada para Bluetooth de bajo consumo (BLE) en el rol central y ofrece APIs que las apps pueden usar para descubrir dispositivos, consultar servicios y transmitir información.
Los siguientes son algunos de los casos de uso típicos:
- Transferir volúmenes de datos reducidos entre dispositivos cercanos
- Interactuar con sensores de proximidad para brindarles a los usuarios una experiencia personalizada en función de su ubicación actual
A diferencia del Bluetooth clásico, el BLE está diseñado para un consumo de energía significativamente menor. Esto permite que las apps se comuniquen con dispositivos BLE que tienen requisitos de consumo más estrictos, como sensores de proximidad, monitores de frecuencia cardíaca y dispositivos de fitness.
Precaución: Cuando un usuario vincula su dispositivo con otro mediante BLE, todas las apps del dispositivo del usuario pueden acceder a los datos que se transmiten entre los dispositivos.
Por esa razón, si tu app captura datos sensibles, debes implementar medidas de seguridad en el nivel de la app para proteger la confidencialidad de esos datos.
Conceptos básicos
Para que los dispositivos compatibles con BLE transmitan datos entre sí, primero deben formar un canal de comunicación. El uso de las APIs de Bluetooth LE requiere que declares varios permisos en tu archivo de manifiesto. Una vez que la app tenga permiso para usar Bluetooth, deberá acceder a BluetoothAdapter y determinar si Bluetooth está disponible en el dispositivo. Si Bluetooth está disponible, el dispositivo buscará dispositivos BLE cercanos.
Una vez que se encuentra un dispositivo, sus capacidades se descubren mediante la conexión al servidor GATT en el dispositivo BLE.
Una vez que se establece una conexión, se pueden transferir datos con el dispositivo conectado según los servicios y las características disponibles.
Términos y conceptos clave
El siguiente es un resumen de los términos y conceptos clave de BLE:
- Perfil de atributos genéricos (GATT)
- El perfil GATT es una especificación general para enviar y recibir fragmentos de datos cortos, conocidos como "atributos", a través de un vínculo BLE. Todos los perfiles de aplicaciones BLE actuales se basan en GATT. Revisa la muestra de BluetoothLeGatt de Android en GitHub para obtener más información.
- Perfiles
- Bluetooth SIG define muchos perfiles para dispositivos BLE. Un perfil es una especificación sobre el funcionamiento de un dispositivo en una aplicación en particular. Ten en cuenta que un dispositivo puede implementar más de un perfil. Por ejemplo, un dispositivo puede incluir un monitor de frecuencia cardíaca y un detector de nivel de batería.
- Protocolo de atributos (ATT)
- GATT se basa en el protocolo de atributos (ATT). Esto también se conoce como GATT/ATT. ATT está optimizado para funcionar en dispositivos BLE. Por esa razón, usa la menor cantidad de bytes posible. Cada atributo se identifica de forma exclusiva mediante un identificador único universal (UUID), que es un formato estandarizado de 128 bits para un ID de cadena que se usa para identificar información de manera exclusiva. Los atributos que transporta ATT tienen formato de características y servicios.
- Característica
- Una característica contiene un solo valor y 0 a n descriptores que describen el valor de la característica. Una característica se puede considerar como un tipo, análogo a una clase.
- Descriptor
- Los descriptores son atributos definidos que describen el valor de una característica. Por ejemplo, un descriptor puede especificar una descripción legible por humanos, un rango aceptable para el valor de una característica o una unidad de medida específica del valor de una característica.
- Servicio
- Un servicio es un conjunto de características. Por ejemplo, podrías tener un servicio denominado "Monitor de ritmo cardíaco" que incluya características como "medición del ritmo cardíaco". Puedes encontrar una lista de los perfiles y servicios basados en GATT en bluetooth.org.
Funciones y responsabilidades
Cuando un dispositivo interactúa con un dispositivo BLE, los roles y las responsabilidades se dividen de dos maneras diferentes:
Central y periférica. Esto se aplica a la conexión BLE en sí misma: el dispositivo con el rol central escanea en busca de publicidad y el dispositivo con el rol periférico realiza la publicidad. Dos dispositivos que solo admiten el rol periférico no pueden comunicarse entre sí, al igual que dos dispositivos que solo admiten el rol central.
Servidor GATT y cliente GATT. Esto determina cómo se comunican entre sí los dos dispositivos una vez establecida la conexión. El dispositivo en la función de cliente envía solicitudes de datos y el dispositivo en la función de servidor las cumple.
Para comprender la distinción entre las divisiones de funciones de periférico central y de servidor y cliente, considera un ejemplo en el que tienes un teléfono Android y un rastreador de actividad habilitado para BLE que informa los datos de sensores al teléfono.
El teléfono (el dispositivo central) busca de forma activa dispositivos BLE. El monitor de actividad (el dispositivo periférico) anuncia y espera recibir una solicitud de conexión.
Una vez que el teléfono y el dispositivo de seguimiento establecen una conexión, comienzan a transferirse metadatos GATT entre sí. En este caso, la app que se ejecuta en el teléfono envía solicitudes de datos, por lo que actúa como el cliente GATT. El monitor de actividad completa esas solicitudes, por lo que actúa como el servidor GATT.
Un diseño alternativo de la app podría implicar que el teléfono desempeñe el rol de servidor GATT. Consulta BluetoothGattServer para obtener más información.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]
