Android InputStream 丢弃前两个字节(修改后的 BluetoothChat) [英] Android InputStream dropping first two bytes (modified BluetoothChat)

查看:22
本文介绍了Android InputStream 丢弃前两个字节(修改后的 BluetoothChat)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我使用 BluetoothChat 示例中的代码从蓝牙秤发送和接收字节数据.秤从设备接收命令,然后发回一个字节数组.{2,198,48,48,48,48,199,3}在我们的通信协议中,2 = STX,198 = 数据包开始,199 = 数据包结束,3 = ETX.

I've used code from BluetoothChat example to send and receive byte data from a Bluetooth Scale. The scale receives the command from the device, then sends back a byte array. {2,198,48,48,48,48,199,3} The 2 = STX, and the 198 = packet start, and 199 = packet end, and 3 = ETX in our comms protocol.

一切正常,除了 BluetoothChatService.java 中的以下代码反应奇怪,因为它丢弃了前两个字节.

All works just fine, except that the following code in the BluetoothChatService.java reacts strangely in that it drops the first two bytes.

/**
     * This thread runs during a connection with a remote device.
     * It handles all incoming and outgoing transmissions.
     */
    private class ConnectedThread extends Thread {
        private final BluetoothSocket mmSocket;
        private final InputStream mmInStream;
        private final OutputStream mmOutStream;

        public ConnectedThread(BluetoothSocket socket, String socketType) {
            Log.d(TAG, "create ConnectedThread: " + socketType);
            mmSocket = socket;
            InputStream tmpIn = null;
            OutputStream tmpOut = null;

            // Get the BluetoothSocket input and output streams
            try {
                tmpIn = socket.getInputStream();
                tmpOut = socket.getOutputStream();
            } catch (IOException e) {
                Log.e(TAG, "temp sockets not created", e);
            }

            mmInStream = tmpIn;
            mmOutStream = tmpOut;
        }

        public void run() {
            Log.i(TAG, "BEGIN mConnectedThread");
            final byte[] buffer = new byte[1024];
            int bytes;

            // Keep listening to the InputStream while connected
            while (true) {
                try {
                    // Read from the InputStream
                    bytes = mmInStream.read(buffer);

                    // Send the obtained bytes to the UI Activity
                    mHandler.obtainMessage(BluetoothChat.MESSAGE_READ, bytes, -1, buffer)
                            .sendToTarget();
                } catch (IOException e) {
                    Log.e(TAG, "disconnected", e);
                    connectionLost();
                    // Start the service over to restart listening mode
                    BluetoothChatService.this.start();
                    break;
                }
            }
        }

我对以下代码段有特别的疑问:

I have a problem specifically with the following section of code:

 bytes = mmInStream.read(buffer);

                    // Send the obtained bytes to the UI Activity
                    mHandler.obtainMessage(BluetoothChat.MESSAGE_READ, bytes, -1, buffer)
                            .sendToTarget();

调试时,在执行之前查看mmInStream.read(buffer)中buffer的内容,buffer中包含的是秤设备发回的正确数据,即:

When debugging, and looking at the content of buffer in mmInStream.read(buffer) before it is executed, the buffer contains the correct data that was sent back by the scale device ie:

{2,198,48,48,48,48,48,199,3}

但是一旦代码被单步执行,缓冲区的前两个字节就会被剥离,现在它错误地包含:

but once the code has been stepped, the first two bytes of the buffer are stripped off, and it now erroneously contains:

{48,48,48,48,48,199,3}

这是消息处理程序最终传递给活动的内容.

and it is this that the message handler then finally passes on to the activity.

为了更清楚,我必须补充一点,秤发送的字节流是 00 到 FF 范围内的十六进制字符.出于某种奇怪的原因,调试器中的字符串实际上是这样的:

For more clarity, I must add, that the stream of bytes being sent by the scale are Hex characters in the range 00 to FF. For some strange reason the string actually looks like this in the debugger:

{2,-58,48,48,48,48,48,-57,3}

然后丢弃 2,-58.

and then the 2,-58 are dropped.

我注意到当我通过套接字发送一个字节数组时,我需要执行以下操作:

I noticed that when I send a byte array over a socket, I need to do the following:

byte[] sendBytes = {2,(byte)198,48,48,48,48,48,(byte)199,3}

当这个数组的内容被调试时,它会给出{2,-58,48,48,48,48,48,-57,3}

When the content of this array is debugged it will give {2,-58,48,48,48,48,48,-57,3}

请理解,我是 Android - java 的新手,还有很多东西要学.所有帮助将不胜感激.谢谢阿德里安

Please understand that I am new to Android - java, and have a lot to learn. All help will be appreciated. Thanks Adrian

我添加了 log.i 条目,以便根据 Radu 的建议更好地了解正在发生的事情.看来我通过蓝牙将数据写入我的设备后,它会响应,我们出于某种原因只读取前两个字节,然后将它们发送到消息处理程序,然后读取从设备发送的其余数据包,然后发送这关闭消息处理程序,但在处理程序甚至第一次响应之前,缓冲区已经被覆盖,因此当处理程序尝试读取前两个字节时,它正在读取响应的第 3 个和第 4 个字节数据包,然后立即再次响应并从第 3-17 位读取整个数据包.所以如果我可以简单地说......消息处理程序只会在它被覆盖后响应发送的缓冲区.查看下面的日志:

I have added log.i entries to better understand what is happening based on Radu's advice. It appears that after I write data to my device over Bluetooth, it responds, and we read for some reason only first two bytes, then send these to the message handler, then read the rest of the packet sent from the device, and then send this off to the message handler, but before the handler has even responded the first time, the buffer has already been overwritten, thus by the time the handler tries to read the first two bytes, it is reading the 3rd and 4th bytes of the response packet, then immediately responds again and reads the entire packet from 3-17th position. So if I can put it simply .. the message handler only responds to the sent buffer after it has been overwritten. See the log below:

09-05 13:16:52.093: V/BluetoothSocket.cpp(11279): writeNative
09-05 13:16:52.118: I/IN_BUFFER(11279): The entire buffer after read stream into buffer: 2 
09-05 13:16:52.118: I/IN_BUF_AFTER(11279): 2 
09-05 13:16:52.118: I/IN_BUF_AFTER(11279): -58 
09-05 13:16:52.118: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:52.118: I/IN_BUF_AFTER(11279): 0 
...truncated to save space ... 
09-05 13:16:52.163: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:52.163: I/IN_BUFFER(11279): We now send to handler.
09-05 13:16:52.168: I/IN_BUFFER(11279): Read Stream into Buffer:
09-05 13:16:52.168: V/BluetoothSocket.cpp(11279): readNative
09-05 13:16:52.168: I/IN_BUFFER(11279): The entire buffer after read stream into buffer: 17 
09-05 13:16:52.168: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.168: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.168: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.173: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.173: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.173: I/IN_BUF_AFTER(11279): 44 
09-05 13:16:52.173: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.178: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.178: I/IN_BUF_AFTER(11279): 49 
09-05 13:16:52.178: I/IN_BUF_AFTER(11279): 50 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 44 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 85 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 13 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): -57 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 3 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 6 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 0 
...truncated to save space ... 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:52.188: I/IN_BUFFER(11279): We now send to handler.
09-05 13:16:52.193: I/IN_BUFFER(11279): Read Stream into Buffer:
09-05 13:16:52.208: V/BluetoothSocket.cpp(11279): readNative
09-05 13:16:52.208: I/MESSAGE_READ(11279): I am reading 2 bytes
09-05 13:16:52.208: I/Content(11279): The entire array:
09-05 13:16:52.208: I/some hardcoded tag(11279): 0 
09-05 13:16:52.208: I/some hardcoded tag(11279): 0 
09-05 13:16:52.273: I/MESSAGE_READ(11279): I am reading 17 bytes
09-05 13:16:52.273: I/Content(11279): The entire array:
09-05 13:16:52.273: I/some hardcoded tag(11279): 0 
...truncated to save space ... 
09-05 13:16:52.283: I/some hardcoded tag(11279): 0 
09-05 13:16:52.283: I/some hardcoded tag(11279): 0 
09-05 13:16:54.528: V/BluetoothSocket.cpp(11279): writeNative
09-05 13:16:54.553: I/IN_BUFFER(11279): The entire buffer after read stream into buffer: 2 
09-05 13:16:54.553: I/IN_BUF_AFTER(11279): 2 
09-05 13:16:54.553: I/IN_BUF_AFTER(11279): -58 
09-05 13:16:54.558: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:54.558: I/IN_BUF_AFTER(11279): 0 
...truncated to save space ... 
09-05 13:16:54.618: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:54.618: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:54.618: I/IN_BUFFER(11279): We now send to handler.
09-05 13:16:54.618: I/IN_BUFFER(11279): Read Stream into Buffer:
09-05 13:16:54.618: V/BluetoothSocket.cpp(11279): readNative
09-05 13:16:54.623: I/IN_BUFFER(11279): The entire buffer after read stream into buffer: 17 
09-05 13:16:54.623: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.623: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.623: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.623: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.628: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.628: I/IN_BUF_AFTER(11279): 44 
09-05 13:16:54.628: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.628: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.633: I/IN_BUF_AFTER(11279): 49 
09-05 13:16:54.633: I/IN_BUF_AFTER(11279): 50 
09-05 13:16:54.638: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.638: I/IN_BUF_AFTER(11279): 44 
09-05 13:16:54.638: I/IN_BUF_AFTER(11279): 85 
09-05 13:16:54.638: I/IN_BUF_AFTER(11279): 13 
09-05 13:16:54.638: I/IN_BUF_AFTER(11279): -57 
09-05 13:16:54.648: I/IN_BUF_AFTER(11279): 3 
09-05 13:16:54.648: I/IN_BUF_AFTER(11279): 6 
09-05 13:16:54.648: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:54.648: I/IN_BUF_AFTER(11279): 0 
...truncated to save space ... 
09-05 13:16:54.653: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:54.653: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:54.653: I/IN_BUFFER(11279): We now send to handler.
09-05 13:16:54.653: I/IN_BUFFER(11279): Read Stream into Buffer:
09-05 13:16:54.653: V/BluetoothSocket.cpp(11279): readNative
09-05 13:16:54.658: I/MESSAGE_READ(11279): I am reading 2 bytes
09-05 13:16:54.658: I/Content(11279): The entire array:
09-05 13:16:54.658: I/some hardcoded tag(11279): 0 
09-05 13:16:54.663: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/MESSAGE_READ(11279): I am reading 17 bytes
09-05 13:16:54.723: I/Content(11279): The entire array:
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.728: I/some hardcoded tag(11279): 0 
09-05 13:16:54.728: I/some hardcoded tag(11279): 0 
09-05 13:16:54.728: I/some hardcoded tag(11279): 0 

