android - activar - Al cancelar el socket del servidor bluetooth antes de aceptar, todo el proceso muere. ¿Por qué?

bluetooth android studio

Question

Estoy compilando para SDK 10 (2.3.3):

android:minSdkVersion="10"
android:targetSdkVersion="16"

Estoy probando en dos teléfonos inteligentes Sony Ericsson. Uno tiene Android 2.3.7 y el otro 4.0.1.

Estoy usando listenUsingInsecureRfcommWithServiceRecord para abrir un nuevo socket de servidor en bluetooth y escuchar las conexiones.

Si la conexión se acepta con éxito, todo funciona bien. Incluso puedo intentar cancelar el socket del servidor, pero eso no parece molestar al socket de conexión que acaba de crear.

PERO cuando quiero cancelar el socket del servidor antes de haber aceptado cualquier conexión tan pronto como la línea bluetoothServerSocket.close(); se ejecuta toda la actividad se cierra y el proceso muere. Y, además, esta no es una excepción regular que podría manejar.

En realidad, ¡incluso Logcat se cierra! y tengo que ejecutarlo de nuevo rápidamente para captar los errores que puedes ver a continuación:

Zygote D Process 25471 terminated by signal (11)
295 InputDispatcher W channel ''2c2e20a8 com.pligor.test/activities.MainActivity (server)'' ~ Consumer closed input channel or an error occurred. events=0x8
295 InputDispatcher E channel ''2c2e20a8 com.pligor.test/activities.MainActivity (server)'' ~ Channel is unrecoverably broken and will be disposed!
295 dalvikvm D GC_FOR_ALLOC freed 1299K, 21% free 13252K/16583K, paused 93ms
295 InputDispatcher W Attempted to unregister already unregistered input channel ''2c2e20a8 com.pligor.test/activities.MainActivity (server)''
295 BluetoothService D Tracked app 25471 diedType:10
295 BluetoothService D Removing service record 10009 for pid 25471
132 SurfaceFlinger D Release buffer at 0x61c08
295 WindowManager I WINDOW DIED Window{2c2e20a8 com.pligor.test/activities.MainActivity paused=false}
295 ActivityManager I Process com.pligor.test (pid 25471) has died.
295 ActivityManager W Force removing ActivityRecord{2c021800 com.pligor.test/activities.MainActivity}: app died, no saved state
295 WindowManager W Failed looking up window
295 WindowManager W java.lang.IllegalArgumentException: Requested window android.os.BinderProxy@2bf3e798 does not exist
295 WindowManager W at com.android.server.wm.WindowManagerService.windowForClientLocked(WindowManagerService.java:7165)
295 WindowManager W at com.android.server.wm.WindowManagerService.windowForClientLocked(WindowManagerService.java:7156)
295 WindowManager W at com.android.server.wm.WindowState$DeathRecipient.binderDied(WindowState.java:1545)
295 WindowManager W at android.os.BinderProxy.sendDeathNotice(Binder.java:417)
295 WindowManager W at dalvik.system.NativeStart.run(Native Method)
295 WindowManager I WIN DEATH: null
295 BluetoothEventLoop D Property Changed: UUIDs : 11
295 hAdapterStateMachine D BluetoothOn process message: 51
295 InputManagerService W Got RemoteException sending setActive(false) notification to pid 25471 uid 10040

Nota: El proceso terminado por la señal (11) significa falla de segmentación ( http://en.wikipedia.org/wiki/SIGSEGV ).

EDITAR

Creo el socket del servidor Bluetooth usando el siguiente código ( Scala ):

private val bluetoothServerSocket: BluetoothServerSocket = try {
bluetoothAdapter.listenUsingInsecureRfcommWithServiceRecord(MY_SERVICE_NAME_INSE‌​CURE, MY_UUID_INSECURE);
}
catch {
case e: IOException => throw new ServerSocketException;
} 

Utilizo este código para cerrar el socket Bluetooth :

try {
isCancelled = true;
bluetoothServerSocket.close();
} catch {
case e: IOException => throw new NotClosedException;
}

Answer 1

Si cerrar el socket causa tanto daño, ¿por qué no simplemente crear un indicador booleano que se establece en verdadero cuando el usuario está conectado y configurado en falso cuando el usuario se desconecta? luego solo se llama cuando el usuario estuvo conectado anteriormente.

Answer 2

He experimentado un problema similar y la causa raíz del problema fue llamar cerca de un socket más de una vez. Para corregir este problema, envolví mis conectores bluetooth en una clase especial para evitar que se llamara al método de cierre más de una vez.

Tenga en cuenta que el cierre de las transmisiones creadas por un socket bluetooth es capaz de llamar cerca del socket. Lo siguiente resuelve el problema.

public class CloseOnceBluetoothSocket
{
private final BluetoothSocket mSocket;
private boolean mIsClosed;
public CloseOnceBluetoothSocket(BluetoothSocket socket)
{
this.mSocket = socket;
}
public void connect() throws IOException
{
mSocket.connect();
}
public InputStream getInputStream() throws IOException
{
return new FilterInputStream(mSocket.getInputStream()) {
@Override
public void close() throws IOException
{
CloseOnceBluetoothSocket.this.close();
}
};
}
public OutputStream getOutputStream() throws IOException
{
return new FilterOutputStream(mSocket.getOutputStream()) {
@Override
public void close() throws IOException
{
CloseOnceBluetoothSocket.this.close();
}
};
}
public void close() throws IOException
{
synchronized (mSocket) {
if (!mIsClosed) {
mSocket.close();
mIsClosed = true;
}
}
}
}

Answer 3

Creo que he encontrado una solución para este problema. El "Creo" es porque esto aún no se ha probado en muchos dispositivos.

el siguiente código es Scala

Para la solución, aprovecho el método sobrecargado accept (int) que tiene un tiempo de espera excedido

Entonces, tenemos una variable para el estado del ciclo infinito que está viendo debajo

private var toContinue = true;

Simplemente repetimos aceptando en un ciclo while

while (toContinue) {
try {
//this is a blocking call and will only return on a successful connection or an exception, or on timeout
val socket = bluetoothServerSocket.accept(10000); //msec
connectionAccepted(socket);
} catch {
case e: IOException => {
Logger("accepting timed out");
}
}
}

Así que ahora, en lugar de llamar a bluetoothServerSocket.close() , solo estamos configurando variables como falsas

def cancel() {
toContinue = false;
}

El código real es un poco más complejo ya que necesita una función de devolución de llamada para hacer algo a la salida del ciclo while, pero el problema principal se resuelve como se muestra arriba.