安卓的InputStream下探前两个字节（修改BluetoothChat） [英] Android InputStream dropping first two bytes (modified BluetoothChat)

查看：242
本文介绍了安卓的InputStream下探前两个字节（修改BluetoothChat）的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我用code从BluetoothChat例如从Bluetooth规模发送和接收字节的数据。 规模接收命令从设备，然后发回一个字节数组。 {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.

所有工作得很好，除了以下code在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;
                }
            }
        }

我有一个问题，特别是与code以下部分：

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（缓冲区）被执行之前，它的内容，缓冲区中包含了正确的数据被送回了规模装置，即：

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}

但一旦code已被台阶，前两个字节的缓冲器被剥离，它现在错误地包含：

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}

请理解，我是新来的Andr​​oid - java的，并且有很多东西需要学习。所有帮助将AP preciated。 谢谢 阿德里安

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

我已经加入log.i项，以更好地了解什么是基于拉杜的意见发生。看来，以后我写数据到我的设备通过蓝牙，它响应了，我们看由于某种原因只有前两个字节，然后把这些给消息处理程序，然后读取从设备发送数据包的休息，然后送这一关的消息处理程序，但在此之前的处理程序，甚至回应的第一次，缓冲区已被覆盖，因此，通过处理程序尝试读取前两个字节的时候，正在读第3和第4字节的响应数据包，然后立刻再次响应和读取3-17th位置的整个数据包。 所以，如果我可以把它简单地..消息处理程序只响应发送缓冲区它已被覆盖后。请参阅下面的日志：

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，之前，我没有这个日志出现如下之前，我的新code也重置缓冲区为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示范code，当addapted为自己所用有。 不知怎的，我们需要保持缓冲区被覆盖，直到消息处理程序阅读？ 问候

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

阿德里安Wreyford

Adrian Wreyford

更新code工作，因为睡眠好！

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;
                }
            }
        }

现在的日志，如下所示：

Now the logs look as follows:

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个字节，然后在code中的下一行，当我们读缓冲区，读出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

推荐答案

我见过的人使用蓝牙聊天例如，当之前碰到这样的问题。与例如code的问题是，发送到处理程序的消息对象只包含一个引用到实际字节[] 阵列用于每个后续的阅读（）操作。这意味着，只要处理程序得到消息，并开始检查阵列，随后阅读（）操作上蓝牙接口已经有机会写新的数据到该数组。

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.

在这行code：

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.

为什么蓝牙聊天示例适用于它原来的目的的唯一原因是因为它的目的是要传达的字符短束在人的打字速度。如果你送什么比这更快，什么处理程序从阵列读取变为垃圾。

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.

这前两个字节被错位事实是奇怪的，但它可能只是降低到在蓝牙栈的底层的读操作的特定设备上的特定的实现。一个简单的事实是，一旦你有一个名为阅读（）与该缓冲区，你不应该接触在此期间该缓冲区或关心什么在它。也许特定蓝牙套接字读取执行您的设备上做一些事的，因为是与它的内部运作缓冲区的前几个字节。但你不应该关心什么样的有趣的中间状态的缓冲区中，而阅读（）阻止，因为没有其他线程应该试图理解它当时。所有你关心的是，缓冲区与有效数据有效状态时，阅读（）的回报。

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.

为什么使用睡眠（）理由操作显然部分是治愈的问题，是因为它给人一种粗暴的方式你的处理程序时间来看看之前随后阅读（）操作获取其手中的阵列上的阵列。这不是一个很好的解决方案，但。

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中，字节签署的事实。这就是为什么调试器显示你的字节作为符号值。在应用程序中，如果你需要一个给定的字节作为工作 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;

这篇关于安卓的InputStream下探前两个字节（修改BluetoothChat）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
移动开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