TLDR: Wird erwartet, dass Service Discovery-Ergebnisse über discoverServices()
Ich habe ein Bluetooth-Zubehör im gemischten Modus, das verschiedene Funktionen als Bluetooth Classic-Gerät und als Bluetooth LE-Peripheriegerät bietet.
Android hat Probleme, die Bluetooth LE GATT-Dienste des Zubehörs zu finden, es sei denn, Sie verwenden das versteckte peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback, BluetoothDevice.TRANSPORT_LE) API, mit der Sie die Verwendung von TRANSPORT_LE oder TRANSPORT_BREDR erzwingen können.
Wenn ich das Gerät über peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback) und dann discoverServices() genannt Ich würde nur die generischen Dienst-UUIDs entdecken (und erst nach vielen fehlgeschlagenen Verbindungsversuchen mit mysteriösem Status 133, die an onConnectionStateChange ).
Allerdings, wenn ich die versteckte peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback, BluetoothDevice.TRANSPORT_LE) und dann discoverServices() genannt. Ich bekomme die volle erwartete Service Discovery-Antwort:
Ist das erwartete Android-Framework-Verhalten (Doubt it, also versteckte API)? Ist es schlecht, ein Peripheriegerät mit dieser "Mixed-Mode" -Operation zu entwickeln?
Das
Die-Methode ist seit API 23 öffentlich und scheint daher der sanktionierte Weg zu sein, das oben beschriebene Problem zu vermeiden.
Die Methode scheint für AOSP in der android-5.0.0_r1 Version eingeführt worden zu sein und war in Jede Veröffentlichung, die dazu geführt hat, wird in API 23 veröffentlicht.
Daher sollte es sicher sein, über Reflektion für Geräte mit den API-Stufen 21 und 22 aufzurufen. Bei Geräten mit früheren Plattformversionen scheint das Android-Framework keine Tools zur Verfügung zu stellen, um das Problem zu mindern.
Tags und Links android bluetooth-lowenergy android-bluetooth