I tried at making a socket with an Android NDK wrapper, passing the file descriptor to Java to be used with a recv wrapper. The target user should not require Single User. The recv call does not receive any data. Why?
TCP sockets can not be read without a connection, because they require sequentiality. UDP packets were not being received either. RAW sockets were, of course, not being successfully made. My code had more bugs than a restaurant's dumpster, I was calling shutdown instead of close... not sure why. It's April fools, and usually I delete questions once I realize I'm being an idiot and wasting people's time; but today I have a bounty on this question, so I think I'll revisit this idea for a bit and post better code. Check back later if you're still interested.
Android doesn't support reading from unconnected sockets.
TCP doesn't support reading from unconnected sockets, or writing to them either. Your socket is of type SOCK_STREAM, and you are calling shutdown() on it, so it must be a TCP socket.
NB:
shutdown() doesn't close the FD. You must also call close().
recv() returning -1 doesn't necessarily mean 'socket closed'. You need to look at the value of errno to decide what it does mean.
Your title 'Java Native Socket Not Persistent' has nothing to do with your question.
Related
im trying to control a bluetooth bracelet with vibration function via HFP (hands free profile) in Android. I've been able to connect to the bracelet and access the input- and outputstream.
My goal is to simulate an incoming call so that the bluetooth bracelet starts vibrating (which seems to be the only way to do that). To do this, im using AT commands. In the bluetooth specs at https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=238193 on page 22 you can see the handshake to establish service level connection.
I need to establish this connection to use the "+CIEV" command (see handshake page 48).
But when my bracelet returns the command "AT+CIND=?" I dont know how to respond. I can't find any hints on how to answer with the "CIND:" command. Also I dont know how to send the acknowledgement (is it just "OK"?).
That might even be the completely wrong way to do this. Every suggestion is appreciated. I only found one post on stackoverflow that helped me in some way, rest of the posts I found were unanswered.
By the way, im using a smartphone with Android 4.1.2. The bracelet supports HFP and HSP. Thanks in advance.
UPDATE 10/29/2014
===== Connection through RFCOMM Socket established at this point =====
// read AT+BRSF=0 from device
byte[] buffer = new byte[200];
mBluetoothSocket.getInputStream().read(buffer);
Log.d(TAG, new String(buffer).trim());
//write answer BRSF: ...
mBluetoothSocket.getOutputStream().write("+BRSF=20\r".getBytes());
mBluetoothSocket.getOutputStream().write("OK\r".getBytes());
// read AT+CIND=? command
buffer = new byte[200];
mBluetoothSocket.getInputStream().read(buffer);
Log.d(TAG, new String(buffer).trim());
//write answer CIND: ...
mBluetoothSocket.getOutputStream().write("+CIND: (\"battchg\",(0-5)),(\"signal\",(0-5)),
(\"service\",(0,1)),(\"call\",(0,1)),(\"callsetup\",(0-3)),
(\"callheld\",(0-2)),(\"roam\",(0,1))".getBytes());
mBluetoothSocket.getOutputStream().write("OK".getBytes());
// read AT+CIND?
buffer = new byte[200];
mBluetoothSocket.getInputStream().read(buffer);
Log.d(TAG, new String(buffer).trim());
Following the procedure of the protocol, I should receive the "AT+CIND?" command and then I could send the command "+CIND: 5,5,1,0,0,0,0", but...I dont receive the "AT+CIND?" command. Actually im not receiving anything. Am I missing something? Sending an "OK" doesnt change anything btw...
I was fiddeling with exaclty the same problem. After days of trial and error, I finally got it to work.
I think it depends on the speed at wich you answer the HF's commands, as well as on the correct line-endings ("COMMAND").
Here is my DroidScript which works. It's not cleaned up, but it works.
https://gist.github.com/t-oster/68a568ac4c4e133f67ac
Also, the one example I found that seemed to almost work, it's expecting the responses to be top and tailed with crlf:
"\r\n+BRSF=20\r\n"
"\r\nOK\r\n"
Still struggling with the rest of it myself.
refer to bluetooth hfp 1.5 spec in which you can understand CIEV response
normally when not in any call setup, response can be +CIND = 1,0,0,0,5,0,5
Note these values are based on the hfp spec, on incoming call return +CIEV: ,
ind- indicator for callsetup and value as 1 and then RING commands to the bracelet
My BLE application requires computation on the server side (BLE chip) which takes time and results with disconnection.
Th flow is like this:
1- Android phone writes the characteristic value to the BLE chip.
2- The chip evaluates this value and starts computation.
3- The connection is lost soon after the computation has started.
What solution can I apply to prevent the disconnecton? I have two solutions in my mind:
1- Changing the connection interval: Currently Android uses 7.5 msec as connection interval. Since the computation on BLE chip takes time, packets are not sent or received during the computation. Increasing the connection interval will decrease the number of lost packets. However there is no guarantee that Android phone will accept the new connection parameters.
2- Running the computation in a separate thread: I dont think that BLE chips' SDK support multi-threading such that while there is a computation process going on, it will keep receiving and sending packets and prevent the disconnection. I use CSR chip and I think it doesnt support.
Please correct me if I am wrong at my points.
Do you have any other suggestions to solve the issue?
Thanks in advance.
Thank you for the answers. I found out what the problem is after spending hours.
First of all, when Android gives error 133 or 129, it is most probably because of the remote device.
At the beginning I thought that the problem occurred because of the supervision timeout. Then I re-configured the connection parameters of the CSR chip but it didn't help.
There is a problem about CSR app development with xIDE (IDE of CSR). When there is run-time-error due to index overshoot or accessing some invalid pointers, then you would not receive any errors in xIDE. I finally found out the array problem and fixed it. Now it works perfect.
Thanks a lot!
I don't know exactly if what i going to explain it's feasible under Android because I used BLE only with a low level applications, anyway if your problems are the connection parameters you can try to change the Slave_Latency.
It should be usefull since playing with this parameter, you can change the number of connection intervals in which the Central device can wait until it considers the connection lost.
The following equation is usefull to derive the connection parameters:
Effective_Connection_Interval = (Connection_Interval)*(1+(Slave_Latency))
Remember that can exists some kind of Supervision_Timeout that can collide with your Effective_Connection_Interval
I am stuck at a place where my Android Phone(Samsung Galaxy) has to open 2(or more) connections to my PC(server) which is a paired device. For this purpose, I start SDP server on PC with UUID : 00001101-0000-1000-8000-00805F9B34FB and channel 2, after the first connection I unregister the SDP service on the PC and register it again on channel 3(and same UUID) and expect my android phone to 'connect' to it for establishing the second bluetooth connection. The second one fails.
The problem as I have figured out is that because of the pairing, the channel num and UUID of the device for the 'BluetoothSocket.connect' are serviced from cache and are not being updated, so my SDP change in channel num on the server side is not visible here as it still tries to connect to channel 2(old one).
A workaround of this problem(found after a lot of frustrating attempts) might be to change the android.server.BluetoothService.java file, by introducing
updateDeviceServiceChannelCache(addr) before returning in the getRemoteServiceChannel() and fetchRemoteUuids() so as to update the channel number at each func call.
The above solution may well be wrong, please pardon me for that. If it is correct please suggest any further changes and how to make this change permanent in eclipse, or in other case(wrong solution), the right way of doing this.
Note: I have android 2.3.5 and the requests from the device are actually from the browser that I forward to the PC. I want them on separate channels.
thanks.
My app needs to contact the same device it is working on, via http://127.0.0.1/... (a localhost url).
For some reason, about 50% of the times (and maybe exactly 50%) when I reach a website there with JSON content, I get the exception:
java.net.SocketException: recvfrom failed: ECONNRESET (Connection reset by peer)
For the other 50%, I get perfectly good results. I've tried to do polls (and even large delay between polls), but I keep getting the same weird results.
I've searched the internet and also here, and I'm not sure why it occurs. Does the peer mean that the client has caused it? Why does it happen, and how should i handle it?
Some websites say that it's a common thing, but I didn't find what's the best thing to do in such cases.
Ok, the answer was that it's the server's fault - it had to close the connection after each request.
It might be that Android keeps a pool of connections and use the old one or something like that.
Anyway , now it works.
EDIT: according to the API of HttpURLConnection, this can be solved on the client side too:
The input and output streams returned by this class are not buffered.
Most callers should wrap the returned streams with BufferedInputStream
or BufferedOutputStream. Callers that do only bulk reads or writes may
omit buffering. When transferring large amounts of data to or from a
server, use streams to limit how much data is in memory at once.
Unless you need the entire body to be in memory at once, process it as
a stream (rather than storing the complete body as a single byte array
or string).
To reduce latency, this class may reuse the same underlying Socket for
multiple request/response pairs. As a result, HTTP connections may be
held open longer than necessary. Calls to disconnect() may return the
socket to a pool of connected sockets. This behavior can be disabled
by setting the http.keepAlive system property to false before issuing
any HTTP requests. The http.maxConnections property may be used to
control how many idle connections to each server will be held.
Taken from:
developer.android.com/reference/java/net/HttpURLConnection.html
Try to set this property for your HttpURLConnection before connecting:
conn.setRequestProperty("connection", "close");
This will disable "keep-alive" property which is on by default.
This is an old thread i know. But this might help someone.
In my case this error was caused by the .NET WCF (soap) service. One of the objects in the returning result had a DataMember with get{} property but no set{} property.
For serialization to occur every DataMember should have both get{} & set{} available. I implemented an empty set{} (empty due to my business rules), and problem was solved.
My scenerio is a specific bad server implementation, but maybe it'll help someone saving time when troubleshooting.
I was having a lot of these Connection reset by peer when I was visiting certain web pages or downloading files (from my app or the Android browser).
Turned out it was my 3G carrier that blocked the connections (e.g. downloading an .exe file was forbidden).
Do you have the same problem on Wifi ?
in my situation the problem has been solved by cleaning the proxy address and port from APN which was produced by the operator.
as I have tested, using IP address of remote server instead of domain name also can solve the problem.
In our case the issue is in the Server side (Application Pool configuration in IIS). I resolved it by setting Maximum Worker Processes to 1. Setting it with value more than 1 will enable Web Garden which seems to be the issue.
I recently compiled ffmpeg and live555 for android, and built my own media client wrapper. The whole system works perfectly in all other systems (windows and linux), but not in android, just no UDP packets could be ever received. The RTSP communication works fine, which uses TCP connection. The session starts successfully, and keeps running in server. After searching for the similar topics, I see it seems that I have to acquire a multicasting permission with wifi at first. So I did:
- put permissions in AndroidManifest.xml
<uses-permission android:name="android.permission.CHANGE_NETWORK_STATE""/>
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.CHANGE_WIFI_MULTICAST_STATE"/>
- put following java codes in android Activity::onCreate()
WifiManager wm = (WifiManager)getSystemService(Context.WIFI_SERVICE);
if( wm != null ) {
mMCLock = wm.createMulticastLock( TAG );
mMCLock.acquire();
}
But it still doesn't work, the results are all the same in Emulator, in Galaxy S2 Phone and
in Galaxy Tab 10.1. Even I deactivate the live555 module, and just use ffmpeg ( ffmpeg has also its build-in rtsp client, but not as stable as live555, therefor, I ported live555 into android). The results are the same, rtsp ok, rtp not, where rtp uses udp as underlying carrier.
In DDMS is an error registered:
Address Family not supported by protocol
I think, the problem is that the UDP port is still blocked. Maybe getting multicastlock in
java is not enough for native code running in user kernel of android.
Does anyone has idea?
Steven
The UDP Problem in meinem RTSP client has been solved, there is nothing to do with permission and multicast lock. It is the bug inside android stl library implementation, provided in android-ndk-r7 and android-ndk-r8 both. Anyone wants to use gnu-libstdc++.so has to keep in mind: don't use string, especially string::c_str(), it leaves danger pointer in your stack, and damages everything. After I threw out every thing to do with stl, everything works fine, tcp and udp. A little off-topic: Inside the live555, there are at least 20 bugs, and the most fatal errors are: they used unblocked rtp over tcp, therefore, most packets are get lost before they reach the network interface, and at rtsp client, the rtp/tcp socket will never get the packets which are lost in the network interface, and then a rtsp session enters into endless receiving loop, it hangs.
I faced the same problem.
I think, in your bind you are biding to an IP, use htonl(INADDRY_ANY) as s_addr.
not sure whether this helps your cause, but it seems to solve my problem.