Question on Android Requirements

[emojahedi]

I have a grpc server written in go which serves through a valid https certificate,
and an Android client like the examples but without the usePlaintext(true) part.

The RPC services work fine for Android devices with sdk-version >= 21, but they fail for older devices with this exception:

io.grpc.StatusRuntimeException: UNAVAILABLE: No provided cause
    at io.grpc.Status.asRuntimeException(Status.java:503)
    at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:207)
    at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:140)
    at net.honarnama.nano.AuthServiceGrpc$AuthServiceBlockingStub.createAccount(AuthServiceGrpc.java:290)
    ... app stack
Caused by: javax.net.ssl.SSLHandshakeException: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0xb8adea90: Failure in SSL library, usually a protocol error
error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers available (external/openssl/ssl/s23_clnt.c:486 0xac7ba990:0x00000000)
    at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:448)
    at io.grpc.okhttp.OkHttpProtocolNegotiator.negotiate(OkHttpProtocolNegotiator.java:106)
    at io.grpc.okhttp.OkHttpProtocolNegotiator$AndroidNegotiator.negotiate(OkHttpProtocolNegotiator.java:172)
    at io.grpc.okhttp.OkHttpTlsUpgrader.upgrade(OkHttpTlsUpgrader.java:74)
    at io.grpc.okhttp.OkHttpClientTransport$1.run(OkHttpClientTransport.java:345)
    at io.grpc.internal.SerializingExecutor$TaskRunner.run(SerializingExecutor.java:154)
    ... 3 more
Caused by: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0xb8adea90: Failure in SSL library, usually a protocol error
error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers available (external/openssl/ssl/s23_clnt.c:486 0xac7ba990:0x00000000)
    at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
    at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:405)
    ... 8 more

Using this mechanism I was able to perform the rpc call on an older device, but the suitable Google Play Services version isn't installed on more than half of the devices in my target population. Is there another way to make grpc work on theses devices? Like switching to Netty-based transport? Is there any sample of an android app usig Netty-based transport?

Thanks in advance

[ejona86]

Using the Google Play Services Security Provider is pretty necessary on older devices in order to have ALPN support and be less buggy. I'd recommend using it even on newer devices, because it contains bug fixes.

The provider is https://conscrypt.org/, which you could compile yourself and include in your app. But you will then be shipping BoringSSL with your app which will increase app size.

Netty doesn't help because it would still require a recent TLS implementation.

[emojahedi]

Thank you it was a great help.

[ejona86]

And I should note that we are working on a cronet-based transport (as an alternative to OkHttp, mainly for QUIC support). It would always include its own copy of boringssl, so it would not depend on Google Play Services Security Provider.

[clockzhong]

I got the same error.
I used Python to implement my server. And the Python client could work correctly with it. But my Android client couldn't. Who could tell me why? Thanks!

[clockzhong]

Sorry, I've located the root cause for my issue: I didn't add user permission for my android application.
Just addin the following line into AndroidManifest.xml could fix my issue:

<uses-permission android:name="android.permission.INTERNET" />

[kraghu]

@ericgribkoff I still see this exception on Android devices < 21. Is the cronet based transport is available ? Or Do I have to use the above mechanism using Google Play Services Security Provider ?

[ericgribkoff]

The Cronet transport is not yet available, mainly due to low prioritization. For devices < 21, you should use the Google Play Services Security Provider. If this isn't a viable solution for your target audience, let me know and I can look further into Cronet as an alternative - it's primarily a matter of investigating what it would take to get the Cronet dependencies integrated into gRPC's build system.

[kraghu]

@ericgribkoff I will get back to you on this by the end of this week

[ejona86]

It's also possible to ship conscrypt.org as part of your app (it's the same thing that comes with Android and Google Play Services Security Provider). This used to mean compiling it yourself, but I now see a conscrypt-android aar artifact on Maven Central, so that may be a semi-easy alternative.

[kraghu]

@ejona86 thanks. Unfortunately it is gonna increaseo ur app size in an inefficient way.
@ericgribkoff can you help us on getting cronet with smaller size ? or any alternative to get it working on <21 devices ?

[ejona86]

Cronet should be strictly larger than conscrypt. Both include boringssl, and most of conscrypt's size is from boringssl.

[ericgribkoff]

I experimented with adding Cronet to our interop test app, and it actually clocks in just a little smaller than org.conscrypt:conscrypt-android:1.0.0.RC8. But it's still an increase of ~9-10MB.

Just spoke with @ejona86 and it's probably possible to get a smaller build of Conscrypt if you explore building it yourself. For example, netty-tcnative-boringssl-static includes boringssl and is only ~2.5MB. @kraghu if that kind of size increase is acceptable to your app, that's probably the best (and only) approach I can suggest here.

[ejona86]

I just checked, stripping the Conscrypt binaries cuts their size by ⅘ths. I filed google/conscrypt#266. So I'm seeing proper Conscrypt binaries being at most ½ the size of Cronet binaries.

(Let it be known I'm not against Cronet. But by its nature it would be very strange for it to be smaller than Conscrypt.)