aboutsummaryrefslogtreecommitdiff
path: root/framework/java/android/bluetooth/BluetoothClass.java
diff options
context:
space:
mode:
authorNick Pelly <npelly@google.com>2009-10-07 07:44:03 +0200
committerNick Pelly <npelly@google.com>2009-10-07 23:25:24 +0200
commit07b84cb5bb5283352a27cc0cf651586ed00035a0 (patch)
tree62ef30e6b0c78badc1cc88ff0abc919e1abff5c2 /framework/java/android/bluetooth/BluetoothClass.java
parent1e79198aafef8cde937694e6fdbd863acf4f7b8a (diff)
Encourage developers to connect RFCOMM by UUID instead of Channel.
Hide createRfcommSocket(int channel) Add createRfcommSocketWithServiceRecord(UUID uuid) Rename listenUsingRfcomm(String,UUID) -> listenUsingRfcommWithServiceRecord(..) Now we have a complete API for developers to make peer-peer RFCOMM connections with hard-coding the limited (30) RFCOMM channels, instead using SDP lookup of an UUID. This commit addresses two serious bugs: - Do not throw IOException on accepting an incoming RFCOMM connection with BluetoothSocket. This was a regression from commit ee1402d8d697be3a - Workaround failure of bluez to update SDP cache when channel changes by trying to use the same RFCOMM channel on the server every time, instead of picking server channels randomly. This is a pretty ugly workaround, and we are still trying to fix the caching issue - but with this workaround we are at least shippable and apps will work at least until they start colliding on the 30 RFCOMM channels. DrNo: eastham Bug: 2158900 Joke: What did the digital watch say to his mom? "Look mom no hands." Change-Id: Ia4879943b83afac06b6f1a3f2391cf1628afce7d
Diffstat (limited to 'framework/java/android/bluetooth/BluetoothClass.java')
0 files changed, 0 insertions, 0 deletions