2011-03-08 18 views
12

Utilicé el ejemplo de Bluetooth Chat como punto de partida para implementar una conexión BT desde mi teléfono a un dispositivo incrustado. Puedo conectarme con éxito al dispositivo, pero una vez que se establece la conexión, Logcat está siendo invadido por una gran cantidad de registros. No vi este tipo de registro la primera vez que uso el teléfono BT de la aplicación de chat.Android Bluetooth logging llenando logcat

Esto es lo que se repite una y otra vez. Básicamente hace el logcat inutilizable. Hasta ahora no he encontrado una forma de configurar el registro o por qué está registrando tanto. Cualquier idea sería apreciada.

03-08 14:29:04.941: DEBUG/BluetoothSocket.cpp(11422): availableNative 
03-08 14:29:04.957: DEBUG/BluetoothSocket(11422): available 
03-08 14:29:04.957: DEBUG/BluetoothSocket.cpp(11422): availableNative 
03-08 14:29:04.971: DEBUG/BluetoothSocket(11422): available 
03-08 14:29:04.976: DEBUG/BluetoothSocket.cpp(11422): availableNative 
03-08 14:29:04.989: DEBUG/BluetoothSocket(11422): available 
03-08 14:29:04.991: DEBUG/BluetoothSocket.cpp(11422): availableNative 
03-08 14:29:05.016: DEBUG/BluetoothSocket(11422): available 
03-08 14:29:05.016: DEBUG/BluetoothSocket.cpp(11422): availableNative 
03-08 14:29:05.034: DEBUG/BluetoothSocket(11422): available 
03-08 14:29:05.036: DEBUG/BluetoothSocket.cpp(11422): availableNative 
03-08 14:29:05.050: DEBUG/BluetoothSocket(11422): available 
03-08 14:29:05.051: DEBUG/BluetoothSocket.cpp(11422): availableNative 
03-08 14:29:05.066: DEBUG/BluetoothSocket(11422): available 
03-08 14:29:05.066: DEBUG/BluetoothSocket.cpp(11422): availableNative 
03-08 14:29:05.081: DEBUG/BluetoothSocket(11422): available 
03-08 14:29:05.081: DEBUG/BluetoothSocket.cpp(11422): availableNative 
03-08 14:29:05.086: DEBUG/(2419): jw_if_rfcomm_cl_cback: jw_if_rfcomm_cl_cback event=BTA_JV_RFCOMM_READ_EVT 
03-08 14:29:05.086: DEBUG/(2419): jv_forward_data_to_jni: BTA_JV_RFCOMM_DATA_IND_EVT bta hdl 2 
03-08 14:29:05.086: DEBUG/(2419): bts_log_tstamps_us: [update stats] ts 1263504, bta hdl 2, diff 01263504, tx_q 1 (1), rx_q 0 (0) 
03-08 14:29:05.086: DEBUG/BLZ20_WRAPPER(11422): blz20_wrp_poll: transp poll : (fd 41) returned r_ev [POLLIN ] (0x1) 
03-08 14:29:05.086: DEBUG/BLZ20_WRAPPER(11422): blz20_wrp_poll: return 1 
03-08 14:29:05.086: DEBUG/BLZ20_WRAPPER(11422): blz20_wrp_read: read 122 bytes out of 1024 on fd 41 
03-08 14:29:05.101: DEBUG/BluetoothSocket(11422): read 
03-08 14:29:05.101: DEBUG/BluetoothSocket.cpp(11422): readNative 
03-08 14:29:05.101: DEBUG/ASOCKWRP(11422): asocket_read 
03-08 14:29:05.106: INFO/BLZ20_WRAPPER(11422): blz20_wrp_poll: nfds 2, timeout -1 ms 
03-08 14:29:05.117: DEBUG/BluetoothSocket(11422): available 
03-08 14:29:05.121: DEBUG/BluetoothSocket.cpp(11422): availableNative 

Respuesta

-1

