Hi, I can't confirm it is just 2.2 but I have had similar experiences & I have not been able to get more than four phones to connect via bluetooth reliably on any version of Android in a single server many clients arrangement. I have not tried a daisy chain configuration where each phone just connects to it neighbour but I suspect this might work better, maybe up to the magic seven devices ?
Let me know if you can get more than 4 devices working together. I've found the BT implementation / connection reliability varies wildly across different Android phones & tablet, ranging from good through bad - Nexus S, Nexus One, Xoom, EVO 3D, Galaxy S2, LG G2X (G2X only device with Android 2.2). I often find I need to reset the bluetooth disable/enable on some of the latter to get reliable connections. Regards On Sep 13, 1:37 am, novakom <[email protected]> wrote: > 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-bluetoothsoc...) > 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
