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:
09-04 22:54:40.070 3866-3924/? W/NearbyConnections: Cannot deserialize BluetoothDeviceName: expecting min 16 raw bytes, got 6
I'm guessing that this is because Nearby Connections uses its own short tokens (like ZGbx) instead of the device Bluetooth name? I'm not at all sure about that, though. And anyway, if these are Nearby Connections' own special tokens, then why would it be issuing warning messages about it?
[Disclaimer: I work on Nearby Connections] I can try and help out.
STATUS_ALREADY_CONNECTED_TO_ENDPOINT: This occurs if you call 'requestConnection' while you have any pending (onConnectionInitiated) or established (onConnectionResult) connections to the given endpoint. Move your log statements earlier, to onConnectionInitiated, and you should see why we throw this error.
STATUS_BLUETOOTH_ERROR: Something went wrong with Bluetooth. The phone is probably in a bad state. This (hopefully) shouldn't happen too often. But if you really want a fix, stop advertising & discovery before reattempting requestConnection. Nearby Connections will toggle Bluetooth when it detects this error, but only if nothing else is going on.
STATUS_ENDPOINT_IO_ERROR: We lost connection to the other device. This can happen for a variety of reasons (they could have walked too far away, Bluetooth was flaky, the device stopped responding, etc). If you're discovering while you have connections, avoid that. Discovery can be hard on the phone and reduces bandwidth at best, causes dropped connections at worst.
STATUS_ERROR: Something went wrong that didn't fit well in the other error codes. It's a catch-all. This is most-often returned in onConnectionResult(FAILED), to notify you that something went wrong in between onConnectionInitiated and waiting for both sides to accept the connection.
We've also lowered the log severity of "Cannot deserialize BluetoothDeviceName" in an upcoming release, since it's not really a warning. It's like you said; expected behavior when we see non-Nearby Connections devices while discovering.
If you continue to see problems, let us know what devices you're using and we'll be sure to add them to our test suite.
I just want to add that it may be necessary to have a short client name string when calling the API.
E.g., Nearby.Connections.requestConnection(googleApiClient, shortNameHere,....)
I had been generating my own client name with UUID.randomUUID().toString() and that seemed to cause the STATUS_BLUETOOTH_ERROR.
All I did was change the code sample to use a UUID name and to use P2P_CLUSTER and I got that error.
This was the solution for me regarding the STATUS_BLUETOOTH_ERROR.
Related
In my Android app, I do poll a device (Wallbox) every 5 seconds using the Volley library. For one customer, I get
java.net.NoRouteToHostException: Address not available
after several hours. Usually, using the exactly same type of device and at my place, this polling works for days, but not at (at least) this customer.
The device address is on the local LAN.
I have not found any description about "address not available" that might apply to my case, or at least I did not see the point.
The call is always the same:
http://192.168.160.152/api/status
As this is live data, I set ".setShouldCache(false)" for the request.
Meanwhile, other HTTP requests (in this case, a query to a WWW address, also polled continuously), even using Volley, continue to work:
https://backend.powerfox.energy/api/2.0/my/***********/current
The connection works again after rebooting the device (and at the same original IP address), so I guess it has nothing to do with the wallbox or the router.
And if the wallbox would be not available, I assue I would get "unreachable" error or such.
Is there someone who can help me, what could cause that exception ("address not available"), and what can I do about it?
I'm developing an adaptation for an android app, to communicate with a remote control, which has some pre defined commands.
I've followed this implementation to do the Bluetooth communication and it's working fine for sometime.
This app should communicate with the remote control every 5 minutes or less, and I've been using the app for almost 6 months now. The last week I've some command clashes problem and looking at the logs I couldn't identify why did that happened. The last time that this had happened the app was running for more than 24h, communicating with the remote control, without any communication issue.
Two of it's commands have some similar characters, the first one that have to be done, to establish the connection.
OK_CONN
And an sniffer command which keeps the pilot awake listening for some sensor data:
N
Looking at the logs I can see the answer for command N, after applying the command OK_CONN.
Is it possible for a Bluetooth command to lost part of it's data, during an established communication or am I doing something wrong when writing to a characteristic? Should I change the command names to avoid this kind of clash?
I'm using android 9, at a Sony XPeria XZ phone.
Edit to clarify #Emil comment
07:02:12.880 [BleThread] writing <OK+CONN> to characteristic
07:02:12.368 [Binder:19249_F] [onCharacteristicChanged():274]:
n command confirme
Looking at the logs I see that the last written command as an ok_conn but it has written only the N, this is been show as the last line, it has confirmed to receive the n command alone, instead of receiving the full data of ok_conn.
By name clashes I mean that maybe the last N of the ok_conn command is been accepted as the command.
I just realized what's going on, you can post that as an answer #Emil, my problem was at the logic that sends the first command, sometimes I send this command and the micro controller is not started yet, that's probably the reason of it getting only part of the command.
Not sure what you mean by name clashes, but Android will always write what you told it to write, without packet loss, as long as you follow the rules to never have more than one outstanding operation (always wait for callback before you send the next operation) and that your data must fit within the maximum length for the corresponding operation.
I have implemented successfully the pires/obd-java-api OBD Interface in an Android app and everything works as expected, expect that after about 1.000 - 1.500 API calls, the API stops responding.
Did anyone come across the same problem?
Is it maybe necessary to send a reset command to the OBD dongle after some time?
I thought it might be that the API is collecting data and a memory problem occurs, but onTrimMemory is never called.
I assume API means Standard Pids(mode 1)then OBD will not response in following case
1: TimeoutCommand is too low, set 255
2: may be not proper power supply
Note: ResetCommand is used as initial command once before fetching real time data.
you can refer android-obd-reader sample app:
https://github.com/md-sohrab-alam/android-obd-reader
Since couple of weeks this exception appears sometimes on my App:
Non-fatal Exception: com.facebook.FacebookAuthorizationException: CONNECTION_FAILURE: TigonError(2): TigonLigerErrorDomain(2) AsyncSocketException: connect failed (immediately), type = Socket not open, errno = 101 (Network is unreachable)
at com.facebook.login.LoginManager.onActivityResult(LoginManager.java:218)
at com.facebook.login.LoginManager$1.onActivityResult(LoginManager.java:173)
at com.facebook.internal.CallbackManagerImpl.onActivityResult(CallbackManagerImpl.java:95)
at com.myapp.util.connect.FacebookConnect.onActivityResult(FacebookConnect.java:338)
Facebook SDK: 4.27.0
Android version's impacted: 4.4.2 and 7 (Crashlytics informations)
Have you got some ideas guys about this exception?
Thank you very much
UPDATE
I wrote a ticket on Facebook support, and after several messages, the last is:
Hi Anthony, thanks for the additional details. Looking at the data for your app,
there don't seem to be any failed API calls logged for your app. This indicates
that the login attempts failed before they reached our servers, and confirms
that this was indeed due to network errors.
I agree that it's not the ideal experience for users to have to retry their
login attempt, but in the case of network-related issues like this, this is the
best approach. I would recommend prompting the user to check their device
connectivity and initialize the login flow again.
From debugging this, it's unlikely that this is due to compatibility issues with
Retrofit, though I can't rule it out with certainty. It's more likely that the
affected users simply experienced a temporary drop in connectivity.
I'll mark this as closed since there doesn't seem to be a bug within the
Facebook SDK, but if you're able to get any information that would indicate
otherwise (for example, a way to consistently reproduce the error on a device
that has full internet connectivity), please let me know and I'll be glad to
help look into this again.
This exception means that user of your app is experiencing problems with his Internet connection. It is a problem that all the developers should care when making network calls, but it is especially important for mobile devices (the quality of mobile internet can be significantly low). Unfortunately netwok errors cannot be eliminated completely.
The common way of solving such a problem is making retries: either on the side of the app (retrying, showing user an error only after several network errors), either on the side of the user (suggesting user to try once more).
i am trying to develop a cordova(3.5.0) project in android platform and in that i have to check network connection availability before each API call. for that i am using 'navigator.connection.type',and some times it return 0. why this is happening? plz help me for solving this trouble
Without some more details I can only guess.. There are some conditions which may cause this.
navigator.connection.type = 0 -> connection type unknown.
So you may have a connection, you may not it simply hasn't been determined yet, or because of privileges the device isn't saying.
Are you calling this check too early? ie before deviceready
In our app we do not check the connection each time but we handle it this way:
by making the API request anyway, knowing that its possible to fail, we set a timeout and error handling. If it fails by error or timeout we check connection type and then ping the server with a simple "hello" "acknowledge" request. Its a super small request that we figure will work or if it timeouts again the connection must be so poor it might as well be disconnected.
This is because there are really two types of connection you need to check. Many miss this!
And also because its navigator totally lies some times... :/
Just because wifi is on and connected and navigator tells you this, it doesn't mean you will have a connection to the outside world. You need to check the network hardware (which is all navigator will tell you) but you must also check network connectivity, if this is something you are sensitive about.