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"?

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.

  • BluetoothLeScanner.startScan con Android 6.0 no detecta dispositivos
  • BLE en Nexus 7 (ME370T) con android 4.4.2
  • Problemas con Android Bluetooth LE Notificaciones
  • ¿Cuál es la duración de la exploración en api del mensaje cercano de google?
  • BluetoothGatt: la negociación de nuevos MTU tiene éxito pero el nuevo tamaño no se puede utilizar (diferencia de 3 bytes)
  • Android BLE- ¿Cómo se llama al método onScanResult en ScanCallback?
  • Bluetooth: Transferencia de llamadas desde el teléfono Android de origen a un kit de desarrollo de audio de receptor?
  • Android BLE: onCharacteristicRead () parece estar bloqueado por subprocesos
  • Android 4.4.4 Moto G Bluetooth LE vuelve a conectar el problema
  • Implementación del perfil de soporte de protocolo de Internet (IPSP) para Bluetooth Low Energy en Android
  • ¿Cómo trabajar con BLE Android 4.3 cómo escribir características?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.