我的新代码在读入最新流之前也将缓冲区重置为 0,因此消息处理程序只看到 0,在我这样做之前,日志显示如下:

My new code also resets the buffer to 0 before reading in the latest stream, thus the message handler only seeing 0, before I did this the log appeared as follows:

09-05 13:06:20.508: V/BluetoothSocket.cpp(10176): writeNative
09-05 13:06:20.533: I/IN_BUFFER(10176): The entire buffer after read stream into buffer: 2 
09-05 13:06:20.533: I/IN_BUF_AFTER(10176): 2 
09-05 13:06:20.533: I/IN_BUF_AFTER(10176): -58 
09-05 13:06:20.533: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.533: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.538: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.538: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.548: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.548: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.548: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.553: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.553: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.573: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.573: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.573: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.573: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.573: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.578: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.578: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.578: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.578: I/IN_BUFFER(10176): We now send to handler.
09-05 13:06:20.578: I/IN_BUFFER(10176): Read Stream into Buffer:
09-05 13:06:20.578: V/BluetoothSocket.cpp(10176): readNative
09-05 13:06:20.578: I/IN_BUFFER(10176): The entire buffer after read stream into buffer: 17 
09-05 13:06:20.578: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.578: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.583: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.583: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.583: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 44 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 49 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 51 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 44 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 85 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 13 
09-05 13:06:20.598: I/IN_BUF_AFTER(10176): -57 
09-05 13:06:20.598: I/IN_BUF_AFTER(10176): 3 
09-05 13:06:20.613: I/IN_BUF_AFTER(10176): 6 
09-05 13:06:20.613: I/IN_BUF_AFTER(10176): 0 
...truncated to save space ... 
09-05 13:06:20.623: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.623: I/IN_BUFFER(10176): We now send to handler.
09-05 13:06:20.623: I/IN_BUFFER(10176): Read Stream into Buffer:
09-05 13:06:20.623: V/BluetoothSocket.cpp(10176): readNative
09-05 13:06:20.628: I/MESSAGE_READ(10176): I am reading 2 bytes
09-05 13:06:20.628: I/Content(10176): The entire array:
09-05 13:06:20.628: I/some hardcoded tag(10176): 48 
09-05 13:06:20.628: I/some hardcoded tag(10176): 48 
09-05 13:06:20.688: I/MESSAGE_READ(10176): I am reading 17 bytes
09-05 13:06:20.688: I/Content(10176): The entire array:
09-05 13:06:20.688: I/some hardcoded tag(10176): 48 
09-05 13:06:20.688: I/some hardcoded tag(10176): 48 
09-05 13:06:20.688: I/some hardcoded tag(10176): 48 
09-05 13:06:20.688: I/some hardcoded tag(10176): 48 
09-05 13:06:20.688: I/some hardcoded tag(10176): 48 
09-05 13:06:20.688: I/some hardcoded tag(10176): 44 
09-05 13:06:20.688: I/some hardcoded tag(10176): 48 
09-05 13:06:20.693: I/some hardcoded tag(10176): 48 
09-05 13:06:20.693: I/some hardcoded tag(10176): 49 
09-05 13:06:20.693: I/some hardcoded tag(10176): 51 
09-05 13:06:20.693: I/some hardcoded tag(10176): 48 
09-05 13:06:20.693: I/some hardcoded tag(10176): 44 
09-05 13:06:20.693: I/some hardcoded tag(10176): 85 
09-05 13:06:20.693: I/some hardcoded tag(10176): 13 
09-05 13:06:20.693: I/some hardcoded tag(10176): -57 
09-05 13:06:20.693: I/some hardcoded tag(10176): 3 
09-05 13:06:20.693: I/some hardcoded tag(10176): 6 
09-05 13:06:21.788: V/BluetoothSocket.cpp(10176): writeNative
09-05 13:06:21.803: I/IN_BUFFER(10176): The entire buffer after read stream into buffer: 2 
09-05 13:06:21.803: I/IN_BUF_AFTER(10176): 2 
09-05 13:06:21.803: I/IN_BUF_AFTER(10176): -58 
09-05 13:06:21.803: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.803: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.808: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.808: I/IN_BUF_AFTER(10176): 44 
09-05 13:06:21.818: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.818: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.818: I/IN_BUF_AFTER(10176): 49 
09-05 13:06:21.823: I/IN_BUF_AFTER(10176): 51 
09-05 13:06:21.823: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.828: I/IN_BUF_AFTER(10176): 44 
09-05 13:06:21.828: I/IN_BUF_AFTER(10176): 85 
09-05 13:06:21.833: I/IN_BUF_AFTER(10176): 13 
09-05 13:06:21.848: I/IN_BUF_AFTER(10176): -57 
09-05 13:06:21.848: I/IN_BUF_AFTER(10176): 3 
09-05 13:06:21.848: I/IN_BUF_AFTER(10176): 6 
09-05 13:06:21.853: I/IN_BUF_AFTER(10176): 0 
...truncated to save space ... 
09-05 13:06:21.853: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:21.853: I/IN_BUFFER(10176): We now send to handler.
09-05 13:06:21.858: I/IN_BUFFER(10176): Read Stream into Buffer:
09-05 13:06:21.858: V/BluetoothSocket.cpp(10176): readNative
09-05 13:06:21.858: I/IN_BUFFER(10176): The entire buffer after read stream into buffer: 17 
09-05 13:06:21.858: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.863: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.863: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.863: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.863: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.863: I/IN_BUF_AFTER(10176): 44 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 49 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 51 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 44 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 85 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 13 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): -57 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 3 
09-05 13:06:21.873: I/IN_BUF_AFTER(10176): 6 
09-05 13:06:21.873: I/IN_BUF_AFTER(10176): 0 
...truncated to save space ...
09-05 13:06:21.893: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:21.893: I/IN_BUFFER(10176): We now send to handler.
09-05 13:06:21.893: I/IN_BUFFER(10176): Read Stream into Buffer:
09-05 13:06:21.898: V/BluetoothSocket.cpp(10176): readNative
09-05 13:06:21.903: I/MESSAGE_READ(10176): I am reading 2 bytes
09-05 13:06:21.903: I/Content(10176): The entire array:
09-05 13:06:21.903: I/some hardcoded tag(10176): 48 
09-05 13:06:21.903: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/MESSAGE_READ(10176): I am reading 17 bytes
09-05 13:06:21.958: I/Content(10176): The entire array:
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 44 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 49 
09-05 13:06:21.958: I/some hardcoded tag(10176): 51 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 44 
09-05 13:06:21.958: I/some hardcoded tag(10176): 85 
09-05 13:06:21.958: I/some hardcoded tag(10176): 13 
09-05 13:06:21.958: I/some hardcoded tag(10176): -57 
09-05 13:06:21.963: I/some hardcoded tag(10176): 3 
09-05 13:06:21.963: I/some hardcoded tag(10176): 6 

