rfcomm

I have a strange issue with bluetooth socket. If I create socket and later close application, android device freeze with very hight CPU load. Here my sample code: // open socket public ConnectThread(final BluetoothDevice device) { Log.v(ConnectThread.class.getName(), "Try to get a socket"); try { this.socket = device.createRfcommSocketToServiceRecord(UUID.fromString("00001101-0000-1000-8000-00805F9B34FB")); } catch (IOException e) { Log.e(ConnectThread.class.getName(), e.getMessage()); } Log.v(ConnectThread.class.getName(), "Got a socket"); } // close it public void cancel() { try { Log.v

I have Windows Phone app, that controls a device by Bluetooth (Bluetooth App To Device). In WP8 it works good. This is code 1)searching all paired devices PeerFinder.AlternateIdentities["Bluetooth:Paired"] = ""; var peers = await PeerFinder.FindAllPeersAsync(); ObservableCollection<PeerInformation> devicesCollection = new ObservableCollection<PeerInformation>(); foreach (var peer in peers) { devicesCollection.Add(peer); } 2)connect to device socket = new StreamSocket(); await socket.ConnectAsync(selectedPeer.HostName, "{00001101-0000-1000-8000-00805F9B34FB}"); 3)connect to PC or to other Phone

I´m writing an android app that connects to a device through bluetooth using RFCOMM. I use the BluetoothChat example as basis for establishing a connection and everything works perfectly most of the time. However, sometimes I cannot reconnect due to a message that the socket is already open: RFCOMM_CreateConnection - already opened state:2, RFC state:4, MCB state:5 This tends to happen if I connect to the device, close the app (call onDestroy()), reopen it and try to connect again, which results in the above. I use this method for connecting in the ConnectThread(ref.BluetoothChat example):

I have two Android devices which I want to connect, using Bluetooth, and transfer data over an RFCOMM channel. I only one one device to receive data, while the other device sends it... Using this code, I am able to connect to the other device and begin listening to an RFCOMM channel: Method m = device.getClass().getMethod("createRfcommSocket", new Class[] { int.class }); socket = (BluetoothSocket) m.invoke(device, 2); socket.connect(); class BasicThread implements Runnable{ public void run() { try { InputStream stream = socket.getInputStream(); BufferedReader r = new BufferedReader(new

I'm looking for a way to detect the disconnection of a Bluetooth device immediately after it has happened (2 second max), typically in a "device too far" scenario or Device battery is dead. Currently I can detect it with a BroadcastReceiver by getting a BluetoothDevice.ACTION_ACL_DISCONNECTED , but it takes about 16 to 20 seconds to fire. Is there any way to get notified in 2 seconds Max. I used BroadcatReceiver but it is not fast enough to get alert in 2 seconds Max, so is there any other kind of approach available to get notification quickly that bluetooth is disconnected. I use this

I am planning a communication protocol to be used between an Android device and a custom sensor that would use a commercial Bluetooth module. I would use the SPP profile that is said to "provide a simple reliable data stream to the user, similar to TCP." I am not so familiar with the Bluetooth technology and have some questions about designing such a protocol. First of all it is not clear to me if I have to worry corrupted data being transferred or not. Will the underlying protocoll stack guarantee me that the bytes I read from the InputStream Android gives are the same that the UART receives

I am trying to connect two unpaired android devices via Bluetooth for P2P networking purposes. MitM protection is not required. Android has the createInsecureRfcommSocketToServiceRecord and listenUsingInsecureRfcommWithServiceRecord for this (since API level 10), which works perfectly on modern devices. However, on a Galaxy Ace (Android 2.3.3 = API level 10, connecting with a Galaxy Nexus), it creates a pairing dialog. This happens both on incoming and outgoing connections. ( Update : Updating the Galaxy Ace to Android 2.3.6 apparently fixes the problem. Is there a specific Android version