Bluetooth Low Energy (BLE) w programowaniu mobilnym: co to jest, jakie protokoły i jak działa

Czym jest Bluetooth Low Energy (BLE) i jak działa?

Bluetooth Low Energy (BLE) działa w modelu klient-serwer z dwiema rolami: Central (urządzenie mobilne) i Peripheral (urządzenie). Central skanuje eter i inicjuje połączenie, podczas gdy Peripheral przesyła dane. W przeciwieństwie do klasycznego Bluetooth, BLE nie jest przeznaczony do strumieni audio — jego zadaniem jest przesyłanie małych pakietów przy minimalnym poborze mocy. Według Bluetooth SIG Core Specification 5.4 (2025), BLE obsługuje prędkość do 2 Mbps przy prądzie mniejszym niż 15 mA w trybie aktywnym.

Hierarchia GATT: Service, Characteristic, Descriptor

GATT (Generic Attribute Profile) definiuje strukturę danych Bluetooth Low Energy. Service to logiczna grupa cech (np. Heart Rate Service 0x180D). Characteristic to punkt danych z konkretną wartością. Descriptor to metadane cechy, w tym CCCD do zarządzania powiadomieniami. Każdy element ma UUID — 16-bitowy dla standardowych profili Bluetooth SIG lub 128-bitowy dla niestandardowych.

Bluetooth Low Energy w aplikacjach mobilnych używa tej hierarchii do organizowania wymiany danych między smartfonem a urządzeniami peryferyjnymi. Prawidłowe zrozumienie GATT to podstawa tworzenia aplikacji BLE na obu platformach. Deweloper musi znać UUID usług i cech urządzenia, a także właściwości każdej cechy (read, write, notify, indicate).

Advertising Data i Scan Response

Urządzenia BLE przesyłają pakiety reklamowe (advertising packets) w celu wykrycia. Advertising Data zawiera nazwę urządzenia, UUID usług, RSSI i Manufacturer Specific Data. Rozmiar pakietu reklamowego jest ograniczony do 31 bajtów. Do przesyłania dodatkowych danych używany jest Scan Response — drugi pakiet, który urządzenie centralne żąda po wykryciu.

BLE na iOS: Core Bluetooth, CBCentralManager, CBPeripheral

Na iOS za Bluetooth Low Energy odpowiada framework Core Bluetooth. CBCentralManager zarządza skanowaniem i połączeniem, CBPeripheral reprezentuje zdalne urządzenie BLE. Proces jest standardowy: inicjalizacja CBCentralManager, sprawdzenie stanu poweredOn, uruchomienie scanForPeripherals, połączenie i wykrycie usług. Core Bluetooth automatycznie zarządza zasilaniem modułu radiowego — jeśli BLE nie jest używane, wyłącza się.

BLE w programowaniu mobilnym na iOS wymaga uwzględnienia trybów tła. Tryb tła Core Bluetooth włącza się przez Capabilities projektu (Uses Bluetooth LE accessories). W tle aplikacja może otrzymywać powiadomienia od cech, ale skanowanie jest ograniczone — system uruchamia je ponownie tylko przy ruchu urządzenia. Dla iBeacon skanowanie w tle działa aktywniej przez CLLocationManager.

Przykład skanowania BLE w 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("Znaleziono: \(peripheral.name ?? "unknown")")
    }
}

W tym przykładzie CBCentralManagerDelegate obsługuje wszystkie zdarzenia połączenia BLE. Metoda centralManagerDidUpdateState sprawdza, czy Bluetooth jest włączony na urządzeniu mobilnym. Po pomyślnej inicjalizacji rozpoczyna się skanowanie. Callback didDiscover jest wywoływany dla każdego znalezionego urządzenia.

Łączenie i odczytywanie cech w Core Bluetooth

Po wykryciu urządzenia należy wywołać connect i discoverServices. CBPeripheralDelegate udostępnia metody do obsługi każdego kroku: didDiscoverServices, didDiscoverCharacteristics, didUpdateValueFor. Każda metoda jest asynchroniczna — dane przychodzą przez callbacki delegowane. RSSI (Received Signal Strength Indicator) pokazuje poziom sygnału: im bliżej 0, tym silniejszy sygnał.

BLE na Androidzie: BluetoothAdapter, BluetoothGatt, BluetoothLeScanner

Na Androidzie Bluetooth Low Energy jest implementowany przez pakiet android.bluetooth. BluetoothAdapter to punkt wejścia dla wszystkich operacji BLE. BluetoothLeScanner uruchamia skanowanie z callbackami ScanCallback. Po wykryciu urządzenia tworzone jest BluetoothGatt — połączenie z urządzeniem peryferyjnym. BluetoothGattCallback obsługuje zdarzenia: połączenie, wykrycie usług, odczyt cech, zmiany RSSI.