我希望这不会混淆问题,但实际上演示了许多人在添加供他们自己使用时使用 BluetoothChat 演示代码时遇到的问题.我们需要以某种方式保持缓冲区不被覆盖,直到消息处理程序读取它?问候

I hope that hasn't confused the matter, but actually demonstrates the problem so many people appear to be having with the BluetoothChat demonstration code, when addapted for their own use. Somehow we need to keep the buffer from being overwritten until the message handler has read it?? Regards

阿德里安·雷福德

由于睡眠,更新后的代码工作得更好!

Updated code working better because of Sleep!

public void run() {
            Log.i(TAG, "BEGIN  IN mConnectedThread");
            byte[] buffer = new byte[1024];
            int bytes;

            // Keep listening to the InputStream while connected
            while (true) {
                try {
                      try {
                        sleep(100);
                    } catch (InterruptedException e) {
                        // TODO Auto-generated catch block
                        e.printStackTrace();
                    }
                    bytes = mmInStream.available();
                    Log.i("IN_BUFFER", "mmInStream-available bytes: " + Integer.toString(bytes)+ " ");
                    if (bytes>0){ 
                    for(int i=0; i<30; i++){ 
                       buffer[i] = 0;}
                    // Read from the InputStream
                    Log.i("IN_BUFFER", "Read Stream into Buffer:");
                    bytes = mmInStream.read(buffer);

                    Log.i("IN_BUFFER", "The entire buffer after read stream into buffer: " + Integer.toString(bytes)+ " "); 
                    for(int i=0; i<30; i++) 
                         Log.i("IN_BUF_AFTER", buffer[i] + " ");
                    // Send the obtained bytes to the UI Activity
                    Log.i("IN_BUFFER", "We now send to handler.");
                    mHandler.obtainMessage(BluetoothScale.MESSAGE_READ, bytes, -1, buffer)
                            .sendToTarget();}
                } catch (IOException e) {
                    Log.e(TAG, "disconnected", e);
                    connectionLost();
                    // Start the service over to restart listening mode
                    BluetoothScaleService.this.start();
                    break;
                }
            }
        }

