Bluetooth Low Energy (BLE) no Desenvolvimento Móvel: O Que É, Protocolos e Como Funciona

O que é Bluetooth Low Energy (BLE) e como funciona?

Bluetooth Low Energy (BLE) funciona num modelo cliente-servidor com dois papéis: Central (dispositivo móvel) e Peripheral (dispositivo). Central faz scanning das ondas e inicia a ligação, enquanto Peripheral transmite dados. Ao contrário do Bluetooth clássico, o BLE não foi concebido para fluxos de áudio — a sua função é transmitir pequenos pacotes com consumo mínimo de energia. De acordo com a Bluetooth SIG Core Specification 5.4 (2025), o BLE suporta velocidades até 2 Mbps com um consumo inferior a 15 mA em modo ativo.

Hierarquia GATT: Service, Characteristic, Descriptor

GATT (Generic Attribute Profile) define a estrutura de dados do Bluetooth Low Energy. Service é um grupo lógico de características (exemplo: Heart Rate Service 0x180D). Characteristic é um ponto de dados com um valor específico. Descriptor são metadados da característica, incluindo CCCD para gestão de notificações. Cada elemento tem um UUID — 16 bits para perfis padrão Bluetooth SIG ou 128 bits para personalizados.

Bluetooth Low Energy em aplicações móveis utiliza esta hierarquia para organizar a troca de dados entre um smartphone e periféricos. Uma compreensão adequada do GATT é a base para desenvolver aplicações BLE em ambas as plataformas. O desenvolvedor deve conhecer os UUIDs dos serviços e características do dispositivo, bem como as propriedades de cada característica (read, write, notify, indicate).

Advertising Data e Scan Response

Os dispositivos BLE transmitem pacotes de publicidade (advertising packets) para deteção. Advertising Data contém o nome do dispositivo, UUIDs de serviços, RSSI e Manufacturer Specific Data. O tamanho do pacote de publicidade está limitado a 31 bytes. Para transmitir dados adicionais, utiliza-se Scan Response — um segundo pacote que o dispositivo central solicita após a deteção.

BLE no iOS: Core Bluetooth, CBCentralManager, CBPeripheral

No iOS, o framework Core Bluetooth gere o Bluetooth Low Energy. CBCentralManager gerencia o scanning e a ligação, CBPeripheral representa um dispositivo BLE remoto. O processo é padrão: inicializar o CBCentralManager, verificar o estado poweredOn, iniciar scanForPeripherals, conectar e descobrir serviços. O Core Bluetooth gere automaticamente a alimentação do módulo de rádio — se o BLE não estiver a ser utilizado, desliga-se.

BLE no desenvolvimento móvel em iOS requer consideração dos modos em segundo plano. O modo em segundo plano do Core Bluetooth é ativado através das Capabilities do projeto (Uses Bluetooth LE accessories). Em segundo plano, a aplicação pode receber notificações de características, mas o scanning é limitado — o sistema reinicia-o apenas quando o dispositivo se move. Para iBeacon, o scanning em segundo plano funciona mais ativamente através de CLLocationManager.

Exemplo de scanning BLE em Swift

import CoreBluetooth

class DeviceScanner: NSObject, CBCentralManagerDelegate {
    var centralManager: CBCentralManager!

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

    func centralManagerDidUpdateState(_ central: CBCentralManager) {
        guard central.state == .poweredOn else { return }
        central.scanForPeripherals(withServices: nil, options: nil)
    }

    func centralManager(_ central: CBCentralManager,
                        didDiscover peripheral: CBPeripheral,
                        advertisementData: [String: Any],
                        rssi RSSI: NSNumber) {
        print("Encontrado: \(peripheral.name ?? "unknown")")
    }
}

Neste exemplo, CBCentralManagerDelegate trata todos os eventos da ligação BLE. O método centralManagerDidUpdateState verifica se o Bluetooth está ligado no dispositivo móvel. Após a inicialização bem-sucedida, o scanning é iniciado. O callback didDiscover é invocado por cada dispositivo encontrado.

Ligar e ler características no Core Bluetooth

Após descobrir um dispositivo, é necessário chamar connect e discoverServices. CBPeripheralDelegate fornece métodos para tratar cada etapa: didDiscoverServices, didDiscoverCharacteristics, didUpdateValueFor. Cada método é assíncrono — os dados chegam através de callbacks delegados. RSSI (Received Signal Strength Indicator) mostra o nível do sinal: quanto mais próximo o valor estiver de 0, mais forte é o sinal.

BLE no Android: BluetoothAdapter, BluetoothGatt, BluetoothLeScanner

No Android, o Bluetooth Low Energy é implementado através do pacote android.bluetooth. BluetoothAdapter é o ponto de entrada para todas as operações BLE. BluetoothLeScanner inicia o scanning com callbacks ScanCallback. Após descobrir um dispositivo, é criado BluetoothGatt — uma ligação ao periférico. BluetoothGattCallback trata eventos: ligação, descoberta de serviços, leitura de características, alterações de RSSI.

