Why can't Android Wear connect target for debugging over Bluetooth?

Question

Whenever I activate debugging over Bluetooth on my wearable emulator, the device starts vomiting this error every 10 milliseconds on the console:

08-07 12:15:53.472   1484-29405/com.google.android.apps.wearable.settings W/AdbTargetService﹕ error during createTcpConnection
    java.net.ConnectException: failed to connect to localhost/127.0.0.1 (port 7272): connect failed: ECONNREFUSED (Connection refused)
            at libcore.io.IoBridge.connect(IoBridge.java:124)
            at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:183)
            at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:163)
            at java.net.Socket.startupSocket(Socket.java:590)
            at java.net.Socket.tryAllAddresses(Socket.java:128)
            at java.net.Socket.<init>(Socket.java:178)
            at java.net.Socket.<init>(Socket.java:150)
            at com.google.android.clockwork.settings.AdbTargetService$PipeControlThread.createTcpConnection(AdbTargetService.java:203)
            at com.google.android.clockwork.settings.AdbTargetService$PipeControlThread.access$400(AdbTargetService.java:81)
            at com.google.android.clockwork.settings.AdbTargetService$PipeControlThread$2.run(AdbTargetService.java:153)
            at java.lang.Thread.run(Thread.java:818)
     Caused by: android.system.ErrnoException: connect failed: ECONNREFUSED (Connection refused)
            at libcore.io.Posix.connect(Native Method)
            at libcore.io.BlockGuardOs.connect(BlockGuardOs.java:111)
            at libcore.io.IoBridge.connectErrno(IoBridge.java:137)
            at libcore.io.IoBridge.connect(IoBridge.java:122)
            at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:183)
            at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:163)
            at java.net.Socket.startupSocket(Socket.java:590)
            at java.net.Socket.tryAllAddresses(Socket.java:128)
            at java.net.Socket.<init>(Socket.java:178)
            at java.net.Socket.<init>(Socket.java:150)
            at com.google.android.clockwork.settings.AdbTargetService$PipeControlThread.createTcpConnection(AdbTargetService.java:203)
            at com.google.android.clockwork.settings.AdbTargetService$PipeControlThread.access$400(AdbTargetService.java:81)
            at com.google.android.clockwork.settings.AdbTargetService$PipeControlThread$2.run(AdbTargetService.java:153)
            at java.lang.Thread.run(Thread.java:818)
08-07 12:15:53.476    1229-1229/system_process D/ZenLog﹕ disable_effects: 0|com.google.android.apps.wearable.settings|11003|null|1000,listenerHints

In my code I send a message from wearable to handheld. The message is correctly sent, but the debugger doesn't stop at any breakpoints within the WearableListenerService class on the handheld module and seems that that code is not getting executed.

Complementary info:

• Device: Genymotion Samsung Galaxy S4, API 19, 4.4.4.
• Wearable device: ADV Emulator Square, API 21
• Same applicationId
• Same versionNumber
• Wearable project added as a dependency in handheld project as wearApp project(':wear')
• No <uses-permission> tags
• Android Wear installed via apk dropping on emulator: com.google.android.wearable.app-1.1.1.2016316-702016316-minAPI18
• Debug over bluetooth activated on handheld device and devices paired
• Host: connectedTarget: disconnected. It doesn't connect when I execute adb -s 192.168.56.102:5555 forward tcp:4444 localabstract:/adb-hub adb connect localhost:4444, however, a third useless device seems to be created in a perpetual offline status and it can't be used to run anything on it:

Nor Revoking permissions or factory reset (as suggested in the post Android Wear device selection box says "offline localhost:4444 minSdk (API 20) > deviceSdk (API 1)" ) are working.

Answer 1

It happens that I was misunderstanding everything. If you're using an emulated wearable, there is NO need to:

• Activate "Debugging over Bluetooth" in the wearable.
• Redirect ports with adb -s 192.168.56.102:5555 forward tcp:4444 localabstract:/adb-hub and adb connect localhost:4444.
• And even both target and host devices can appear as "disconnected".

All you need is to execute adb -s handheldDeviceName forward tcp:5601 tcp:5601 so the handheld is paired with the emulator and then you can start debugging without further concerns.

Trouble was that in Android Studio you can debug just one module at a time with the icon for debugging: .

If you want to debug both modules at the same time so you can trace all the breakpoints, you have to use the debugging button with one module and then attach a debugger to the other device .

Both devices will be available in the list displaying their proccesses once they are paired.

Answer 2

I had this problem with the moto 360 and solved with this tutorial:

http://melix.github.io/blog/2014/10/android-moto360.html

So you were looking at a solution, and here it is. Basically, the problem is that the Android companion app doesn’t store its settings under its cache. They are stored in the Google Play Services space, so here is the procedure that worked for me, and I sincerely hope it will do for you. On your handheld:

1. open the applications settings, search for the Android Wear application, then force stop it

2. clear its data and cache

3. now search for Google Play Services (depending on your language settings, it can appear with a different name, on m y device it is "Services Google Play".

4. click on Manage space. You will see that there’s a section for connected devices. I tried to clear data here, but it didn’t help, so you have to click on delete all data.

5. reboot your phone

6. reboot your Moto 360

I am unsure that the two last steps are really necessary, but I did it because I wanted to make sure that force stopping and clearing data did not introduce some weird behavior after that. When you reopen the Android Wear companion app, it should now be as if it was the first time you opened it and ask you to associate it with your watch. Do it, and now, you should be able to follow the normal procedure described in the Android documentation and…