现在日志如下所示:

09-05 20:57:15.833: V/BluetoothSocket.cpp(25368): availableNative
09-05 20:57:15.838: I/IN_BUFFER(25368): mmInStream-available bytes: 0 
09-05 20:57:15.888: V/BluetoothSocket.cpp(25368): availableNative
09-05 20:57:15.888: I/IN_BUFFER(25368): mmInStream-available bytes: 0 
09-05 20:57:15.943: V/BluetoothSocket.cpp(25368): availableNative
09-05 20:57:15.943: I/IN_BUFFER(25368): mmInStream-available bytes: 0 
09-05 20:57:15.958: V/BluetoothSocket.cpp(25368): writeNative
09-05 20:57:15.988: V/BluetoothSocket.cpp(25368): availableNative
09-05 20:57:15.993: I/IN_BUFFER(25368): mmInStream-available bytes: 2 
09-05 20:57:15.993: I/IN_BUFFER(25368): Read Stream into Buffer:
09-05 20:57:15.993: V/BluetoothSocket.cpp(25368): readNative
09-05 20:57:15.998: I/IN_BUFFER(25368): The entire buffer after read stream into buffer: 19 
09-05 20:57:15.998: I/IN_BUF_AFTER(25368): 2 
09-05 20:57:15.998: I/IN_BUF_AFTER(25368): -58 
09-05 20:57:16.003: I/IN_BUF_AFTER(25368): 48 
...truncated to save space ... 
09-05 20:57:16.033: I/IN_BUF_AFTER(25368): 85 
09-05 20:57:16.033: I/IN_BUF_AFTER(25368): 13 
09-05 20:57:16.033: I/IN_BUF_AFTER(25368): -57 
09-05 20:57:16.033: I/IN_BUF_AFTER(25368): 3 
09-05 20:57:16.038: I/IN_BUF_AFTER(25368): 6 
09-05 20:57:16.038: I/IN_BUF_AFTER(25368): 0 
...truncated to save space ... 
09-05 20:57:16.043: I/IN_BUF_AFTER(25368): 0 
09-05 20:57:16.043: I/IN_BUFFER(25368): We now send to handler.
09-05 20:57:16.058: I/MESSAGE_READ(25368): I am reading 19 bytes
09-05 20:57:16.058: I/Content(25368): The entire array:
09-05 20:57:16.058: I/some hardcoded tag(25368): 2 
09-05 20:57:16.058: I/some hardcoded tag(25368): -58 
09-05 20:57:16.058: I/some hardcoded tag(25368): 48 
...truncated to save space ...
09-05 20:57:16.063: I/some hardcoded tag(25368): 13 
09-05 20:57:16.063: I/some hardcoded tag(25368): -57 
09-05 20:57:16.063: I/some hardcoded tag(25368): 3 
09-05 20:57:16.063: I/some hardcoded tag(25368): 6 
09-05 20:57:16.093: V/BluetoothSocket.cpp(25368): availableNative
09-05 20:57:16.093: I/IN_BUFFER(25368): mmInStream-available bytes: 0

