nearby-connections | Nearby Connections is a high level protocol | Wifi library

I am using NearBy 2.0 API version 'com.google.android.gms:play-services-nearby:12.0.1' with android things 'com.google.android.things:androidthings:1.0' to create a smart home app, but previously upto 8th may it was working fine with the build downloaded from android things console, but from yesterday it is throwing com.google.android.gms.common.api.ApiException:8007 STATUS_BLUETOOTH_ERROR. when I am starting advertisement or discovery whichever maybe. But if I use the previous build (image with apk) of 8th may it is working fine. I tried with that old apk also like new os image with old apk, found not working. In logcat I found it is unable to start listening for incoming connections.

I searched SO and google a lot but no solution worked. Even followed this Error codes in Nearby Connections 2.0 but no luck. I am using Raspberry PI 3 model B. Help!!

I've been experimenting with the new Android Nearby Connections v2.0 API. Most of my devices can now talk to each other most of the time, but I also get a lot of error codes back when trying to connect. Checking status.getStatusCode() inside my program, I can see the following return codes:

• STATUS_ALREADY_CONNECTED_TO_ENDPOINT (8003)
• STATUS_BLUETOOTH_ERROR (8007)
• STATUS_ENDPOINT_IO_ERROR (8012)
• STATUS_ERROR (13)

I'm having a hard time making sense of these. The first error code seems self-explanatory, except that I see it in cases when I haven't hit the onConnectionResult callback with a "SUCCESS" return code on either side of the alleged connection. My current code is full of trace statements, and I'd see logging entries if those callbacks had been reached. So maybe the devices are connected at some lower level, but if so, the higher-level code doesn't always hear about it.

I'm guessing that STATUS_BLUETOOTH_ERROR indicates a Bluetooth error on the side that logs it, while STATUS_ENDPOINT_IO_ERROR indicates an error (probably involving Bluetooth) on the other end? Is it possible to get any more details? The STATUS_ERROR (13) status that I see once in a while sounds like the sort of error code a programmer would use for those "WTF, we should never get here" moments, but without access to the source code, I can only guess.

Note that I see these errors between devices that talk to each other beautifully at other times, using the same code. Sometimes if the code retries enough times, it eventually gets a stable connection. Sometimes it connects and gets instantly disconnected from the other end. Sometimes I just get an endless stream of repeated error messages (STATUS_BLUETOOTH_ERROR and/or STATUS_ENDPOINT_IO_ERROR).

I'm using Nearby Connections with the connection strategy P2P_CLUSTER. These problems seem to happen most often when both sides do both advertising and discovery. However, I wrote two smaller programs that specialize in either advertising or discovery, and they sometimes get these errors too (but less often).

In the trace messages, I've also noticed lots of warning messages from Nearby Connections that look like this:

I'm wondering if it's possible to have a Bluetooth connection only in Googles Nearby-Connections API.
The problem is, if i have a running hotspot for my notebook, google Nearby will cut off the connection.
If I use the connections-activity from github, it will raise a hotspot after the acceptConnection() function.

I'm trying to use the new Android Nearby Connections v2.0 API with the P2P_CLUSTER connection strategy. The following problem (in which both devices request connections, but don't successfully connect) seems to occur on a variety of devices running Android K-N. Sometimes the code gets a successful persistent connection... Sometimes it doesn't.

In this scenario, both sides are advertising and discovering, both sides discover each other, and both sides send connection requests (but connection is not initiated). It's difficult to make this situation happen reliably with a specific test case, but it does happen.

Using Android Monitor, I've captured detailed information about what this scenario looks like from one side, and listed the sequence of events below. In this particular session, the device that I was monitoring was a very cheap KitKat phone, and the remote endpoint was a Samsung Lollipop tablet (in case that's relevant).

• The remote node is discovered, and we issue requestConnection

• Immediately afterward, Android Monitor shows this error:

  ...

I've been experimenting with the new Android Nearby Connections v2.0 API, and have some questions about the Connection Strategies used for advertising and discovery. These questions involve strange edge cases, and might not be easy to answer. But when I mentioned these potential problems in a comment on another post, a Nearby Connections developer requested that I create a separate question about these issues. This question concerns some strange (but somewhat unnatural) edge cases that I've thought of (but which normal developers doing ordinary things would be unlikely to encounter).

The documentation contains this slightly ambiguous statement: "Nearby Connections supports different Strategies for advertising and discovery." Initially, I interpreted this to mean that we can select one of the two available connection strategies, and use this for both advertising and discovery. Since the connection strategy defines the (local) connection topology at a specific node, it makes sense that we would need to use the same connection strategy for both advertising and discovery.

However, one could also interpret the ambiguous statement to mean that one can (literally) use different strategies for advertising and discovery. This seems absurd, but there doesn't seem to be any mechanism to actually force the strategies be the same. Since both startAdvertising() and startDiscovery() take a "strategy" parameter, it's quite possible to pass a different strategy to each.

Note: I've figured out an answer to the above question experimentally. If the advertiser and discoverer are using mismatched strategies, the discoverer's onEndpointFound callback is never reached (so I'm guessing that the lower-level code must realize that there's a mismatch and never send it up).

Another question: Is a heterogeneous network (with a mixture of strategies) possible? Since the connection strategy affects the means of communication used between two connected nodes (P2P_CLUSTER using low bandwidth for small data transfers, and P2P_STAR using both Bluetooth and Wifi Hotspots for higher bandwidth), it seems like in order for two nodes to connect, both would need to use the same strategy.

As mentioned earlier, experiments suggest that both nodes do need to use the same strategy in order to connect. However, I could imagine another edge case in which device A connects to device B in using the "Cluster" strategy, switches strategies (while keeping the connection open), and connects to device C using the "Star" strategy. Would this work? I don't know. Since my current test program restarts after configuration changes, I'd need to write new code in order to test this edge case (and I've got lots of other code that I'd rather be writing). But the Nearby Connections developer was interested in hearing about potential edge cases, so I'm mentioning this here.

These questions came up while I was trying to debug other connection problems. To make my experimental program more versatile, I added a Settings option for the connection strategy, and another Settings option controlling whether the program should just advertise, or just discover, or both. And then I had to decide what should happen when these setting change.

Would it suffice to just stop advertising/discovery and then restart whatever's specified, using the requested strategy? But then what would happen with any existing connections leftover from the previous strategy? This answer doesn't seem obvious.

Maybe these questions would only come up in an artificial scenario like my test program (which I only wrote because I was trying to understand other connection problems). In a final product, I'd probably just pick one strategy and use it consistently. And if Nearby Connections were open-source, I'd just look at that code to learn what might happen in these strange edge cases. But since I can't look at the source, it would be nice to see a little more documentation about expected behaviors

I've been trying to get an example working on a few emulated devices, and it hasn't been easy: Bluetooth isn't supported on emulators, so I thought it would auto-fall-back to WiFi, or even supersonic communication? But even after getting permissions working (yay), it dies with the following.

I'd like to do fun things with Android Nearby Connections 2.0, but I wasn't clear from the announcement which of the technologies (messaging, file transfer, socket-like comms, etc) can have a non-android endpoint. For example, if I want my android phone to control my LeJOS (java) legos, can I? Or do all endpoints (even the whiteboards, RC cars, etc) need all endpoints to be Android (or Android Things) OS?