En DDMS puede filtrar las cosas mediante el uso de los depuración, información, errores, botones de advertencia y también puede crear un filtro especial para mostrar sólo las cosas que le interesan. No creo que haya ningún configuración bluetooth para desactivar el registro que puede usar.

+1

temía que iba a ser la respuesta. Gracias – bursk

+0

Seguimiento: creo que también podría tener un problema con el teléfono. No obtengo el registro excesivo cuando ejecuto el código en un teléfono G1. Tanto mi Galaxy S como la G1 están ejecutando la actualización de Android 2.1 1. – bursk

+5

He visto el mismo problema. Está limitado a dispositivos Samsung. Deben desactivar el spam de depuración antes del envío. – user48956

3

Esto debe ser un error, y una seria uno:

  • ya sea Logcat sólo muestra esta impresión de depuración veces - aunque mi código siempre viene a través de ella

  • o el chip Bluetooth corre suelta veces ...(más como).

Simplemente girando el nivel de registro para depurar desde verbosa voluntad no cambia el hecho de que hay una enorme cantidad de datos transferidos a Logcat, el bloqueo de todos los registros normales ...

4

Después de jugar con mi Arduino Board + Bluetooth-Adapter Intenté implementar el código Bluetooth desde MATT BELL'S BLOG. El problema es el siguiente código:

//final Handler handler = new Handler(); 
workerThread = new Thread(new Runnable() 
{ 
    public void run() 
    { 
     while(!Thread.currentThread().isInterrupted() && !stopWorker) 
     { 
      try { 
       int bytesAvailable = mmInputStream.available(); 
       if(bytesAvailable > 0) 
       { 
        //Log.d(TAG,"bytesAvailable: "+bytesAvailable + " readBufferPosition: "+readBufferPosition); 
        byte[] packetBytes = new byte[bytesAvailable]; 
        mmInputStream.read(packetBytes); 

        for(int i=0;i<bytesAvailable;i++) 
        { 
         byte delimiter = 0x0A;  // /n bzw. LF 
         byte b = packetBytes[i]; 
         if(b == delimiter) 
         { 
          byte[] encodedBytes = new byte[readBufferPosition]; 
          System.arraycopy(readBuffer, 0, encodedBytes, 0, encodedBytes.length); 
          final String data = new String(encodedBytes, "US-ASCII"); 
          //final String data = new String(readBuffer); 
          readBufferPosition = 0; 

          Log.d(TAG,""+data); 

//           //The variable data now contains our full command 
//           handler.post(new Runnable() 
//           { 
//            public void run() 
//            { 
//             //myLabel.setText(data); 
//             Log.d(TAG,""+data); 
//            } 
//           }); 
         } 
         else 
         { 
          readBuffer[readBufferPosition++] = b; 
         } 
        } 
       } 
      } catch (Exception e) { 
       Log.d(TAG,"Exeption 2: "+e.getMessage()); 
       stopWorker = true; 
      } 
     } 
    } 
}); 
workerThread.start(); 

llamando a los siguientes resultados de la función en enorme spam en LogCat

int bytesAvailable = mmInputStream.available(); 

LogCat:

PS: Las marcas de tiempo son, de hecho, de la versión fija. No uso de la corrección se tendrá como resultado un spam cada 5ms effectivly bloqueando toda mi registro de

03-17 18:43:06.615: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:06.715: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:06.820: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:06.920: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:07.020: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:07.120: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:07.220: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:07.320: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:07.420: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:07.520: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:07.620: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:07.725: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:07.825: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:07.925: VERBOSE/BluetoothSocket.cpp(8871): availableNative 
03-17 18:43:08.025: VERBOSE/BluetoothSocket.cpp(8871): availableNative 

Mi solución actual es añadir el siguiente código al final del bucle mientras resulta en la reducción del correo no deseado.

try { 
Thread.sleep(100); 
} catch (Exception e) { 
Log.d(TAG,"Exception Thread.sleep()"); 
} 

