Bluetooth Low Energy (BLE) i mobil utveckling: vad det är, protokoll och hur det fungerar

Vad är Bluetooth Low Energy (BLE) och hur fungerar det?

Bluetooth Low Energy (BLE) fungerar enligt en klient-server-modell med två roller: Central (mobil enhet) och Peripheral (enhet). Central skannar etern och initierar anslutningen, medan Peripheral överför data. Till skillnad från klassisk Bluetooth är BLE inte avsett för ljudströmmar — dess uppgift är att överföra små paket med minimal strömförbrukning. Enligt Bluetooth SIG Core Specification 5.4 (2025) stöder BLE hastigheter upp till 2 Mbps med en ström på mindre än 15 mA i aktivt läge.

GATT-hierarki: Service, Characteristic, Descriptor

GATT (Generic Attribute Profile) definierar datastrukturen för Bluetooth Low Energy. Service är en logisk grupp av egenskaper (t.ex. Heart Rate Service 0x180D). Characteristic är en datapunkt med ett specifikt värde. Descriptor är metadata för en egenskap, inklusive CCCD för aviseringshantering. Varje element har ett UUID — 16-bitars för standard Bluetooth SIG-profiler eller 128-bitars för anpassade.

Bluetooth Low Energy i mobila applikationer använder denna hierarki för att organisera datautbyte mellan en smartphone och kringutrustning. En korrekt förståelse av GATT är grunden för att utveckla BLE-applikationer på båda plattformarna. Utvecklaren måste känna till UUID:erna för enhetens tjänster och egenskaper, samt egenskaperna för varje karakteristik (read, write, notify, indicate).

Advertising Data och Scan Response

BLE-enheter sänder reklampaket (advertising packets) för upptäckt. Advertising Data innehåller enhetens namn, tjänste-UUID, RSSI och Manufacturer Specific Data. Reklampaketets storlek är begränsad till 31 byte. För att överföra ytterligare data används Scan Response — ett andra paket som den centrala enheten begär efter upptäckt.

BLE på iOS: Core Bluetooth, CBCentralManager, CBPeripheral

På iOS hanterar Core Bluetooth-ramverket Bluetooth Low Energy. CBCentralManager hanterar skanning och anslutning, CBPeripheral representerar en fjärr-BLE-enhet. Processen är standard: initiera CBCentralManager, kontrollera poweredOn-status, starta scanForPeripherals, ansluta och upptäcka tjänster. Core Bluetooth hanterar automatiskt strömförsörjningen till radiomodulen — om BLE inte används stängs den av.

BLE i mobil utveckling på iOS kräver hänsyn till bakgrundslägen. Core Bluetooths bakgrundsläge aktiveras via projektets Capabilities (Uses Bluetooth LE accessories). I bakgrunden kan appen ta emot aviseringar från egenskaper, men skanning är begränsad — systemet startar om den endast när enheten rör sig. För iBeacon fungerar bakgrundsskanning mer aktivt via CLLocationManager.

Exempel på BLE-skanning i 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("Hittade: \(peripheral.name ?? "unknown")")
    }
}

I detta exempel hanterar CBCentralManagerDelegate alla BLE-anslutningshändelser. Metoden centralManagerDidUpdateState kontrollerar om Bluetooth är påslaget på den mobila enheten. Efter framgångsrik initiering startar skanningen. Callbacken didDiscover anropas för varje hittad enhet.

Ansluta och läsa egenskaper i Core Bluetooth

Efter att ha upptäckt en enhet måste connect och discoverServices anropas. CBPeripheralDelegate tillhandahåller metoder för varje steg: didDiscoverServices, didDiscoverCharacteristics, didUpdateValueFor. Varje metod är asynkron — data kommer via delegerade callbacks. RSSI (Received Signal Strength Indicator) visar signalstyrkan: ju närmare värdet är 0, desto starkare är signalen.

BLE på Android: BluetoothAdapter, BluetoothGatt, BluetoothLeScanner

På Android implementeras Bluetooth Low Energy via paketet android.bluetooth. BluetoothAdapter är ingångspunkten för alla BLE-operationer. BluetoothLeScanner startar skanning med ScanCallback-callbacks. Efter att ha upptäckt en enhet skapas BluetoothGatt — en anslutning till kringutrustningen. BluetoothGattCallback hanterar händelser: anslutning, tjänstupptäckt, läsning av egenskaper, RSSI-ändringar.

