При отмене соединения с сервером bluetooth перед принятием, весь процесс умирает. Зачем?
Я собираю для SDK 10 (2.3.3):
android:minSdkVersion="10"
android:targetSdkVersion="16"
Я тестирую два смартфона Sony Ericsson. На нем есть Android 2.3.7, а другой 4.0.1.
Я использую listenUsingInsecureRfcommWithServiceRecord
, чтобы открыть новый серверный сокет на bluetooth и прослушать соединения.
Если соединение успешно принято, все работает нормально. Я даже могу попытаться отменить сокет сервера, но это, похоже, не беспокоит только что созданный соединительный сокет.
НО, когда я хочу отменить серверный сокет, прежде чем принимать какие-либо соединения, как только будет выполняться строка bluetoothServerSocket.close();
, вся активность закрывается и процесс умирает. И кроме того, это не регулярное исключение, с которым я мог бы справиться.
На самом деле даже logcat сам уходит! и я должен быстро выполнить его снова, чтобы захватить ошибки, которые вы можете увидеть ниже:
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 [email protected] 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
Примечание. Процесс, завершенный сигналом (11), означает ошибку сегментации (http://en.wikipedia.org/wiki/SIGSEGV).
ИЗМЕНИТЬ
Я создаю сокет сервера Bluetooth, используя следующий код (Scala
):
private val bluetoothServerSocket: BluetoothServerSocket = try {
bluetoothAdapter.listenUsingInsecureRfcommWithServiceRecord(MY_SERVICE_NAME_INSECURE, MY_UUID_INSECURE);
}
catch {
case e: IOException => throw new ServerSocketException;
}
Я использую этот код для закрытия сокета Bluetooth:
try {
isCancelled = true;
bluetoothServerSocket.close();
} catch {
case e: IOException => throw new NotClosedException;
}
Ответы
Ответ 1
Я думаю, что нашел обходной путь для этой проблемы. "Я думаю", потому что это еще не тестировалось на многих устройствах.
ниже приведен код Scala
Для обходного пути я использую перегруженный метод accept (int), у которого есть тайм-аут
Итак, у нас есть переменная для состояния бесконечного цикла, который вы видите ниже
private var toContinue = true;
Мы просто повторяем прием в цикле 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");
}
}
}
Итак, теперь вместо вызова bluetoothServerSocket.close()
мы просто устанавливаем переменную в false
def cancel() {
toContinue = false;
}
Фактический код немного сложнее, поскольку для выхода из цикла while требуется функция обратного вызова, но основная проблема устранена, как показано выше.
Ответ 2
У меня возникла аналогичная проблема, и основной причиной проблемы явилось обращение к сокету более одного раза. Чтобы исправить эту проблему, я завернул свои сокеты bluetooth в специальном классе, чтобы предотвратить вызов метода close более одного раза.
Имейте в виду, что закрытие потоков, создаваемых гнездом bluetooth, может вызвать закрытие сокета. Следующая проблема решена.
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;
}
}
}
}
Ответ 3
Если закрытие сокета вызывает большой урон, то почему бы просто не создать логический флаг, который установлен на true, когда пользователь подключен и установлен на false, когда пользователь отключается; затем только закрывать вызов, когда пользователь был ранее подключен.