Develop Reference

Need help implementing Bluetooth in my Android app

I am creating an app for an arduino thermometer, to connect via Bluetooth.
However I am finding it very difficult to implement Bluetooth in Android studio I looked at the example here, I am having errors implementing it.
It's line 65 in the "MyBluetoothService" class that is creating the error.
The error is: Cannot resolve method "obtainMessage(int, int, int, byte[])
The link to the full code
And the faulty code here:
public void run() {
mmBuffer = new byte[1024];
int numBytes; // bytes returned from read()
// Keep listening to the InputStream until an exception occurs.
while (true) {
try {
// Read from the InputStream.
numBytes = mmInStream.read(mmBuffer);
// Send the obtained bytes to the UI activity.
Message readMsg = mHandler.obtainMessage(
MessageConstants.MESSAGE_READ, numBytes, -1,
mmBuffer);
readMsg.sendToTarget();
} catch (IOException e) {
Log.d(TAG, "Input stream was disconnected", e);
break;
}
}
}

Android Open Accessory USB communication failing after sending large data packets

I have an android phone communicating with a Linux machine using AOA. The Linux machine is set up to initiate the connection, then wait for incoming data and echo it back to the phone unchanged. This works fine for small packets of data (less than 1024 bytes) from the phone. However, if I send exactly 1024 bytes, it appears to work from the Android end, but the computer never sees the packet, just any following ones that are smaller. If the phone attempts to send packets larger than 1024, these do get received by the computer, but the android phone will no longer be able to receive any packets from the computer. Further confusing the issue, this did work in the past, yet rolling back to earlier versions of the transmitting/receiving code on the phone doesn't seem to have any effect. The code on the computer has not been changed.
The android app checks for a USB accessory at start-up, and if one is found it starts a listener and sender thread. The sender thread waits on a blocking queue for outgoing packets, and sends them as soon as they are received. The listener thread continuously attempts to read from the input stream, which blocks until data is available. This is the code I use for setting up & running the threads:
private boolean openUSB(){
mUSBManager = (UsbManager) getSystemService(Context.USB_SERVICE);
mAccessory = mUSBManager.getAccessoryList();
if (mAccessory != null && mAccessory.length > 0) {
mParcelFileDescriptor = mUSBManager.openAccessory(mAccessory[0]);
mFileDescriptor = mParcelFileDescriptor.getFileDescriptor();
mListener = new Thread() {
public void run() {
listenerThread();
}
};
mListener.start();
mSender = new Thread() {
public void run() {
senderThread();
}
};
mSender.start();
displayText("Connected to USB accessory");
return true;
} else {
displayText("No USB accessory detected");
return false;
}
}
private void listenerThread(){
byte packet[] = new byte[SDR_PREFIX_SIZE+SDR_HEADER_SIZE+SDR_MAX_PAYLOAD+SDR_CRC_SIZE];
FileInputStream input = new FileInputStream(mFileDescriptor);
try {
ByteArrayOutputStream incoming = new ByteArrayOutputStream();
displayText("Listener Started");
while ( mFileDescriptor != null && input != null ) {
int read = input.read(packet,0,packet.length);
/* data in packet gets processed */
}
} catch ( Exception e) {
displayText("Listener Exception - "+e.getMessage(),true);
}
displayText("Listener Exited");
}
private void senderThread(){
displayText("sender started");
FileOutputStream output=new FileOutputStream(mFileDescriptor);
try {
byte data[] = mTransmitQueue.take();
while (data != null) {
displayText("Sending packet " + packet + ", "+data.length + " bytes");
output.write(data);
data = mTransmitQueue.take();
}
} catch ( Exception e) {
displayText("Sender Exception - "+e.getMessage(),true);
}
}
In the past, I had issues getting the listener and sender to work, until I found out that some of the intermediate objects that were used to create the file streams were being garbage-collected, yet were still needed. I now store all those intermediate objects to member variables (mUSBManager, mAccessory, mParcelFileDescriptor, mFileDescriptor) to give them persistence. I suspect that this issue is something similar, but I haven't been able to make any headway. I have been beating my head on this issue without any success, and really hope that others will have some insight on what is causing this.

I've found a work-around, expanding the buffer used for receiving data seems to fix the issue, even though the existing buffer was large enough for all packets. Increasing the buffer from 1524 to 2524 fixed the issue with incoming packets not being received. This is a kludgy solution, but it works.

Android Bluetooth SPP - How to stop transmitting the internal send buffer ?

