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.

  • Leer paquete de publicidad en Android
  • Android BLE: onCharacteristicChanged nunca se dispara
  • Android BLE API: GATT Notificación no recibida
  • Diferencia entre close () y disconnect () en Android Bluetooth API?
  • Cómo resolver el error onClientConnectionState () - status = 22 clientIf = 7 en BLE
  • Desactivar con fuerza el dispositivo BLE conectado a la aplicación de Android activa onConnectionStateChange con el estado 8
  • Android Cómo leer las propiedades de BLE Readable Writable Notifiable GATT Características
  • Parámetros de conexión de baja energía de Bluetooth para Android, iOS y Win8
  • ¿Cómo usar el perfil de PROXIMITY PROFILE, IMMEDIATE ALERT SERVICE y Find Me Profile en android 4.3 BLE?
  • Android Lollipop 5.0 Bluetooth Low Energy función central de mal rendimiento
  • Android - BLE vinculación programáticamente no funciona en todos CoolPad Nota 3
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.