IssueTracker

Have you tried some kind of packet capture tool such as tcpdump to show what data is making it on to the network from the client and server? If so could you attach it?

This problem is because ready() method of BufferedReader always returns
false with SSLSocket Implementation. I'll use readLine() without asking for
ready() before, but I'll have another problem "readLine()" will block UI
thread. But it's another problem.

El 11 de enero de 2012 16:22, Miguel Rodr�guez <mrodfuentes@gmail.com>escribi�:

Ah BufferedReader.ready() is calling InputStreamReader.ready() is calling OpenSSLSocket$SSLInputStream.available(), which is inherited from InputStream.available() which returns 0 by default (as noted here http://developer.android.com/reference/java/io/InputStream.html#available())

Note especially:

Firstly, the guarantee is "without blocking for more input" rather than "without blocking": a read may still block waiting for I/O to complete — the guarantee is merely that it won't have to wait indefinitely for data to be written. The result of this method should not be used as a license to do I/O on a thread that shouldn't be blocked.

So you probably shouldn't be using ready() to avoid doing I/O on the UI thread, because it doesn't guarantee that.

I have just come across this problem.  However in my case it is purely that .available() is always returning 0 for an SSLSocket.  If I call read() anyway, then I get data values returned.

The default OpenSSLSocketImpl doesn't implement available for its InputStream so it always returns 0.

A workaround for 2.3 and later is to use the SSLSocketImpl implementation. You can do this using SSLContext.getInstance("TLS", "HarmonyJSSE");

or just don't use available. See http://developer.android.com/reference/java/io/InputStream.html#available() for some reasons why.

Hi b... thanks for your workaround.  I'm currently using available as a true/false indicator of whether to attempt to read a message.  Do you have any further information on getting this workaround up and running?
I'm trying the following code (which doesn't load anything into the keystore) and I'm consequently getting a "Not trusted server certificate" exception on handshake.  Is there a way to still use the default keystore?  (Please forgive me if I'm asking a stupid question here)

                                    KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
                                final KeyManagerFactory keyManager = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
                                keyManager.init(keyStore, null);

                                final TrustManagerFactory trustFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
                                trustFactory.init(keyStore);

                                context.init(keyManager.getKeyManagers(), trustFactory.getTrustManagers(), new SecureRandom());
                                        socket = context.getSocketFactory().createSocket();

You can just use context.init(null, null, null) to use the defaults.

I still think you should just use a separate thread to read rather than polling with available. The workaround SSLContext will be a lot slower than the default OpenSSL based one but if you insist another idea is to use the default context with SSLContext.getInstance("TLS"). Then you could use SSLSocketFactory.createSocket to wrap an SSLSocket around a plain Socket:

http://developer.android.com/reference/javax/net/ssl/SSLSocketFactory.html#createSocket(java.net.Socket, java.lang.String, int, boolean)

Then you could call available() on the underlying Socket.

Bulk reassignment of Conscrypt issues.

Thank you for your feedback.  We assure you that we are doing our best to address all issues reported. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with the bug report here https://goo.gl/TbMiIO and reference this bug for context.