Bluetooth Low Energy
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Android offre il supporto integrato della piattaforma per Bluetooth Low Energy (BLE) nel ruolo centrale e fornisce API che le app possono utilizzare per rilevare dispositivi, richiedere servizi e trasmettere informazioni.
I casi d'uso comuni includono:
- Trasferimento di piccole quantità di dati tra dispositivi nelle vicinanze.
- Interazione con i sensori di prossimità per offrire agli utenti un'esperienza personalizzata in base alla loro posizione attuale.
A differenza del Bluetooth classico, il BLE è progettato per un consumo energetico notevolmente inferiore. In questo modo le app possono comunicare con dispositivi BLE che hanno requisiti di alimentazione più rigidi, come sensori di prossimità, cardiofrequenzimetri e dispositivi per il fitness.
Attenzione:quando un utente accoppia il proprio dispositivo a un altro dispositivo tramite BLE, i dati comunicati tra i due dispositivi sono accessibili a tutte le app sul dispositivo dell'utente.
Per questo motivo, se la tua app acquisisce dati sensibili, devi implementare la sicurezza a livello di app per proteggere la privacy di questi dati.
Nozioni di base
Affinché i dispositivi compatibili con BLE trasmettano dati tra loro, devono prima formare un canale di comunicazione. L'utilizzo delle API Bluetooth LE richiede di
dichiarare diverse autorizzazioni
nel file manifest. Una volta che l'app dispone dell'autorizzazione per utilizzare il Bluetooth, l'app deve accedere a BluetoothAdapter e
determinare se il Bluetooth è disponibile sul dispositivo
Se il Bluetooth è disponibile, il dispositivo
eseguirà una scansione per rilevare i dispositivi BLE nelle vicinanze.
Una volta trovato un dispositivo, le funzionalità del dispositivo BLE vengono rilevate connettendosi al server GATT sul dispositivo BLE.
Una volta stabilita la connessione,
i dati possono essere trasferiti con il dispositivo collegato
in base ai servizi e alle caratteristiche disponibili.
Termini e concetti chiave
Di seguito è riportato un riepilogo dei termini e dei concetti chiave di BLE:
- Profilo attributi generico (GATT)
- Il profilo GATT è una specifica generale per l'invio e la ricezione di brevi frammenti di dati noti come "attributi" tramite un link BLE. Tutti i profili di applicazione BLE attuali si basano su GATT. Per saperne di più, consulta l'esempio Android BluetoothLeGatt su GitHub.
- Profili
- Il Bluetooth SIG definisce molti
profili
per i dispositivi BLE. Un profilo è una specifica del funzionamento di un dispositivo in una determinata applicazione. Tieni presente che un dispositivo può implementare più di un profilo. Ad esempio, un dispositivo potrebbe contenere un cardiofrequenzimetro e un rilevatore del livello della batteria.
- Attribute Protocol (ATT)
- GATT è basato sul protocollo Attribute (ATT). Questo processo è noto anche
come GATT/ATT. ATT è ottimizzato per l'esecuzione su dispositivi BLE. A questo scopo, utilizza il minor numero possibile di byte. Ogni attributo è identificato in modo univoco da un identificatore universale univoco (UUID), ovvero un formato standardizzato a 128 bit per un ID stringa utilizzato per identificare in modo univoco le informazioni. Gli attributi trasportati da ATT
sono formattati come caratteristiche e servizi.
- Caratteristica
- Una caratteristica contiene un singolo valore e da 0 a n descrittori che descrivono il valore della caratteristica. Una caratteristica può essere considerata un tipo,
analogo a una classe.
- Descrittore
- I descrittori sono attributi definiti che descrivono un valore caratteristico. Ad esempio, un descrittore potrebbe specificare una descrizione leggibile, un intervallo accettabile per il valore di una caratteristica o una unità di misura specifica per il valore di una caratteristica.
- Servizio
- Un servizio è un insieme di caratteristiche. Ad esempio, potresti avere un servizio denominato "Monitoraggio della frequenza cardiaca" che include caratteristiche come "misurazione della frequenza cardiaca". Puoi trovare un elenco di profili e servizi basati su GATT esistenti su bluetooth.org.
Ruoli e responsabilità
Quando un dispositivo interagisce con un dispositivo BLE, i ruoli e le responsabilità sono suddivisi in due modi diversi:
Centrale e periferico. Questo vale per la connessione BLE stessa: il dispositivo nel ruolo centrale esegue la scansione alla ricerca di annunci e il dispositivo nel ruolo periferico li pubblicizza. Due dispositivi che supportano solo il ruolo di periferica non possono comunicare tra loro, così come due dispositivi che supportano solo il ruolo di dispositivo centrale.
Server GATT e client GATT. Questo determina la modalità di comunicazione
tra i due dispositivi dopo aver stabilito la connessione. Il dispositivo nel ruolo client invia richieste di dati e il dispositivo nel ruolo server le soddisfa.
Per comprendere la differenza tra le suddivisioni dei ruoli centrali-periferici e server-client, prendiamo ad esempio uno smartphone Android e un tracker per attività abilitato al BLE che riporta i dati del sensore allo smartphone.
Lo smartphone, il dispositivo centrale, cerca attivamente i dispositivi BLE. Il tracker di attività, ovvero il dispositivo periferico, si annuncia e attende di ricevere una richiesta di connessione.
Dopo che lo smartphone e il tracker per attività hanno stabilito una connessione, inizieranno a trasferirsi tra loro i metadati GATT. In questo caso, l'app in esecuzione sullo smartphone invia richieste di dati, quindi agisce come client GATT. Il tracker per attività soddisfa queste richieste, quindi funge da server GATT.
Un design alternativo dell'app potrebbe prevedere invece che lo smartphone svolga il ruolo di server GATT. Per maggiori informazioni, consulta
BluetoothGattServer.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
