Neil, My original implementation used a pool of 7 UUIDs, but since thats a nightmare to manage if you don't make activity limiting assumptions, I tried re-implementing based on a single UUID. My tests showed that I got the same behavior with 1 UUID or 7, so I ripped out the UUID management stuff. My theory (detailed here: http://stackoverflow.com/questions/7198487/are-connected-bluetoothsocket-rfcomm-channels-unique-regardless-of-uuid) is that UUIDs do nothing other than provide a key to a particular SDP entry, and that the call to listenUsingRfcommWithServiceRecord() or createRfcommSocketToServiceRecord() creates a new socket on an open RFCOMM channel, regardless of the UUID used. I have no definitive proof but unless I can get a google engineer to answer either this or the other question I can't know, so I'm just proceeding this way.
One thing to watch out for is that one time (and one time only) when I opened a new connection, the receiving phone prompted me that the external connection was trying to connect to my mailbox through BT. I don't know a ton about BT but it appears there is a BT channel specific to mailboxes that can get mixed up in there. I don't know if the 2.2 device was mixed up in there or how; it was 2 weeks ago or so and I didn't take notes, and it didn't happen again. I have no other updates, I'm working on other code right now. Unfortunately I am only working data sockets right now so I have no insight to share wrt audio sockets. Good Luck! On Sep 11, 7:46 pm, Neil <[email protected]> wrote: > I'm doing the same, extended the Bluetooth Chat example in a similar > way to you. > > Not tried with 4 devices yet, your experience is worrying! > > Any updates? > > Are you doleing out from a Collection of 7 UUIDs? > > My Asus EeePad or Nexus One can't sustain a Bluetooth audio stream at > the same time as one of my connections, even if there's no data > traffic. > > On Aug 31, 9:19 pm,novakom<[email protected]> wrote: > > > I am developing an app which will have multiple phones communicating > > together concurrently via bluetooth. To this end, I extended the > > BluetoothChat example to support multiple simultaneous connections. > > Once I got it working with 3 phones, I ramped up to 4 but have > > discovered that it appears that phones running Android 2.2 can only > > support 2 simultaneous bluetooth connections, while phones running > > 2.3.4 can support 3 (at least, if not more). Can anyone confirm this > > as a known bug for 2.2? It would be good to know if this is just a > > hard limitation. > > > Phones I am testing with: > > HTC Incredible (2.2) > > Nexus S (2.3.4) > > Nexus 1 (2.3.4) > > Nexus 1 (2.3.4) > > > Here's how I determined that there is this hard limit: > > > My code extends the BluetoothChat sample program, as I said. > > Unfortunately I cannot share it right now (company legal limitations) > > but it's basically the same as the original except that all threads > > are not killed when new connections are made, all ConnectThread and > > ConnectedThread objects are stored in an array, and I kick off a new > > AcceptThread whenever an incoming connection is turned into a > > ConnectedThread. > > > After instrumenting my code with lots of debug, what I've found is > > that once my 2.2 device (the incredible) has established 2 > > connections, it will literally hang at either the accept() in the > > AcceptThread or at the connect() in the ConnectThread. This is true > > with whichever order of connections are made. For example, if I do > > the following: > > 1. Incredible > NS > > 2. Incredible > N1 (1) > > 3. Incredible > N1 (2) > > or > > 1. Incredible > N1 (1) > > 2. Incredible > N1 (2) > > 3. Incredible > NS > > or > > 1. Incredible > N1 (either) > > 2. Incredible > NS > > 3. Incredible > N1 (either) > > or > > 1. NS > Incredible > > 2. N1 (either) > Incredible > > 3. N1 (either) > Incredible > > > In all cases, the Incredible will Always hang on step 3, whether it's > > on the connect() in the first 3 cases, or the accept() in the last > > case. Debug shows that it hangs specifically on those calls (not the > > RFComm socket creation calls or anything else). Now, there are other > > potential connection orders but these are the basic ones that need to > > work, so I'm not worried about interleaving connects and accepts right > > now. > > > The other interesting thing is that I instrumented an end program > > method from the menu which calls cancel on all open threads. > > According to the SDK, when you call close() on an open hanging socket, > > it is supposed to throw an error. Well, if the app has already hung > > on either accept() or connect() in any of the scenarios above, then > > the close() call hangs as well and I have to forceclose the program. > > > Other info: > > - Using another N1 running 2.3.4, I found that I didn't have any > > trouble connecting all 4 phones as long as the incredible wasn't in > > the mix. > > - Also, when a phone running 2.3.4 with 2 active connections tries to > > connect to the incredible while the incredible has 2 other active > > connections, the phone running 2.3.4 fails to connect and does not > > hang, while attempting the connection in reverse has the (now) > > expected hang. > > - Also tried to connect 4 phones with a Samsung Infuse (2.2) and > > another N1 running 2.2. Both cases had similar hangs (cannot > > exhaustively check this thanks to limited access to the devices). > > - When trying to establish a 3rd connection with a device which is not > > there (turned off the bluetooth on one of the N1s), the connect() call > > does NOT hang. However, if I then turn on BT on the 3rd phone and try > > to reconnect, it's back to hanging at connect(). Therefore there > > definitely appears to be some kind of connection management problem > > when running 2.2. > > - If I make 2 connections on the incredible, then close one, I can > > open another. All closing/opening works fine as long as I'm only > > trying to manage 2 connections. > > > Anyways, as I said, if anyone can confirm that I simply cannot use my > > 2.2. device for testing more than 2 concurrent connections, that would > > be very helpful. > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
