diff options
| author | Nick Pelly <npelly@google.com> | 2009-10-07 07:44:03 +0200 |
|---|---|---|
| committer | Nick Pelly <npelly@google.com> | 2009-10-07 23:25:24 +0200 |
| commit | 16fb88a673c41b93c5d57ccb28c2697e7d87701a (patch) | |
| tree | f6c32d70ca192de4fd6608c931b501263de2766b /core/java/android/server/BluetoothEventLoop.java | |
| parent | 64dd5be583bab8218e54068bbf70edc5fc6087c8 (diff) | |
| download | frameworks_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.java | 27 |
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 } } |
