summaryrefslogtreecommitdiffstats
path: root/core/java/android/server/BluetoothEventLoop.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
commit16fb88a673c41b93c5d57ccb28c2697e7d87701a (patch)
treef6c32d70ca192de4fd6608c931b501263de2766b /core/java/android/server/BluetoothEventLoop.java
parent64dd5be583bab8218e54068bbf70edc5fc6087c8 (diff)
downloadframeworks_base-16fb88a673c41b93c5d57ccb28c2697e7d87701a.zip
frameworks_base-16fb88a673c41b93c5d57ccb28c2697e7d87701a.tar.gz
frameworks_base-16fb88a673c41b93c5d57ccb28c2697e7d87701a.tar.bz2
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 24bb9b8af4ff6915 - 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 'core/java/android/server/BluetoothEventLoop.java')
-rw-r--r--core/java/android/server/BluetoothEventLoop.java27
1 files changed, 22 insertions, 5 deletions
diff --git a/core/java/android/server/BluetoothEventLoop.java b/core/java/android/server/BluetoothEventLoop.java
index 0152223..da1918a 100644
--- a/core/java/android/server/BluetoothEventLoop.java
+++ b/core/java/android/server/BluetoothEventLoop.java
@@ -55,6 +55,10 @@ class BluetoothEventLoop {
private static final int EVENT_RESTART_BLUETOOTH = 2;
private static final int EVENT_PAIRING_CONSENT_DELAYED_ACCEPT = 3;
+ private static final int CREATE_DEVICE_ALREADY_EXISTS = 1;
+ private static final int CREATE_DEVICE_SUCCESS = 0;
+ private static final int CREATE_DEVICE_FAILED = -1;
+
// The time (in millisecs) to delay the pairing attempt after the first
// auto pairing attempt fails. We use an exponential delay with
// INIT_AUTO_PAIRING_FAILURE_ATTEMPT_DELAY as the initial value and
@@ -550,14 +554,27 @@ class BluetoothEventLoop {
mBluetoothService.updateRemoteDevicePropertiesCache(address);
}
mBluetoothService.sendUuidIntent(address);
+ mBluetoothService.makeServiceChannelCallbacks(address);
}
- private void onCreateDeviceResult(String address, boolean result) {
- if (DBG) {
- log("Result of onCreateDeviceResult:" + result);
- }
- if (!result) {
+ private void onCreateDeviceResult(String address, int result) {
+ if (DBG) log("Result of onCreateDeviceResult:" + result);
+
+ switch (result) {
+ case CREATE_DEVICE_ALREADY_EXISTS:
+ String path = mBluetoothService.getObjectPathFromAddress(address);
+ if (path != null) {
+ mBluetoothService.discoverServicesNative(path, "");
+ break;
+ }
+ Log.w(TAG, "Device exists, but we dont have the bluez path, failing");
+ // fall-through
+ case CREATE_DEVICE_FAILED:
mBluetoothService.sendUuidIntent(address);
+ mBluetoothService.makeServiceChannelCallbacks(address);
+ break;
+ case CREATE_DEVICE_SUCCESS:
+ // nothing to do, UUID intent's will be sent via property changed
}
}