Bluetooth на 2.0+ - PullRequest
       13

Bluetooth на 2.0+

1 голос
/ 23 апреля 2010

Я занимаюсь разработкой bluetooth для подключения к ПК.Я в основном использовал BTChatExample и изменил UUID на стандартный SPP-профиль ПК.

  1. Попытка закрыть приложение bluetooth во время блокировки чтения, закрытие сокета Bluetooth оставит Bluetoothстек в непригодном для использования состоянии.Это может быть исправлено только путем отключения и включения Bluetooth и перезапуска приложения.Проверяя logcat, вы можете увидеть, что некоторые из внутренних методов дают сбой, оставляя открытый порт.Любая информация по этому поводу?

  2. Прежде всего, есть разногласия по поводу того, как реализован bluetooth в N1 и HTC Legend / Desire под управлением 2.1, знаете ли вы что-нибудь об этом?*

  3. Соединение не на 100% надежно, иногда я получаю предупреждение, говорящее ~PortSystemContext init: FAILED.Это делает Bluetooth непригодным для использования, и требуется перезапуск.

  4. Прав ли я, полагая, что SPP - единственный профиль, поддерживаемый для использования с API-интерфейсами?Об этом говорится в документации по адаптеру Bluetooth.

Я хотел бы обсудить проблемы с Bluetooth с разработчиком и устранить эти ошибки, чтобы Android мог иметь надлежащую надлежащую поддержку Bluetooth, которую он заслуживает.

Ответы [ 3 ]

2 голосов
/ 23 апреля 2010

Закрытие сокета в одном потоке во время блокирующего чтения, безусловно, должно привести к возвращению чтения (с помощью IOException) и не должно оставлять стек в «плохом состоянии». Это поведение на Droid и Nexus.

Я говорил непосредственно с оригинальным постером, и он наблюдал эту проблему в HTC Legend и HTC Desire. Похоже, что они не реализуют API правильно. Я поднимаю вопрос с ними.

Вы правы, что SPP / RFCOMM - единственный профиль, который предназначен для использования с API. SPP / RFCOMM предоставляет вам потоковый сокет, который подходит для многих случаев использования.

На данный момент я рекомендую разработку BT для Nexus One / Motorola Droid, которые считаются «эталонными» реализациями Bluetooth API.

1 голос
/ 17 мая 2010

Могу ли я предложить вам не выполнять блокировку вызовов read(), если вы сначала не проверили наличие данных, готовых для чтения, с помощью inputstream.available(), который возвращает целое число, указывающее, сколько байтов ожидает во входном буфере.

    long timeouttime = gettimeinseconds() + 2;
    String response = "";

    while (gettimeinseconds() < timeouttime) {
      if (inputstream.available() > 0)
          response = response + inputstream.read();
      } else {
          Thread.sleep(100); // sleep to slow down the while() loop. 
      }
    }
return response;

Это просто псевдокод, и он упрощен. Суть в том, что мы не выполняем никаких блокирующих вызовов (read()), если не уверены, что они сразу же вернутся незамедлительно.

Кроме того, я настоятельно рекомендую использовать BufferedInputStream вместо стандартного InputStream.

0 голосов
/ 07 июля 2010

Кто-нибудь может решить эту проблему?

Я пробую следующий код:

// Keep listening to the InputStream while connected
while (!isInterrupted)
{
    try
    {
        //Clear buffer
        buffer = new byte[1024];

        // Read from the InputStream
        if (mmInStream != null && mmInStream.available() > 0)
        {
            if (isInterrupted)
                break;

            bytes = mmInStream.read(buffer);

            // Send the obtained bytes to the UI Activity
            mHandler.obtainMessage(Act_Main.MESSAGE_READ, bytes, -1, buffer).sendToTarget();
        }
        else
        {
            try
            {
                synchronized (this)
                {
                    this.wait(100);
                }

                if (isInterrupted)
                    break;
            }
            catch(InterruptedException ex)
            {
                Log.e(TAG, "WAIT_EXCEPTION:"+ ex.getMessage());
            }
        }
    }
    catch(Exception ex)
    {
        Log.e(TAG, "disconnected", ex);
        connectionLost();
        break;
    }
}

И я изменил логическое значение isInterrupted в методе cancel(). Вот мой stop() метод:

/**
 * Stop all threads
 */
public synchronized void stop()
{
    isStop = true ;

    if (D)
        Log.d(TAG, "stop");

    if(mConnectThread != null)
    {
        mConnectThread.cancel();
        mConnectThread = null;
    }

    if(mConnectedThread != null)
    {
        mConnectedThread.cancel();
        mConnectedThread = null;
    }

    setState(STATE_NONE);
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...