Bluetooth Low Energy i mobila applikationer på Android kräver explicita tillstånd BLUETOOTH_SCAN, BLUETOOTH_CONNECT och ACCESS_FINE_LOCATION. Sedan Android 12 är tillstånden separerade: BLUETOOTH_SCAN för skanning, BLUETOOTH_CONNECT för anslutning. ACCESS_FINE_LOCATION krävs endast för att skanna vissa typer av enheter. Utan dessa tillstånd kan appen inte fungera med BLE.

Exempel på BLE-skanning i 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", "Enhet: ${device.name}, RSSI: $rssi")
        }
    }
}

ScanSettings gör det möjligt att konfigurera skanningsläge: LOW_POWER för att spara batteri, BALANCED för standarduppgifter, LOW_LATENCY för maximal upptäcktshastighet. ScanFilter begränsar sökningen efter tjänste-UUID, enhetsnamn eller MAC-adress. Filtrering minskar strömförbrukningen och påskyndar upptäckten av önskad enhet.

BluetoothGatt: läsning och aviseringar på Android

Efter att ha skapat BluetoothGatt via connectGatt anropar appen discoverServices. BluetoothGattCallback innehåller onServicesDiscovered, onCharacteristicRead, onCharacteristicChanged. För att ta emot aviseringar om egenskapsändringar måste setCharacteristicNotification anropas. Processen kräver uppmärksamhet: varje GATT-operation är asynkron och resultatet kommer i en separat callback.

iBeacon, Bonding och Advertising Data i BLE-ekosystemet

iBeacon är Apples teknik för BLE-fyrar som sänder UUID, Major och Minor. Fyrenheten sänder ett reklampaket och mobilapplikationen bestämmer plats och avstånd baserat på denna data. På iOS stöds iBeacon inbyggt via CLLocationManager. På Android krävs ett tredjepartsbibliotek (t.ex. AltBeacon eller Android iBeacon Library).

Bonding är proceduren för att skapa en permanent säker anslutning mellan BLE-enheter. Efter Bonding sparas krypteringsnycklar och enheterna ansluts automatiskt när de kommer nära varandra igen. På iOS hanteras bonding automatiskt av systemet. På Android — via BluetoothDevice.createBond(). Bonding är viktigt för bärbara enheter och fitnesstrackers som kräver snabb återanslutning.

Reklampaket och Manufacturer Specific Data

Advertising Data är en viktig upptäcktsmekanism i Bluetooth Low Energy. Enhetstillverkare kan lägga till Manufacturer Specific Data i reklampaketet för att överföra anpassad data. Paketformatet inkluderar en Company Identifier (2 byte) och godtycklig data. På iOS accepterar CBCentralManager en array av tjänste-UUID för filtrering — detta sparar batteri. På Android fungerar ScanFilter enligt samma princip.

Jämförelse av iOS och Android för BLE-utveckling

BLE-optimering: MTU, Connection Interval och bakgrundsläge

MTU (Maximum Transmission Unit) är den maximala storleken på ett enda Bluetooth Low Energy-datapaket. Som standard är MTU 23 byte (3 byte header + 20 byte data). Att öka MTU till 512 byte påskyndar avsevärt överföringen vid utbyte av konfigurationer eller loggar. På iOS visar maximumWriteValueLength tillgänglig MTU. På Android används requestMtu() för att öka MTU.

Connection Interval är den frekvens med vilken den centrala enheten pollar kringutrustningen. Ju kortare intervall, desto högre överföringshastighet, men också högre strömförbrukning. Typiska värden varierar från 7,5 ms till 4 sekunder. För fitnesstrackers räcker 100 ms; för ljud — 7,5 ms. BLE i mobil utveckling kräver en balans mellan överföringshastighet och enhetens batteritid.

Bakgrundsläge på iOS och Android

iOS stöder BLE i bakgrundsläge via Background Modes, men med begränsningar. En app i bakgrunden tar emot aviseringar från egenskaper men kan inte aktivt skanna. Systemet startar om skanningen när enhetens plats ändras. På Android kräver bakgrundsskanning en Foreground Service med en permanent avisering. Utan detta kommer mobilsystemet att döda processen när appen minimeras.

Praktiska optimeringsrekommendationer

För tillförlitlig BLE-drift i mobila applikationer, följ dessa regler. Använd notify istället för polling — en egenskap med aviseringar skickar data vid förändring, vilket sparar batteri. Ställ in optimal MTU i början av anslutningen. Filtrera enheter efter tjänste-UUID vid skanning. Kontrollera BLE-stackens kompatibilitet på olika modeller — tillverkare (Xiaomi, Huawei, Samsung) gör ändringar som påverkar Bluetooth-beteendet.