Bluetooth Low Energy em aplicações móveis no Android requer permissões explícitas BLUETOOTH_SCAN, BLUETOOTH_CONNECT e ACCESS_FINE_LOCATION. Desde o Android 12, as permissões estão separadas: BLUETOOTH_SCAN para scanning, BLUETOOTH_CONNECT para ligar. ACCESS_FINE_LOCATION é necessária apenas para scanning de certos tipos de dispositivos. Sem estas permissões, a aplicação não pode funcionar com BLE.

Exemplo de scanning BLE em Kotlin

class BLEScanner(private val bluetoothAdapter: BluetoothAdapter) {

    fun startScan() {
        val scanner = bluetoothAdapter.bluetoothLeScanner
        val settings = ScanSettings.Builder()
            .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY)
            .build()
        scanner.startScan(null, settings, scanCallback)
    }

    private val scanCallback = object : ScanCallback() {
        override fun onScanResult(callbackType: Int, result: ScanResult) {
            val device = result.device
            val rssi = result.rssi
            Log.d("BLE", "Dispositivo: ${device.name}, RSSI: $rssi")
        }
    }
}

ScanSettings permite configurar o modo de scanning: LOW_POWER para poupar bateria, BALANCED para tarefas padrão, LOW_LATENCY para máxima velocidade de deteção. ScanFilter reduz a pesquisa por UUID de serviço, nome do dispositivo ou endereço MAC. A filtragem reduz o consumo de energia e acelera a deteção do dispositivo desejado.

BluetoothGatt: leitura e notificações no Android

Após criar BluetoothGatt através de connectGatt, a aplicação chama discoverServices. BluetoothGattCallback contém onServicesDiscovered, onCharacteristicRead, onCharacteristicChanged. Para receber notificações sobre alterações de características, é necessário chamar setCharacteristicNotification. O processo requer atenção: cada operação GATT é assíncrona e o resultado chega num callback separado.

iBeacon, Bonding e Advertising Data no ecossistema BLE

iBeacon é a tecnologia da Apple para balizas BLE que transmitem UUID, Major e Minor. O dispositivo baliza transmite um pacote de publicidade, e a aplicação móvel determina a localização e distância com base nestes dados. No iOS, o iBeacon tem suporte nativo através de CLLocationManager. No Android, é necessária uma biblioteca de terceiros (por exemplo, AltBeacon ou Android iBeacon Library).

Bonding é o procedimento para criar uma ligação segura permanente entre dispositivos BLE. Após o Bonding, as chaves de encriptação são guardadas e os dispositivos ligam-se automaticamente quando voltam a estar próximos. No iOS, o bonding é gerido automaticamente pelo sistema. No Android — através de BluetoothDevice.createBond(). O bonding é importante para dispositivos wearable e rastreadores de fitness que necessitam de reconexão rápida.

Pacotes de publicidade e Manufacturer Specific Data

Advertising Data é um mecanismo chave de deteção em Bluetooth Low Energy. Os fabricantes de dispositivos podem adicionar Manufacturer Specific Data ao pacote de publicidade para transmitir dados personalizados. O formato do pacote inclui um Company Identifier (2 bytes) e dados arbitrários. No iOS, o CBCentralManager aceita uma matriz de UUIDs de serviços para filtragem — isto poupa bateria. No Android, o ScanFilter funciona pelo mesmo princípio.

Comparação de iOS e Android para desenvolvimento BLE

Otimização BLE: MTU, Connection Interval e modo em segundo plano

MTU (Maximum Transmission Unit) é o tamanho máximo de um único pacote de dados Bluetooth Low Energy. Por padrão, o MTU é de 23 bytes (3 bytes de cabeçalho + 20 bytes de dados). Aumentar o MTU para 512 bytes acelera significativamente a transmissão ao trocar configurações ou registos. No iOS, maximumWriteValueLength mostra o MTU disponível. No Android, usa-se requestMtu() para aumentar o MTU.

Connection Interval é a frequência com que o dispositivo central consulta o periférico. Quanto menor o intervalo, maior a velocidade de transmissão, mas também o consumo de energia. Os valores típicos variam de 7,5 ms a 4 segundos. Para rastreadores de fitness, 100 ms é suficiente; para áudio — 7,5 ms. O BLE no desenvolvimento móvel requer um equilíbrio entre velocidade de transmissão e duração da bateria do dispositivo.

Modo em segundo plano no iOS e Android

O iOS suporta BLE em segundo plano através de Background Modes, mas com limitações. Uma aplicação em segundo plano recebe notificações de características, mas não pode fazer scanning ativamente. O sistema reinicia o scanning quando a localização do dispositivo muda. No Android, o scanning em segundo plano requer um Foreground Service com uma notificação persistente. Sem isso, o sistema móvel eliminará o processo ao minimizar a aplicação.

Recomendações práticas de otimização

Para um funcionamento fiável do BLE em aplicações móveis, siga estas regras. Use notify em vez de polling — uma característica com notificações envia dados quando muda, poupando bateria. Defina o MTU ideal no início da ligação. Filtre dispositivos por UUID de serviço ao fazer scanning. Verifique a compatibilidade da pilha BLE em diferentes modelos — os fabricantes (Xiaomi, Huawei, Samsung) fazem alterações que afetam o comportamento do Bluetooth.