Espero que esto ayude a algunas personas con problemas similares.

Editar: Actualmente tuve que reducir el sueño-temporizador de 10 ms bam .. SPAM

03-18 15:50:18.470: VERBOSE/BluetoothSocket.cpp(3482): availableNative 
03-18 15:50:18.470: VERBOSE/BluetoothSocket.cpp(3482): availableNative 
03-18 15:50:18.470: VERBOSE/BluetoothSocket.cpp(3482): availableNative 
03-18 15:50:18.470: VERBOSE/BluetoothSocket.cpp(3482): availableNative 
03-18 15:50:18.470: VERBOSE/BluetoothSocket.cpp(3482): availableNative 
03-18 15:50:18.470: VERBOSE/BluetoothSocket.cpp(3482): availableNative 
03-18 15:50:18.470: VERBOSE/BluetoothSocket.cpp(3482): availableNative 
03-18 15:50:18.470: VERBOSE/BluetoothSocket.cpp(3482): availableNative 
03-18 15:50:18.470: VERBOSE/BluetoothSocket.cpp(3482): availableNative 
03-18 15:50:18.470: VERBOSE/BluetoothSocket.cpp(3482): availableNative 
+0

¿Encontraste alguna forma de solucionar esto? Estoy muy luchando por el problema exacto. – skygeek

1

"avaliableNative" tiene una prioridad detallado. Para deshacerse del mensaje (y todos los mensajes detallados también) utilice un parámetro "*: D" como último parámetro de logcat. Se puede lograr algo similar en Eclipse utilizando la prioridad de "depuración" en el cuadro combinado al lado del ícono del disquete.

2

Acabo de tropezar con esto: después de 3 años esta obstrucción de registro sigue presente, al menos en mi Samsung GT-I8190 (4.1.2).

El culpable es mmInputStream.available()

Una forma de evitar esto es no usarlo available() método. En lugar de:

int bytesAvailable = mmInputStream.available(); 

if(bytesAvailable > 0) 
{... 

Usted podría utilizar algo así como el código de abajo a la obstrucción de registro awoid ...

int i = -1; 
while((i=mmInputStream.read())!=-1) 
{       
    char c=(char)i; 

    // you can do your buffering here... 
    Log.i("readBT","have char: "+c); 
} 

Este código de abajo también funciona en los teléfonos con este error desagradable. Probablemente se debe revisar aunque ya que es sólo un rápido & solución sucia:

void beginListenForData() 
    { 
     final Handler handler = new Handler(); 
     final byte delimiter = 10; //This is the ASCII code for a newline character 

     stopWorker = false; 
     readBufferPosition = 0; 
     readBuffer = new byte[1024]; 
     workerThread = new Thread(new Runnable() 
     { 
      public void run() 
      {     
       while(!Thread.currentThread().isInterrupted() && !stopWorker) 
       { 
        try 
        { 
         int i = -1; 
         while((i=mmInputStream.read())!=-1) 
         { 
          byte b=(byte)i; 

          Log.i("readBT","have byte: " + b); 

          if ((readBufferPosition >= 1023) || (b == delimiter)) 
          { 
           byte[] encodedBytes = new byte[readBufferPosition]; 
           System.arraycopy(readBuffer, 0, encodedBytes, 0, encodedBytes.length); 
           final String data = new String(encodedBytes, "UTF-8"); 
           readBufferPosition = 0; 

           handler.post(new Runnable() 
           { 
            public void run() 
            { 
             myLabel.setText(data); 
            } 
           });        
          } 
          else 
          { 
           readBuffer[readBufferPosition++] = b; 
          }       
         }      
        } 
        catch (IOException ex) 
        { 
         stopWorker = true; 
        } 
       } 
      } 
     }); 

     workerThread.start(); 
    } 
+1

Los métodos de lectura también tienen un problema de registro (doble): 'D/BluetoothSocket: leer en: [email protected] len: 1 D/BluetoothSocket: leer: [email protected] ret: 1' – Florian