Descubrimiento del servicio BLE de Android (BluetoothGatt # discoverServices ()) y Low Energy vs BR / EDR

TLDR: ¿Se espera que los resultados de descubrimiento de servicio a través de discoverServices() difieran según el transporte subyacente (LE vs. BR / EDR)?

Tengo un accesorio Bluetooth de modo mixto que ofrece características distintas como un dispositivo Bluetooth Classic y como un Bluetooth LE Peripheral.

Android tiene problemas para descubrir los servicios Bluetooth LE GATT del accesorio a menos que utilice la peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback, BluetoothDevice.TRANSPORT_LE) ocultada peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback, BluetoothDevice.TRANSPORT_LE) que le permite forzar el uso de TRANSPORT_LE o TRANSPORT_BREDR .

Cuando conecté el dispositivo a través de peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback) y luego llamé discoverServices() sólo descubriría los UUID de servicio genéricos (y sólo después de muchos intentos fallidos de conexión con el estado misterioso 133 entregado a onConnectionStateChange ).

  • "00001800-0000-1000-8000-00805f9b34fb" (acceso genérico)
  • "00001801-0000-1000-8000-00805f9b34fb" (atributo genérico).

Sin embargo, cuando invoco el peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback, BluetoothDevice.TRANSPORT_LE) ocultos peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback, BluetoothDevice.TRANSPORT_LE) y entonces llamados discoverServices() consigo la respuesta esperada completa del descubrimiento del servicio:

  • "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" (Mi servicio personalizado)
  • "00001800-0000-1000-8000-00805f9b34fb" (acceso genérico)
  • "00001801-0000-1000-8000-00805f9b34fb" (atributo genérico).

¿Se espera que este comportamiento del framework Android (Dudo, por lo tanto, la API oculta)? ¿Es mala forma diseñar un dispositivo periférico con esta operación de "modo mixto"?

One Solution collect form web for “Descubrimiento del servicio BLE de Android (BluetoothGatt # discoverServices ()) y Low Energy vs BR / EDR”

los

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

Método es público a partir de la API 23, y por lo tanto parece ser la forma sancionada de evitar el problema descrito anteriormente.

El método parece haber sido introducido en AOSP en la versión android-5.0.0_r1 , y estaba presente en cada versión que conduce a que se publique en API 23. Por lo tanto, debe ser seguro invocar a través de la reflexión para los dispositivos con niveles de API 21 y 22. Para dispositivos con versiones de plataformas anteriores, parece que el marco de Android no proporciona herramientas para mitigar el problema.

  • Cómo forzar Bluetooth LE "Just Works" Emparejamiento en Android
  • Android BLE- ¿Cómo se llama al método onScanResult en ScanCallback?
  • ¿Por qué `ACTION_GATT_DISCONNECTED` toma tanto tiempo para actualizar el estado?
  • Desconexión del dispositivo BLE con el dispositivo Android automáticamente. Android BLE
  • Creación de servicios de fondo para Bluetooth de baja energía en Android
  • ¿Cuál es la duración de la exploración en api del mensaje cercano de google?
  • Bluetooth Low Energy startScan en Android 6.0 no encuentra dispositivos
  • ¿Cómo trabajar con BLE Android 4.3 cómo escribir características?
  • Android BLE GATT_ERROR (133) en la conexión al dispositivo
  • Bluetooth LE Scan no funciona
  • Vinculación mediante programación al dispositivo BLE en Android
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.