when opening a bluetooth rfcomm socket via the UUID method ( the other method ( using reflection ) in here http://code.google.com/p/android/issues/detail?id=5427 ) - I sometimes get the following error ( after successfull connections ) and the socket is not opened:
E/BluetoothService(21847): Received ACTION_UPDATE_SERVICE_CACHE00:0B:CE:01:2E:00
D/BluetoothService(21847): updateDeviceServiceChannelCache(00:0B:CE:01:2E:00)
D/BluetoothService(21847): Cleaning up failed UUID channel lookup: 00:0B:CE:01:2E:00 00001101-0000-1000-8000-00805f9b34fb
had no luck with google on this one - has anyone here a clue whats going on and how to prevent that?
Update:
for people running into the same problem - possible solutions:
advice the users to reboot the device if we run into that state (
very bad UX )
use the reflection method ( dirty but works most of the time )
I am still open for new Ideas ;-)
I stick to #2 at the moment - but waiting for a better solution.
It seems that the message is the consequence, not the reason. If a serial port emulation service is not found on device the connection will obviously fail.
Update
After reviewing code everything seems ok. So my questions are: Do the random errors occur with same device o with different devices? If the occur with different devices, the devices might have not registered the SerialPort service. Is device previously paired? In case of the error ocurring randomly with same device? Are you using the connection class concurrently? You have not protected the methods against concurrent access. You have not protected either against succesive connects. If you try to read/close a stream after a second connect it will fail (the socket object has changed).
It seems ok. The random error occurs with same device? If this is the case, are you using concurrent use of that class? In first case
Related
Background
A long time ago I was tasked with making a android app for the Wii Balance Board, after some screwing around I found that android no longer supported L2CAP. More research lead to understand that it was being re-added in Android 10. With Android 10 out I've been trying to give it a crack now.
Problem
So my simple goal at the moment is to create a connection with the Wii Balance Board.
My approach for connection is:
Start discovery
Add discovered bluetooth devices to list
When you click on a device it then tries to open a socket as such:
bluetoothSocket = btDevice.createInsecureL2capChannel(port);
As mentioned on the WiiBrew site I'm using psm value 0x13 for input and 0x11 for output.
I then use bluetoothSocket.connect and proceed to receive a IOException (timeout error)
I've also tried using both createL2capChannel and createInsecureL2capChannel with same results
I was able to successfully pair to the device using btDevice.createBond() and then using the phones BT address backwards for .setpin() and the Wii Balance Board simply acts as a "dumb" input device. (not sure if pairing is needed/good idea)
The above is a simplified flow of how I'm trying to connect. I've also tried using BalanceBoard.java from Paul Burton's fitscales repo updating all of the old bluetooth code, again I still get the timeout.
Have you looked at the bt_stack logs?
Here is mine from trying to open a socket with a wiimote:
04-05 12:25:04.949 E/bt_stack(4895): [ERROR:btif_sock_l2cap.cc(244)] SOCK_LIST: free(id = 4) - NO app_fd!
04-05 12:25:04.949 I/bt_stack(4895): [INFO:btsnoop.cc(323)] clear_l2cap_whitelist: Clearing whitelist from l2cap channel. conn_handle=65535 cid=65:0
04-05 12:25:04.949 E/bt_l2cap(4895): L2CA_FreeLePSM: Invalid PSM=19 value!
04-05 12:25:40.141 I/bt_stack(4895): [INFO:btsnoop.cc(323)] clear_l2cap_whitelist: Clearing whitelist from l2cap channel. conn_handle=1 cid=66:64
04-05 12:25:55.736 I/bt_stack(4895): [INFO:btsnoop.cc(323)] clear_l2cap_whitelist: Clearing whitelist from l2cap channel. conn_handle=2 cid=67:65
I believe this is where the problem lies, Im only a novice so Im not sure what can be done about it. I know the old ways of connecting passed the fd as a parameter to the bluetooth socket constructor but I dont think this is possible anymore
I've been experimenting with the new Android Nearby Connections v2.0 API. Most of my devices can now talk to each other most of the time, but I also get a lot of error codes back when trying to connect. Checking status.getStatusCode() inside my program, I can see the following return codes:
STATUS_ALREADY_CONNECTED_TO_ENDPOINT (8003)
STATUS_BLUETOOTH_ERROR (8007)
STATUS_ENDPOINT_IO_ERROR (8012)
STATUS_ERROR (13)
I'm having a hard time making sense of these. The first error code seems self-explanatory, except that I see it in cases when I haven't hit the onConnectionResult callback with a "SUCCESS" return code on either side of the alleged connection. My current code is full of trace statements, and I'd see logging entries if those callbacks had been reached. So maybe the devices are connected at some lower level, but if so, the higher-level code doesn't always hear about it.
I'm guessing that STATUS_BLUETOOTH_ERROR indicates a Bluetooth error on the side that logs it, while STATUS_ENDPOINT_IO_ERROR indicates an error (probably involving Bluetooth) on the other end? Is it possible to get any more details?
The STATUS_ERROR (13) status that I see once in a while sounds like the sort of error code a programmer would use for those "WTF, we should never get here" moments, but without access to the source code, I can only guess.
Note that I see these errors between devices that talk to each other beautifully at other times, using the same code. Sometimes if the code retries enough times, it eventually gets a stable connection. Sometimes it connects and gets instantly disconnected from the other end. Sometimes I just get an endless stream of repeated error messages (STATUS_BLUETOOTH_ERROR and/or STATUS_ENDPOINT_IO_ERROR).
I'm using Nearby Connections with the connection strategy P2P_CLUSTER. These problems seem to happen most often when both sides do both advertising and discovery. However, I wrote two smaller programs that specialize in either advertising or discovery, and they sometimes get these errors too (but less often).
In the trace messages, I've also noticed lots of warning messages from Nearby Connections that look like this:
09-04 22:54:40.070 3866-3924/? W/NearbyConnections: Cannot deserialize BluetoothDeviceName: expecting min 16 raw bytes, got 6
I'm guessing that this is because Nearby Connections uses its own short tokens (like ZGbx) instead of the device Bluetooth name? I'm not at all sure about that, though. And anyway, if these are Nearby Connections' own special tokens, then why would it be issuing warning messages about it?
[Disclaimer: I work on Nearby Connections] I can try and help out.
STATUS_ALREADY_CONNECTED_TO_ENDPOINT: This occurs if you call 'requestConnection' while you have any pending (onConnectionInitiated) or established (onConnectionResult) connections to the given endpoint. Move your log statements earlier, to onConnectionInitiated, and you should see why we throw this error.
STATUS_BLUETOOTH_ERROR: Something went wrong with Bluetooth. The phone is probably in a bad state. This (hopefully) shouldn't happen too often. But if you really want a fix, stop advertising & discovery before reattempting requestConnection. Nearby Connections will toggle Bluetooth when it detects this error, but only if nothing else is going on.
STATUS_ENDPOINT_IO_ERROR: We lost connection to the other device. This can happen for a variety of reasons (they could have walked too far away, Bluetooth was flaky, the device stopped responding, etc). If you're discovering while you have connections, avoid that. Discovery can be hard on the phone and reduces bandwidth at best, causes dropped connections at worst.
STATUS_ERROR: Something went wrong that didn't fit well in the other error codes. It's a catch-all. This is most-often returned in onConnectionResult(FAILED), to notify you that something went wrong in between onConnectionInitiated and waiting for both sides to accept the connection.
We've also lowered the log severity of "Cannot deserialize BluetoothDeviceName" in an upcoming release, since it's not really a warning. It's like you said; expected behavior when we see non-Nearby Connections devices while discovering.
If you continue to see problems, let us know what devices you're using and we'll be sure to add them to our test suite.
I just want to add that it may be necessary to have a short client name string when calling the API.
E.g., Nearby.Connections.requestConnection(googleApiClient, shortNameHere,....)
I had been generating my own client name with UUID.randomUUID().toString() and that seemed to cause the STATUS_BLUETOOTH_ERROR.
All I did was change the code sample to use a UUID name and to use P2P_CLUSTER and I got that error.
This was the solution for me regarding the STATUS_BLUETOOTH_ERROR.
I am building an app to read data from a ble device. After connecting to a device I call mBluetoothGatt.discoverServices() and in onServicesDiscovered(..) I am reading the list of service by calling getServices().
The problem is sometimes the list is empty.Has anyone faced this issue.The issue is random and not 100% reproducible.
Yes,this is a Common problem.If you get empty services,you can retry discover .
If you get empty more than 3 or 5 times,you should restart you Bluetooth,because it is may be unstable
I just run into this, but even retrying the discovery, gatt services were empty. For me the solution was to restart both BLE and Android devices.
My BLE application requires computation on the server side (BLE chip) which takes time and results with disconnection.
Th flow is like this:
1- Android phone writes the characteristic value to the BLE chip.
2- The chip evaluates this value and starts computation.
3- The connection is lost soon after the computation has started.
What solution can I apply to prevent the disconnecton? I have two solutions in my mind:
1- Changing the connection interval: Currently Android uses 7.5 msec as connection interval. Since the computation on BLE chip takes time, packets are not sent or received during the computation. Increasing the connection interval will decrease the number of lost packets. However there is no guarantee that Android phone will accept the new connection parameters.
2- Running the computation in a separate thread: I dont think that BLE chips' SDK support multi-threading such that while there is a computation process going on, it will keep receiving and sending packets and prevent the disconnection. I use CSR chip and I think it doesnt support.
Please correct me if I am wrong at my points.
Do you have any other suggestions to solve the issue?
Thanks in advance.
Thank you for the answers. I found out what the problem is after spending hours.
First of all, when Android gives error 133 or 129, it is most probably because of the remote device.
At the beginning I thought that the problem occurred because of the supervision timeout. Then I re-configured the connection parameters of the CSR chip but it didn't help.
There is a problem about CSR app development with xIDE (IDE of CSR). When there is run-time-error due to index overshoot or accessing some invalid pointers, then you would not receive any errors in xIDE. I finally found out the array problem and fixed it. Now it works perfect.
Thanks a lot!
I don't know exactly if what i going to explain it's feasible under Android because I used BLE only with a low level applications, anyway if your problems are the connection parameters you can try to change the Slave_Latency.
It should be usefull since playing with this parameter, you can change the number of connection intervals in which the Central device can wait until it considers the connection lost.
The following equation is usefull to derive the connection parameters:
Effective_Connection_Interval = (Connection_Interval)*(1+(Slave_Latency))
Remember that can exists some kind of Supervision_Timeout that can collide with your Effective_Connection_Interval
I am stuck at a place where my Android Phone(Samsung Galaxy) has to open 2(or more) connections to my PC(server) which is a paired device. For this purpose, I start SDP server on PC with UUID : 00001101-0000-1000-8000-00805F9B34FB and channel 2, after the first connection I unregister the SDP service on the PC and register it again on channel 3(and same UUID) and expect my android phone to 'connect' to it for establishing the second bluetooth connection. The second one fails.
The problem as I have figured out is that because of the pairing, the channel num and UUID of the device for the 'BluetoothSocket.connect' are serviced from cache and are not being updated, so my SDP change in channel num on the server side is not visible here as it still tries to connect to channel 2(old one).
A workaround of this problem(found after a lot of frustrating attempts) might be to change the android.server.BluetoothService.java file, by introducing
updateDeviceServiceChannelCache(addr) before returning in the getRemoteServiceChannel() and fetchRemoteUuids() so as to update the channel number at each func call.
The above solution may well be wrong, please pardon me for that. If it is correct please suggest any further changes and how to make this change permanent in eclipse, or in other case(wrong solution), the right way of doing this.
Note: I have android 2.3.5 and the requests from the device are actually from the browser that I forward to the PC. I want them on separate channels.
thanks.