Bluetooth e BLE: o que é, diferença entre Classic e Low Energy e como funciona

O que são Bluetooth e BLE?

Bluetooth é um padrão de rede de área pessoal sem fio (WPAN) que opera na banda ISM de 2,4 GHz, projetado para comunicação de dispositivos a distâncias de até 100 metros. A especificação IEEE 802.15.1 define as camadas física e MAC, enquanto a pilha Bluetooth SIG define perfis de alto nível para cenários específicos: headsets de áudio (HSP), transferência de arquivos (OPP), entrada de teclado (HID).

O padrão se dividiu em dois ramos desde a versão 4.0 (2010): Bluetooth Classic (BR/EDR — Basic Rate / Enhanced Data Rate) e Bluetooth Low Energy (BLE, anteriormente Bluetooth Smart). O Classic é projetado para fluxos contínuos — chamadas de áudio, música, arquivos. O BLE foi criado para aplicações onde os dados são transmitidos em pacotes curtos com pausas de dezenas de segundos ou minutos — monitores de frequência cardíaca, tags, sensores de temperatura.

De acordo com a Bluetooth SIG (2025), 99% dos novos smartphones suportam ambas as versões, e o ecossistema BLE inclui mais de 15 tipos de perfis, desde Blood Pressure até Environmental Sensing.

Bluetooth Classic vs BLE: Comparação

A escolha entre Classic e BLE depende do cenário: para streaming de áudio apenas o Classic é adequado, para consultar um sensor uma vez por hora — apenas o BLE. O BR/EDR usa 79 canais com espaçamento de 1 MHz e salto de frequência adaptativo (AFH), proporcionando resistência a interferências Wi-Fi.

BLE 5.x adicionou LE Coded PHY para aumentar o alcance até 1 km (em áreas abertas) e LE Audio com codec LC3 — a nova versão está gradualmente borrando o limite entre Classic e BLE para cenários de áudio.

Arquitetura BLE: Controller, Host e Application

A pilha BLE é dividida em três camadas: Controller (camadas física e de enlace), Host (L2CAP, ATT, GATT, Gerenciador de Segurança) e Application (implementação do perfil no aplicativo). Essa separação permite que o fabricante do chip implemente o Controller no firmware, enquanto o desenvolvedor do aplicativo móvel trabalha apenas com abstrações GATT.

A camada de enlace (LL) gerencia o tempo no ar: o dispositivo alterna entre os estados Standby, Advertising, Scanning, Initiating e Connection. No estado Connected, Central e Peripheral concordam com um intervalo de conexão — a frequência com que trocam pacotes de dados. Um intervalo típico é de 7,5 a 1000 ms; quanto mais frequente a troca, maior a taxa de transferência e maior o consumo de energia.

O Gerenciador de Segurança (SM) implementa criptografia AES-128 com troca de chaves através do protocolo de pareamento. Existem três modos: Just Works (sem entrada de PIN), Passkey Entry (código de 6 dígitos na tela) e OOB (NFC ou QR). Para dispositivos vestíveis, geralmente se usa Just Works; para dispositivos médicos, OOB com verificação adicional.

De acordo com a Bluetooth Core Specification 5.4 (2023), o tempo de configuração de conexão segura no modo LE Secure Connections não excede 300 ms com um intervalo de conexão de 30 ms.

Perfil GATT: Serviços, Características e Descritores

O ATT (Protocolo de Atributo) é o modelo de transporte básico onde o servidor (dispositivo periférico) armazena atributos e o cliente (smartphone) os lê ou escreve. O GATT (Perfil de Atributo Genérico) constrói uma hierarquia sobre o ATT: Service → Characteristic → Descriptor.

Cada serviço é um grupo lógico de características que descrevem uma função do dispositivo: Heart Rate Service (UUID 0x180D) contém a característica Heart Rate Measurement (UUID 0x2A37) com um Descritor de Configuração de Característica do Cliente (0x2902) que controla as notificações. O desenvolvedor do aplicativo móvel obtém a lista de serviços através de discoverServices(), depois encontra a característica necessária pelo UUID e se inscreve nas notificações.

BLE usa UUIDs de 16 bits para serviços padronizados da Bluetooth SIG e UUIDs de 128 bits para serviços personalizados do fabricante. Por exemplo, um estojo com rastreador pode definir um serviço A000-… com uma característica para transmitir o nível de carga de sua bateria.

Exemplo de trabalho com GATT em Kotlin (Android)

private val gattCallback = object BluetoothGattCallback() {
    override fun onServicesDiscovered(
        gatt: BluetoothGatt, status: Int
    ) {
        val service = gatt.getService(UUID.fromString("0000180d-0000-1000-8000-00805f9b34fb"))
        val char = service?.getCharacteristic(
            UUID.fromString("00002a37-0000-1000-8000-00805f9b34fb")
        )
        gatt.setCharacteristicNotification(char, true)
    }

    override fun onCharacteristicChanged(
        gatt: BluetoothGatt, char: BluetoothGattCharacteristic
    ) {
        val heartRate = char.getIntValue(BluetoothGattCharacteristic.FORMAT_UINT8, 1)
        updateUi("Pulso: $heartRate bpm")
    }
}

