android - tutorial - "La condivisione Bluetooth ha smesso di funzionare" durante l'esecuzione di LeScan
up button in toolbar android (3)
Ho davanti a me un sacco di vari telefoni Android tutti in esecuzione 4.3 / 4.4 e tutti sembrano soffrire di qualche bug in Bluetooth. L'app che sto utilizzando è semplicemente la scansione di altri dispositivi bluetooth che lo circondano utilizzando questo callback: http://developer.android.com/reference/android/bluetooth/BluetoothAdapter.LeScanCallback.html
Basta registrare i dati e avere ancora problemi ...
Qualcuno sa di questo bug e ha una soluzione per questo? Ho davvero bisogno di ottenere la scansione bluetooth stabile per una scadenza che ho domani per una demo della mia applicazione ...
Grazie.
EDIT: Presumibilmente in 4.4.3 (o 4.4.4) questo è stato risolto. (Ovviamente il giorno della nostra presentazione per il progetto ... non ci ha fatto bene). Il problema principale era il file XML che teneva traccia degli indirizzi mac che crescevano oltre la dimensione del 2000 e poi si bloccavano ... un reset del sistema avrebbe cancellato il file xml, risolvendo così il problema temporaneamente.
https://code.i-harness.com
Questo è un bug nel codice bluetooth Android che al momento non sembra avere una risoluzione. Dato che anche gli altri continuano a trovarlo, inserirò ciò che ho trovato durante il tracciamento del problema attraverso lo stack bluetooth, anche se non può essere applicato come una risoluzione a meno che non si sia pronti a apportare modifiche importanti a un sistema basato su AOSP. installare.
Fondamentalmente, il problema è un SIGSEGV in btif_config.c in find_add_node () quando alloc_node () fallisce dopo aver ascoltato troppi indirizzi hardware BTLE univoci.
Parte informativa della traccia dello stack
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)
Disassemblando, il codice in questione è questa serie piuttosto ovvia di clearing r5 e quindi si tenta di de-referenziarlo come puntatore di 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 <[email protected]>
Questo corrisponde al controllo "if (! Node-> name)" alla fine di 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;
}
In particolare, non esiste alcuna clausola else per gestire il fallimento di alloc_node (), quindi quando ciò accade (presumibilmente a causa di esaurimento della memoria dopo aver ascoltato troppi indirizzi di dispositivo) il codice cade e tenta di dereferenziare il membro nome del puntatore del nodo senza averlo mai impostato su un indirizzo non nullo.
Una correzione dovrebbe presumibilmente coinvolgere:
gestione non crash di questo caso di errore quando non è possibile allocare un nuovo record
abbandono più aggressivo degli indirizzi ascoltati in passato quando i nuovi continuano a essere ascoltati e il numero di record memorizzati diventa irragionevole
Qualcuno ha appena aperto un problema: https://code.google.com/p/android/issues/detail?id=67272 . Qualsiasi prova a supporto dovrebbe andare lì e si spera che Google lo risolva nella prossima versione.
Correzione che ha funzionato per il mio S4 (i9500): dopo aver installato una ROM personalizzata per Android 5.1.1, ho iniziato ad affrontare questo problema "Bluetooth interrotto". Poiché il mio telefono era root, ho installato l'app "Root Uninstaller" e i servizi Bluetooth FROZE. Non ho avuto problemi dopo. Ma ancora non sono sicuro che il mio bluetooth funzioni correttamente. È solo che non ho più quei fastidiosi pop-up. Spero che questo aiuti qualcuno!