Android BLE Service Discovery (Bluetooth Gatt # discoverServices()) und Low Energy vs BR/EDR

Question

TLDR: Wird erwartet, dass Service Discovery Ergebnisse über discoverServices() basierend auf dem zugrunde liegenden Transport (LE vs. BR/EDR) abweichen?

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 Mühe, die Entdeckung der Bluetooth LE GATT Dienste des Zubehörs, wenn Sie die versteckten peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback, BluetoothDevice.TRANSPORT_LE) API verwenden, die Sie verwenden entweder TRANSPORT_LE oder TRANSPORT_BREDR zwingen können.

Wenn ich das Gerät über peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback) verbunden und rief dann discoverServices() ich nur die generischen Dienst UUID entdecken würde (und erst nach vielen Verbindungsversuche mit geheimnisvollen Status 133-onConnectionStateChange geliefert fehlgeschlagen).

• „00001800-0000-1000-8000-00805f9b34fb“ (Generic Access)
• „00001801-0000-1000-8000-00805f9b34fb“ (Generic Attribute).

Allerdings, wenn ich die versteckte peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback, BluetoothDevice.TRANSPORT_LE) aufrufen und dann rief discoverServices() ich die volle erwartete Service-Discovery-Antwort erhalten:

• "XXXXXXXXXXXX-XXXXXXXX-XXXXXXXXXXXX" (My benutzerdefinierten Dienst)
• "00001800-0000-1000-8000-00805f9b34fb" (generischer Zugriff)
• "00001801-0000-1000-8000-00805f9b34fb" (generisches Attribut).

Ist das erwartete Android-Framework-Verhalten (Zweifel, also versteckte API)? Ist es schlecht, ein Peripheriegerät mit diesem "gemischten Modus" zu entwickeln?

Answer 1

Die

BluetoothDevice.connectGatt(Context context, boolean autoConnect, android.bluetooth.BluetoothGattCallback callback, int transport)

Methode ist öffentlich als der API 23 und scheint so die sanktioniert Weg, um das Problem zu vermeiden, oben beschrieben.

Die Methode erscheint introduced zu AOSP gefunden in der android-5.0.0_r1 Freisetzung zu haben, und wurde in jedem Release, um es im Vorfeld in öffentlichen API 23. Daher genommen wird, sollte es sicher über Reflektion mit API für Geräte zum Aufrufen Ebenen 21 und 22. Für Geräte mit früheren Plattformversionen scheint das Android-Framework keine Tools zur Verfügung zu stellen, um das Problem zu beheben.