I am trying to control/operate a motor from an android phone in "as close as possible" realtime using the Android SPP Bluetooth socket interface. The motor ought to run in a so called 'dead man' operation mode. So the motor will only turn if a button on the android APP is touched and ought to stop immediately if the touch is released.
I implemented this by continuously sending 'keep turning' telegrams of 20 Bytes about every 20ms to keep the motor turning and to have the motor stop immediately as soon as no more telegrams are received or if a STOP telegram is received.
This seem to work acceptable well on some phone but others continue sending 'keep turning' telegrams even after the MotionEvent.ACTION_UP event has been processed and no more data are being send.
I assume that this is caused by some internal buffers that cache the transmit data and continue sending until the buffer is empty.
Simple questions:
Is there a way to purge the BT stream transmit buffer to stop all data transfer immediately?
Or can I get the fill level of the transmit buffer in which case I would not put anything more than about 2 telegrams into it?
Or is there a way to specify the buffer size when opening the stream?
Searching the net, I was not able to find anything that talks about BT stream buffer size of buffer management.
And Yes, I have implemented read and write functions as threads and I do not have any problems in reading all telegrams, and I do not need to deliver telegrams in real time but I should be able to stop sending 'keep turning' telegrams within about 50 to 100ms.
Any hints are very welcome.

I am sorry that I did not add the code, I thought it may not be necessary as it is straight forward as:
#Override
public boolean onTouch(final View v,MotionEvent event) {
int eventAction = event.getAction();
switch (eventAction) {
case MotionEvent.ACTION_DOWN:
if (v == btnUp || v == btnDown) {
// Start a thread that sends the goUP or DOWN command every 10 ms until
// btnUp released
tvCounter.setText("----");
action_touched = true;
new Thread(new Runnable() {
#Override
public void run() {
int counter = 1;
// Disable heart beat
ServiceRequest.send(EnRequest.REQ_SET_HEARTBEAT,0);
// Send GoUp command plus a wrapping counter byte every nn ms
// until the button is released
while (action_touched) {
try {
setDeadmanMove(v==btnUp,counter);
Thread.sleep(20);
++counter;
}
catch (InterruptedException ex) {
action_touched = false;
}
catch (Exception ex) {
action_touched = false;
}
}
// Send a STOP command
setDeadmanStop();
// Enable heart beat again
ServiceRequest.send(EnRequest.REQ_SET_HEARTBEAT,1);
// We are done
}
}).start();
}
break;
case MotionEvent.ACTION_UP:
// Stop Thread
action_touched = false;
break;
}
return true;
}
The snipped below is part of the communication class that manages the Bluetooth serial communication.
public void btWrite(DeviceRecord message) {
if (runBTreceiver) {
if (message.isValidRecord()) {
try {
lock.lock();
++lockCounter;
mmBufferedOut.write(message.getFullRecord());
mmBufferedOut.flush();
}
catch (IOException e) {
if (GlobalData.isDebugger) Log.i(TAG, "Failed sending " + message + " " + e.getMessage());
ServiceResponse.send(EnEvent.EVT_BT_RECEIVER_ERROR, "Error data send: " + e.getMessage());
resetConnection();
runBTreceiver=false;
}
finally {
--lockCounter;
lock.unlock();
}
}
}
}
The code snipped that allocates and opens the Bluetooth connection
try {
// Set up a pointer to the remote node using it's address.
BluetoothDevice device = myBluetoothAdapter.getRemoteDevice(myBluetoothMacId);
if (device != null)
{
// Two things are needed to make a connection:
// A MAC address, which we got above.
// A Service ID or UUID. In this case we are using the
// UUID for SPP.
try {
myBluetoothSocket = device.createRfcommSocketToServiceRecord(GlobalData.MY_UUID);
}
catch (IOException e) {
sendEventStatus(EnEvent.EVT_BTADAPTER_FAIL,
String.format(GlobalData.rString(R.string.srv_failcrt),BTERROR_CREATE,e.getMessage()));
}
// Establish the connection. This will block until it connects or
// timeout?
try {
if (! myBluetoothSocket.isConnected()) {
myBluetoothSocket.connect();
}
}
catch (IOException e) {
try {
Log.e("","trying fallback...");
myBluetoothSocket =(BluetoothSocket) device.getClass().getMethod("createRfcommSocket", new Class[] {int.class}).invoke(device,1);
myBluetoothSocket.connect();
}
catch (IOException e2) {
sendEventStatus(EnEvent.EVT_BTADAPTER_FAIL,e2.getMessage());
}
}
}
else {
sendEventStatus(EnEvent.EVT_BTADAPTER_FAIL,
String.format(GlobalData.rString(R.string.srv_failcrt),BTERROR_DEVICE,"getRemoteDevice failed"));
}
}
catch (Exception e) {
sendEventStatus(EnEvent.EVT_BTADAPTER_FAIL, e.getMessage());
return;
}
InputStream tmpIn = null;
OutputStream tmpOut = null;
mmSocket = socket;
// Get the input and output streams, using temp objects because
// member streams are final
try {
tmpIn = socket.getInputStream();
tmpOut = socket.getOutputStream();
}
catch (IOException e) {
ServiceResponse.send(EnEvent.EVT_ERROR, GlobalData.rString(R.string.srv_failcst) + e.getMessage());
resetConnection();
runBTreceiver=false;
}
mmInStream = tmpIn;
// mmOutStream = tmpOut;
mmBufferedOut = new BufferedOutputStream(tmpOut,80);
// Initial request
btWrite(new DeviceRecord(0, 4));
I have never discovered any problems sending and receiving data via this code. All records are sent and received properly. Only problem was that I am unable to purge the transmit buffer at the moment the operate button was released.
To overcome this problem, I have changed the protocol in such a way, that only a single 'keep turning' telegram is send at a time, the next telegram will be send after a response from the other end (sort of handshaking), the program then continue to run this ping/pong until the button is released.
This method works quite well as the transmit buffer will never hold more than one telegram at a time.
the mentioned problem is solved though but I still have no clue of whether it would be possible to purge a transmit buffer

