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.
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.
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:
open the applications settings, search for the Android Wear application, then force stop it
clear its data and cache
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".
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.
reboot your phone
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…
If you're on a Mac try this before you go resetting everything unnecessarily (note the 127.0.0.1 instead of localhost):
adb forward tcp:4444 localabstract:/adb-hub
adb connect 127.0.0.1:4444
When localhost resolves to both ::1 (IPv6) and 127.0.0.1 (IPv4), connecting to 127.0.0.1 may help on Linux as well, not just Mac:
$ adb forward tcp:4444 localabstract:/adb-hub
$ adb connect localhost:4444
unable to connect to localhost:4444: Connection refused
$ adb connect 127.0.0.1:4444
connected to 127.0.0.1:4444
$ adb devices
List of devices attached
127.0.0.1:4444 device
...
$
Related
I'm developing a script that permits to connect to the internet through a Mediatek MT7612U wifi adapter (Alfa AWUS036ACM) and making some connection tests using speedtest-cli, iperf3 ...
My script is running under OpenWrt linux system. I installed Openwrt in a raspberry PI4 Model B. I plugged to the raspberry two wifi adapter (Alfa AWUS036ACM with Mediatek MT7612U chipset).
The script is running permenantly, and making periodically some connection Tests. After a period of time I lost the connection.
When I checked the system log I found this error reported by the kernel:
kern.err kernel: [ 1929.020945] mt76x2u 2-1:1.0: error: mt76x02u_mcu_wait_resp failed with -110
The issue disappear when I reboot the system. But I need to fix it without rebooting.
I tried to reset the usb device with ioctl USBDEVFS_RESET but that caused the lost of corresponding network interfaces,
I tried also to poweroff/poweron the usb device with commands like that:
echo disabled > /sys/bus/usb/devices/usb2/power/wakeup
echo enabled > /sys/bus/usb/devices/usb2/power/wakeup
but the issue is not fixed
I tried also to unbind/bind the usb device
echo '2-1' > /sys/bus/usb/drivers/usb/unbind
echo '2-1' > /sys/bus/usb/drivers/usb/bind
and the issue is not fixed also
Has someone an idea why I got this blocker issue. Is there an idea to fix or bypass it without the need to reboot the system.
I've also been getting this exact issue. I've also been using the Alfa AWUS036ACM.
I've tried unplugging the adapter and that resets it, then after putting it into monitor mode again it works for a short while before failing with the issue OP has again. I'm using a Raspberry Pi 3b
I have Raspberry Pi 3 model B
OS: Raspbian(jessie)
I want to create a connection from my smartphone to a headless raspberry, and connect the headless raspberry to a network(which the smartphone is conencted).
like the vacum cleaner robot (IRobot) or Web camera which has an app, or any device that needs an initial connection to setup it's network.
the initial connection needs to be from a remote device, mainly a smartphone app.
What did i try:
1. bluetooth - i've managed to setup the bluetooth in the raspberry. when i try to connect, a popup appears on the raspberry which ask to confirm connection, because the raspberrry needs to be headless, this option is not good for us.
if i set the bluetooth as follow: sudo hciconfig hci0 sspmode 0
when i try to connect to the raspberry, a popup appears in the smartphone required a PIN code, this option may be good, if i new the PIN code.
2. P2P - i try use wifi direct from my smartphone
i've create file called p2p.conf inside /etc/wap_supplicant
inside this file i wrote the following:
ctrl_interface/var/run/wpa_supplicant
update_config=1
device_name=raspberry
device_type=1-0050F204-1
driver_param=use_p2p_group_interface=1
p2p_go_intent=1
p2p_go_ht40=1
then stop the wpa_supplicant and change
sudo wpa_supplicant -B -iwlan0 -Dnl80211 -c/etc/p2p.conf
i've started wpa_cli
and then p2p_find
it's started scanning
when i search from the smartphone for the raspberry, i found the raspberry, when i try to conenct it asks me for PIN code, the PIN code is showen in the raspberry wpa_cli.
two problem i have from this option:
1. the network needs to be connected.
2. the PIN code changes, and i can't make it fixed.
Is there a way to make an initial connection to setup a network from the smartphone to a headless raspberry?
I have been using a Raspberry Pi 3 along with IBM Watson IoT platform and was just deploying some flows. However, I think I may have mixed up the device id between Gateway and Device.
When I registered my Raspberry Pi as a Device and a Gateway, I gave both connections the same Device ID. In hindsight, I can see why this might have been stupid. I am just going to disconnect all connections and create two new connections. However, I have a different problem right now. Whenever I try to launch NodeRed from my Raspberry Pi, I get the following log
3 Feb 17:07:27 - [error] IBMIoT: Error: Connection refused: Not authorized
[BaseClient:connect] Iotfclient is offline. Retrying connection
[BaseClient:onClose] Connection was closed.
This just keeps repeating over and over again, and I have no idea what to do to fix it.
That suggests you still have an IoT node in your flow with the incorrect credentials.
Assuming you are running Node-RED 0.15 or later, open the search dialog (Ctrl-. on 0.15 or Ctrl-F on 0.16) and search for ibmiot. That will reveal any existing configuration nodes you have. Clicking on one in the search results will reveal it in the Config node sidebar tab. Double click on it and either delete it or correct the credentials.
If you're on an older version (I suggest you upgrade), you can open the config node sidebar from the dropdown menu and manually look for the ibmiot nodes.
last week I started to develop apps for a Samsung Smartwatch with the Tizen SDK 2.4.0. My sample web application connects to a remote Websocket server (a simple echo server) and sends some random requests and prints the received messages (Server is http://www.websocket.org/echo.html). This works fine on an emulated devices as well as on the real Gear S2 Smartwatch (Example was taken from https://developer.tizen.org/zh-hans/development/tutorials/web-application/w3chtml5supplementary-features/communication/websocket?langredirect=1)
But as soon as I start a Websocket server in my home LAN I run into problems. The server is launched via a simple Python example I found on Github (https://github.com/dpallot/simple-websocket-server). The emulator device from the SDK connects to this server without any problems using the local IPv4. But the real device, which is logged in to the same WiFi access point, doesn't.
Note that the connection between my PC and my watch device works fine, since the SDK flashes the developed apps via WiFi to the device.
In my config.xml all connections are allowed
<access origin="*" subdomains="true"></access>
and the privilege for "Internet" is available.
The logs show that the watch tries to open a connection, but is then stuck. No error message is printed - the watch just does not go beyond the initial creation of the websocket.
Do you have any hints or thoughts about how I could debug this issue?
Thanks in advance!
I found the solution - my virus scanner has an integrated software firewall that blocked incoming connections...
Try with higher ports maybe ? I got WS working fine on SamsungZ1 on Tizen:2.3:Mobile
https://twitter.com/RzrFreeFr/status/70135763074535014#tizen-gear2-websockets
Maybe I could try your code on Tizen:2.4:Mobile too ?
I have an unpublished custom receiver app, and I am unable to cast to it from my web player sender app in chrome. I do get the receiver "available" message upon initialization of cast api, but when I click on the cast button in player and select the chromecast device from drop down menu in extension, the TV screen goes black and few seconds later I get onError method called with following error:
{code: "channel_error", description: "Error: Timeout", details: null}
The casting works fine when using default media receiver. Also, I do not see any network traffic coming from chromecast device in my server console log, which means that chromecast is not fetching the receiver application.
I made sure of the following:
The Chromecast dongle is registered as Cast Receiver device in Cast
Developer console.
My macbook has NodeJS server running to serve the
receiver application and the "Receiver Application URL" in cast
developer console is correctly pointing to server running on my
macbook.
The chromecast and my macbook both are on same network, with
valid 192.168.x.x IP addresses.
I found another thread discussing this error Chromecast sample sender application CastHelloText-chrome ends with error when trying to get session, but the suggestions provided there dont seem to apply to my situation.
I was able to resolve this particular error by restarting the chromecast device. I tried it on two separate occasions and both times the issue went away once the device was restarted. I can't explain how it worked, but it did the job. If someone can explain what is the cause of this particular error and why restarting fixes it, I will accept that answer.