请注意 mmInStream.available() 返回 2 个字节,然后在我们读取缓冲区时的下一行代码中,读取了 19 个字节......真的很奇怪,它是如何在这两个所谓的直接步骤之间填满的.在重写缓冲区之前,睡眠似乎允许处理程序有足够的时间从传递的缓冲区读取消息.

Notice that the mmInStream.available() returns 2 bytes, then on the next line of code when we read the buffer, 19 bytes are read .. really strange, how it fills up between these two supposedly immediate steps. The sleep appears to allow enough time for the handler to read the message from passed buffer, before the buffer is rewritten to.

我本来希望 handler.obtainmessage... 发送一个唯一的缓冲区,但似乎发送了对线程缓冲区的引用,因此很麻烦.如何每次发送唯一的缓冲区?谢谢阿德里安

I would have expected the handler.obtainmessage... to send a unique buffer, but appears to send the reference to the thread buffer, thus the hassle. How can I send a unique buffer each time? Thx Adrian

推荐答案

我曾见过人们在使用蓝牙聊天示例时遇到此类问题.示例代码的问题在于发送到 Handler 的消息对象只包含对实际 byte[] 数组的引用,该数组用于每个后续 >read() 操作.这意味着一旦 Handler 获得消息并开始检查数组,蓝牙套接字上的后续 read() 操作已经有机会写入更新的数据到那个数组.

