"El recurso compartido Bluetooth ha dejado de funcionar" al realizar LeScan

Tengo un montón de varios teléfonos Android en frente de mí todo el funcionamiento 4.3 / 4.4 y todos parecen estar sufriendo de algún error en Bluetooth. La aplicación que estoy ejecutando es simplemente escaneo de otros dispositivos bluetooth a su alrededor utilizando esta devolución de llamada: http://developer.android.com/reference/android/bluetooth/BluetoothAdapter.LeScanCallback.html

Sólo LogCatting los datos y todavía tiene problemas …

¿Alguien sabe acerca de este error y tiene una solución para ello? Realmente necesito conseguir escaneo de bluetooth estable para una fecha límite que tengo mañana para una demo de mi aplicación …

Gracias.

EDIT: Supuestamente en 4.4.3 (o 4.4.4) esto fue resuelto. (Por supuesto el día de nuestra presentación para el proyecto … no nos hizo bien). El problema principal era el archivo XML que guardaba la pista de las direcciones del mac que crecen sobre el tamaño de 2000 y que se estrellan entonces … un reajuste del sistema despejaría el archivo del xml, solucionando así el problema temporalmente.

Se trata de un error en el código bluetooth Android que no parece tener una resolución en la actualidad. Dado que otras personas siguen encontrando esto también, voy a publicar lo que encontré al rastrear el problema a través de la pila de bluetooth, a pesar de que realmente no se puede aplicar como una resolución a menos que uno está preparado para hacer cambios importantes a AOSP instalar.

Fundamentalmente, el problema es un SIGSEGV en btif_config.c en find_add_node () cuando alloc_node () falla después de escuchar demasiadas direcciones de hardware BTLE únicas.

Parte informativa del seguimiento de la pila

D/BtGatt.btif(22509): btif_gattc_upstreams_evt: Event 4096 D/BtGatt.btif(22509): btif_gattc_add_remote_bdaddr device added idx=1 D/BtGatt.btif(22509): btif_gattc_update_properties BLE device name=beacon len=6 dev_type=2 F/libc (22509): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 22530 (BTIF) I/DEBUG ( 171): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 171): Build fingerprint: 'google/occam/mako:4.4.2/KOT49H/937116:user/release-keys' I/DEBUG ( 171): Revision: '11' I/DEBUG ( 171): pid: 22509, tid: 22530, name: BTIF >>> com.android.bluetooth <<< I/DEBUG ( 171): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000 I/DEBUG ( 171): r0 ffffffff r1 00007d00 r2 00007c60 r3 74c7cf00 I/DEBUG ( 171): r4 74c7cf10 r5 00000000 r6 756f95a8 r7 7503c671 I/DEBUG ( 171): backtrace: I/DEBUG ( 171): #00 pc 0004e68c /system/lib/hw/bluetooth.default.so I/DEBUG ( 171): #01 pc 0004ea65 /system/lib/hw/bluetooth.default.so (btif_config_set+156)

Al desmontar, el código en cuestión es esta serie bastante evidentemente problemática de borrar r5 y luego tratar de desreferenciarlo como un puntero base:

  4e68a: 2500 movs r5, #0 4e68c: 6829 ldr r1, [r5, #0] 4e68e: b919 cbnz r1, 4e698 <btif_gattc_test_command_impl+0x74c> 4e690: 4630 mov r0, r6 4e692: f7dd ef78 blx 2c584 <strdup@plt>

Esto corresponde a la comprobación "if (! Node-> name)" al final de find_add_node ()

 static cfg_node* find_add_node(cfg_node* p, const char* name) { int i = -1; cfg_node* node = NULL; if((i = find_inode(p, name)) < 0) { if(!(node = find_free_node(p))) { int old_size = alloc_node(p, CFG_GROW_SIZE); if(old_size >= 0) { i = GET_NODE_COUNT(old_size); node = &p->child[i]; ADD_CHILD_COUNT(p, 1); } /* else clause to handle failure of alloc_node() is missing here */ } else ADD_CHILD_COUNT(p, 1); } else node = &p->child[i]; if(!node->name) /* this will SIGSEGV if node is still NULL */ node->name = strdup(name); return node; }

Específicamente, no hay otra cláusula para manejar el fallo de alloc_node (), así que cuando eso sucede (presumiblemente debido a quedarse sin almacenamiento después de escuchar demasiadas direcciones de dispositivo) el código se cae e intenta desreferenciar el miembro de nombre del puntero de nodo Sin haberlo configurado nunca a una dirección no nula.

Un reparo presumiblemente necesitaría involucrar:

Manejo sin fallos de este caso de error cuando no se puede asignar un nuevo registro
El rechazo más agresivo de las direcciones escuchadas cuando se escuchan nuevas y el número de registros que se almacenan no es razonable

Alguien acaba de abrir un problema: https://code.google.com/p/android/issues/detail?id=67272 . Cualquier prueba de apoyo debe ir allí y esperamos que Google corrige esto en el próximo lanzamiento.

Esta es probablemente una causa rara, pero tuve este problema al intentar usar un Tono L con mi Galaxy Nexus. He intentado varias soluciones, pero nada funcionó, entonces me acordé de que he instalado una aplicación (en mi teléfono con raíces) que habilitó Bluetooth LE (Normalmente 4.3 en Galaxy Nexus no tiene acceso). Una vez que desinstalé los archivos de la aplicación instalada, parece estar funcionando bien.

Por lo tanto, si la cosa no está funcionando todavía .. pregúntese si ha hecho cualquier cosa personalizada en el teléfono que podría ser conflictivo.

Solución que funcionó para mi S4 (i9500): Después de instalar una ROM personalizada para Android 5.1.1, empecé a hacer frente a este problema de 'Bluetooth detenido'. Desde que mi teléfono estaba enraizado, he instalado la aplicación 'Root Uninstaller' y los servicios FROZE bluetooth. No he tenido ningún problema después de eso. Pero de nuevo no estoy seguro si mi bluetooth está funcionando correctamente. Es sólo que ya no tengo esas molestas ventanas emergentes. Espero que esto ayude a alguien!