Android VpnService: Reading from Tun device hangs

My app is using VpnService for traffic interception.
What it does:
1.Reads from Tun device in a loop:
while (started && tunDevice.valid()) {
final byte[] bytes = tunDevice.read();
IpPacket packet = PacketFactory.createPacket(bytes);
if (packet == null) {
Thread.yield();
} else {
proxyService.handlePacket(packet);
}
}
TunDevice.read:
#Override
public byte[] read() throws IOException {
if (!valid()) {
LOG.warn("TUN: file descriptor is not valid any more");
return null;
}
int length = tunInputStream.read(readBuffer);
LOG.debug("TUN: Received packet length={}", length);
if (length < 0) {
throw new IOException("Tun device is closed");
}
if (length == 0) {
return null;
}
return Arrays.copyOfRange(readBuffer, 0, length);
}
2.Proxifies data to the protected socket.
The problem is that after some time it stops reading from TUN device.
Read method just hangs and waits for some time (like 3-5 minutes).
Using netstat I see that all new connections are in SYN_SENT state and I can understand why - they cannot receive ACK from my code because I cannot receive these SYN packets.
The question is: what could it be? When TUN device could behave like this?

In our case the problem was in our TCP implementation.
We have written more data than TCP could receive (advertised window).

Need to have "stable" TCP connection to server

I need to have a "stable" connection to a server.
The client tries to connect to the server every 5 (10, N)-seconds.
After having connected successfully the client receives data from the server.
In case of service interruption (server shutdown, for example), go to step #1.
How I test:
I start the server
I start the client (to be sure that client gets data from the server)
I stop the server
I wait for about 200 client attempts to connect to the server.
I restart the server.
The server sends data, but the client doesn't get it.
socket.connect(...) is sucessfull, but
socket.getInputStream().read(byte[]) is not: the Thread blocks on input.read(..).
If I uncomment this line:
//socket.setSoTimeout(500);
then input.read(..) throws a TimeoutException.
But the server receives data from the client.
Where is my wrong?
Thanks.
Part of client code:
private void initSocket() {
try {
if (socket == null || socket.isClosed() == true
|| socket.isConnected() == false) {
socket = new Socket();
// socket.setSoTimeout(500);
InetSocketAddress socketAddress = new InetSocketAddress("192.168.1.3"
, 12344);
notifyDataListener(4);
socket.connect(socketAddress, 500);
notifyDataListener(5);
}
} catch (Throwable t) {
System.err.println(t);
}
}
private void closeSocket() {
try {
if (socket != null && socket.isClosed() == false) {
socket.close();
}
} catch (Throwable t) {
System.err.println(t);
}
}
private byte[] buffer = new byte[1024];
public void run() {
while (isActive) {
try {
notifyDataListener(1);
initSocket();
InputStream input = socket.getInputStream();
int length = input.read(buffer);
if (length < 0) {
throw new EOFException("Was got -1");
}
notifyDataListener(2);
} catch (Throwable t) {
closeSocket();
notifyDataListener(3);
try {
Thread.sleep(100);
} catch (InterruptedException ie) {
}
}
}
}
On J2SE the same code works fine. Connection repairs after many wrong attempts.
It looks like Android has limit slosts of sockets (FileDescriptior?), takes them, but don't release after.

Your likely running out of file descriptors, i'm sure the limit is much lower on android than on a typical desktop configuration but the specific values will vary.
With the way you've coded this, the socket will hang around until its garbage collected, additionally on some platforms, the OS level sockets do not close instantly but hang around for a period of time to clean up any hanging data.
The first thing you should do is move your socket.close() code to finally {} statements which will free the socket immediately rather than waiting for garbage collection.