No exemplo, o aplicativo encontra o serviço Heart Rate pelo UUID padrão da Bluetooth SIG, obtém a característica de medição de pulso e se inscreve em suas notificações — sempre que o pulso muda, o dispositivo periférico envia dados sem uma solicitação explícita do Central.

Advertising, varredura e estabelecimento de conexão

Advertising é um mecanismo chave do BLE onde um dispositivo Peripheral envia periodicamente pacotes de broadcast (PDUs de advertising) em três canais primários (37, 38, 39). O dispositivo central varre esses canais, recebe os dados de advertising e pode iniciar uma conexão.

Um pacote de advertising contém até 31 bytes de carga útil: flags, nível de potência TX, nome local, UUIDs de serviço, dados específicos do fabricante. Isso é suficiente para transmitir leituras de sensores sem estabelecer uma conexão — modo Connectionless (tipo Broadcaster). Para transmissão contínua de dados (por exemplo, temperatura uma vez por minuto), usa-se uma conexão com intervalo de até 1000 ms.

Nas plataformas móveis, a varredura é iniciada através de startScan() (Android) ou scanForPeripherals() (iOS). A filtragem por UUID de serviço economiza energia ao não processar todos os dispositivos visíveis — o aplicativo recebe um callback apenas para tags ou sensores relevantes.

Exemplo de varredura de dispositivos BLE em Swift (iOS)

import CoreBluetooth

class ScannerViewController: UIViewController {
    private var centralManager: CBCentralManager!

    override func viewDidLoad() {
        centralManager = CBCentralManager(
            delegate: self, queue: nil
        )
    }

    func centralManagerDidUpdateState(central: CBCentralManager) {
        if central.state == .poweredOn {
            centralManager.scanForPeripherals(
                withServices: nil, options: nil
            )
        }
    }

    func centralManager(
        central: CBCentralManager,
        didDiscover peripheral: CBPeripheral,
        advertisementData: [String : Any],
        rssi RSSI: NSNumber
    ) {
        if let name = advertisementData[CBAdvertisementDataLocalNameKey] {
            print("Dispositivo encontrado: \(name)")
        }
    }
}

Após descobrir um dispositivo, o Central chama connect(), passando o objeto CBPeripheral. Os parâmetros de conexão (intervalo, latência, tempo de supervisão) são negociados no nível da camada de enlace — o desenvolvedor não os gerencia diretamente, mas pode influenciar através de requestConnectionPriority no Android.

Bluetooth LE no desenvolvimento móvel: Core Bluetooth e android.bluetooth

Ambas as plataformas móveis fornecem APIs nativas para trabalhar com BLE. O Core Bluetooth (iOS) usa uma abordagem de delegados: o gerenciador central inicia operações e o objeto periférico relata resultados através de métodos delegados. O android.bluetooth (Android) é construído sobre interfaces de callback e suporta operações GATT paralelas com múltiplos dispositivos.

Diferenças principais entre as plataformas:

• iOS — suporta até 7 conexões simultâneas; o modo BLE em segundo plano requer UIBackgroundModes = bluetooth-central; após sair do primeiro plano, o sistema pode atrasar os callbacks por vários minutos
• Android — não tem limite fixo de conexões (limitado pela memória); requer permissões BLUETOOTH_SCAN e BLUETOOTH_CONNECT (Android 12+); um serviço em primeiro plano é necessário para varredura confiável em segundo plano
• Flutter — o pacote flutter_blue_plus abstrai as APIs das plataformas com uma interface Dart unificada: o código para varredura e operações GATT é idêntico em ambas as plataformas

De acordo com testes da Bluetooth SIG (2024), o tempo de conexão BLE entre um smartphone e um rastreador fitness é em média 150–300 ms no Android e 100–250 ms no iOS — a diferença se deve às políticas de gerenciamento do módulo de radiofrequência.

Exemplo de conexão BLE em Dart (Flutter)

import 'package:flutter_blue_plus/flutter_blue_plus.dart';

class BleService {
  final FlutterBluePlus fbp = FlutterBluePlus();

  Future<void> scanAndConnect(String deviceName) async {
    await fbp.startScan(timeout: Duration(seconds: 15));

    await for (final result in fbp.scanResults) {
      if (result.device.advName == deviceName) {
        await fbp.stopScan();
        await result.device.connect();
        break;
      }
    }
  }
}

O desenvolvedor Flutter obtém uma interface de API unificada; sob o capô, o flutter_blue_plus traduz as chamadas para android.bluetooth nativo ou Core Bluetooth. Essa abordagem reduz o tempo de desenvolvimento de aplicativos para trabalhar com periféricos BLE em ambas as plataformas.