Bluetooth Low Energy w aplikacjach mobilnych na Androidzie wymaga jawnych uprawnień BLUETOOTH_SCAN, BLUETOOTH_CONNECT i ACCESS_FINE_LOCATION. Od Androida 12 uprawnienia są rozdzielone: BLUETOOTH_SCAN do skanowania, BLUETOOTH_CONNECT do łączenia. ACCESS_FINE_LOCATION jest potrzebne tylko do skanowania określonych typów urządzeń. Bez tych uprawnień aplikacja nie może działać z BLE.

Przykład skanowania BLE w 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", "Urządzenie: ${device.name}, RSSI: $rssi")
        }
    }
}

ScanSettings pozwala skonfigurować tryb skanowania: LOW_POWER do oszczędzania baterii, BALANCED do standardowych zadań, LOW_LATENCY dla maksymalnej prędkości wykrywania. ScanFilter zawęża wyszukiwanie po UUID usługi, nazwie urządzenia lub adresie MAC. Filtrowanie zmniejsza zużycie energii i przyspiesza wykrywanie żądanego urządzenia.

BluetoothGatt: odczyt i powiadomienia na Androidzie

Po utworzeniu BluetoothGatt przez connectGatt aplikacja wywołuje discoverServices. BluetoothGattCallback zawiera onServicesDiscovered, onCharacteristicRead, onCharacteristicChanged. Aby otrzymywać powiadomienia o zmianach cechy, należy wywołać setCharacteristicNotification. Proces wymaga uwagi: każda operacja GATT jest asynchroniczna, a wynik przychodzi w osobnym callbacku.

iBeacon, Bonding i Advertising Data w ekosystemie BLE

iBeacon to technologia Apple dla beaconów BLE, które przesyłają UUID, Major i Minor. Urządzenie-beacon nadaje pakiet reklamowy, a aplikacja mobilna na podstawie tych danych określa lokalizację i odległość. Na iOS iBeacon jest obsługiwany natywnie przez CLLocationManager. Na Androidzie wymagana jest biblioteka zewnętrzna (np. AltBeacon lub Android iBeacon Library).

Bonding to procedura tworzenia stałego bezpiecznego połączenia między urządzeniami BLE. Po Bondingu klucze szyfrowania są zapisywane, a urządzenia łączą się automatycznie przy ponownym zbliżeniu. Na iOS bonding jest zarządzany automatycznie przez system. Na Androidzie — przez BluetoothDevice.createBond(). Bonding jest ważny dla urządzeń noszonych i trackerów fitness, które wymagają szybkiego ponownego połączenia.

Pakiety reklamowe i Manufacturer Specific Data

Advertising Data to kluczowy mechanizm wykrywania w Bluetooth Low Energy. Producenci urządzeń mogą dodawać Manufacturer Specific Data do pakietu reklamowego w celu przesyłania niestandardowych danych. Format pakietu obejmuje Company Identifier (2 bajty) i dowolne dane. Na iOS CBCentralManager przyjmuje tablicę UUID usług do filtrowania — to oszczędza baterię. Na Androidzie ScanFilter działa na tej samej zasadzie.

Porównanie iOS i Android dla programowania BLE

Optymalizacja BLE: MTU, Connection Interval i tryb tła

MTU (Maximum Transmission Unit) to maksymalny rozmiar pojedynczego pakietu danych Bluetooth Low Energy. Domyślnie MTU wynosi 23 bajty (3 bajty nagłówka + 20 bajtów danych). Zwiększenie MTU do 512 bajtów znacznie przyspiesza transmisję podczas wymiany konfiguracji lub logów. Na iOS maximumWriteValueLength pokazuje dostępne MTU. Na Androidzie do zwiększenia MTU używa się requestMtu().

Connection Interval to częstotliwość, z jaką urządzenie centralne odpytuje urządzenie peryferyjne. Im krótszy interwał, tym wyższa prędkość transmisji, ale także większy pobór mocy. Typowe wartości wahają się od 7,5 ms do 4 sekund. Dla trackerów fitness wystarczy 100 ms, dla audio — 7,5 ms. BLE w programowaniu mobilnym wymaga równowagi między prędkością transmisji a czasem pracy baterii urządzenia.

Tryb tła na iOS i Androidzie

iOS obsługuje BLE w tle przez Background Modes, ale z ograniczeniami. Aplikacja w tle otrzymuje powiadomienia od cech, ale nie może aktywnie skanować. System uruchamia ponownie skanowanie przy zmianie lokalizacji urządzenia. Na Androidzie skanowanie w tle wymaga Foreground Service ze stałym powiadomieniem. Bez niego system mobilny zabije proces przy minimalizacji aplikacji.

Praktyczne zalecenia dotyczące optymalizacji

Do niezawodnego działania BLE w aplikacjach mobilnych stosuj te zasady. Używaj notify zamiast pollingu — cecha z powiadomieniami wysyła dane przy zmianie, oszczędzając baterię. Ustaw optymalne MTU na początku połączenia. Filtruj urządzenia po UUID usługi podczas skanowania. Sprawdzaj zgodność stosu BLE na różnych modelach — producenci (Xiaomi, Huawei, Samsung) wprowadzają zmiany wpływające na działanie Bluetooth.