I have seen people run into this sort of problem before when using the Bluetooth Chat example. The problem with the example code is that the message object that is sent to the Handler simply contains a reference to the actual byte[] array that is used for each subsequent read() operation. This means that as soon as the Handler obtains the message and starts inspecting the array, the subsequent read() operation on the Bluetooth socket has already had the opportunity to write newer data to that array.

在这行代码中:

mHandler.obtainMessage(BluetoothChat.MESSAGE_READ, bytes, -1, buffer)
                        .sendToTarget()

数组没有被复制;而是该消息只是传达对同一数组的对象引用.

The array is not being copied; but rather the message is simply conveying an object reference to the same array.

蓝牙聊天示例实现其原始目的的唯一原因是它的目的是以人类打字速度传达短串字符.如果您发送的速度比这更快,Handler 从该数组中读取的内容将变成垃圾.

The only reason why the Bluetooth Chat example works for its original purpose is because its purpose is to convey short bunches of characters at human typing speed. If you send anything faster than that, what the Handler reads from that array turns to garbage.

答案是发送数组的副本(例如 System.arraycopy())或使用简单的循环缓冲区,这是我自己的蓝牙应用程序所使用的.

The answer is to send a copy of the array (e.g. System.arraycopy()) or use a simple circular buffer, which is what my own Bluetooth application uses.

前两个字节被破坏的事实很奇怪,但这可能只是由于特定设备上蓝牙堆栈中底层读取操作的具体实现.一个简单的事实是,一旦您使用该缓冲区调用了 read(),您就不应在此期间接触该缓冲区或关心其中的内容.也许您设备上的特定蓝牙套接字读取实现对缓冲区中的前几个字节进行了处理,因为与其内部操作有关.但是你不应该关心在 read() 阻塞时缓冲区处于什么样的有趣的中间状态,因为那时没有其他线程应该试图理解它.您所关心的只是当 read() 返回时缓冲区处于有效状态并具有有效数据.

The fact that the first two bytes are being mangled is a strange one, but it could just be down to the specific implementation of the underlying read operation in the Bluetooth stack on your particular device. The simple fact is that once you have called read() with that buffer, you should not be touching that buffer in the meantime or caring what's in it. Perhaps the particular Bluetooth socket read implementation on your device does something with those first few bytes in the buffer because of something to do with its internal operation. But you should not care what kind of funny intermediate state the buffer is in while read() is blocking, because no other thread should be trying to make sense of it at that time. All you care about is that the buffer is in a valid state with valid data when read() returns.

使用 sleep() 操作显然部分治愈"问题的原因是因为它是一种粗略的方式,让您的 Handler 有时间在之前查看数组后续的 read() 操作获得了数组.但这不是一个好的解决方案.

The reason why using the sleep() operation apparently partly "cures" the problem is because it's a crude way of giving your Handler time to look at the array before the subsequent read() operation gets its hands on the array. This is not a good solution though.

您遇到的第二个问题是由于在 Java 中,byte 是有符号的.这就是调试器将字节显示为有符号值的原因.在您的应用程序中,如果您需要将给定的字节用作 int 并且该字节最初是无符号的,您可以执行以下操作:

The second issue you have is due to the fact that in Java, byte is signed. That's why the debugger shows you the bytes as signed values. In your application, if you need to work with a given byte as an int and the byte is originally unsigned, you do something like:

int someValue = myByteArray[someIndex] & 0xff;

这篇关于Android InputStream 丢弃前两个字节(修改后的 BluetoothChat)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