Develop Reference

How to fix a "java.io.IOException: unexpected end of stream on Connection" exception in HTTPClient on .NetStandard

I have been scratching my head with this one for a while. I'm building an Android app in Xamarin and I have a login POST request that mostly works, but will occasionally recieve this error. I notify the user and tell them to try again but I am still getting the error far too often and want to fix it so the app provides a smoother experience.
Here is the stack trace I have logged on App Center:
LoginProvider+d__1.MoveNext () C:\source\repos{MyApp}{MyApp}{MyApp}\Services\LoginProvider.cs:35
java.io.IOException: unexpected end of stream on Connection{testclarity.i-menzies.com:443, proxy=DIRECT# hostAddress=62.244.173.166 cipherSuite=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 protocol=http/1.1} (recycle count=0)
com.android.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:210)
com.android.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
com.android.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:905)
com.android.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:789)
com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:443)
com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:388)
com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:501)
com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:105)
com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:25)
Caused by: java.io.EOFException: \n not found: size=0 content=...
com.android.okhttp.okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:200)
com.android.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:191)
I am using .NETStandard 2.0, with Xamarin Forms 3.2.0.871581.
I have scoured most of Google and identified that this is an issue with various Android libraries, especially OkHttp (the same one mentioned in my stack trace). I've tried investigating the .NETStandard source on Github to identify the possible cause, but I find the project very difficult to navigate, especially as this problem seems to be Android specific. Any advice on finding the right source would be ideal.
Things I have tried based on suggestions from the internet:
Setting my connection header to closed.
Setting my transfer encoding
to chunked.
Swapping out the Android HttpClient implementation from
Android to Default in the Android project's properties.
These seem to be among the popular suggestions online, some of which work for people, some of which don't.
Another common suggestion is setting the OkHttp library's configuration to OkHTTP.setRetryOnConnectionFailure(true), which apparently fixes the problem for many people, as suggested here: https://github.com/square/okhttp/issues/1517#issuecomment-144069139.
Also, a similar bug seems to have been filed in Xamarin.Android here: https://bugzilla.xamarin.com/show_bug.cgi?id=41100. But this has been marked as fixed. I'm not sure whether this would feed into my Xamarin Forms project.
Does anyone know how I can fix this problem or how I can investigate further beyond what I've already tried?

After following the information in this link: https://learn.microsoft.com/en-us/xamarin/android/app-fundamentals/http-stack?tabs=macos
And changing my HTTPHandler to the native android handler:
The Xamarin.Android HttpClient configuration is in Project Options >
Android Options, then click the Advanced Options button.
These are the recommended settings for TLS 1.2 support:
Visual Studio Android Options
The one extra bit I missed was:
Projects must reference the System.Net.Http assembly.
Make sure your project references System.Net.Http otherwise it will still use OKHttp

You can just go the Android Project > Properties > AssemblyInfo.cs file.
Open the AssemblyInfo file and add the following line at the end:
[assembly: Application(UsesCleartextTraffic = true)]
This helped me solve my problem. I hope it helps you also

I was having the same issue and been tracing for this fix. My project reference
to System.Net.Http.
I was changing my HTTPHandler to the native android handler when I got this exception but getting kinda similar system exception when using a different HTTPHandler.
I tried a lot of suggestions and finally fixes the issue by using https in my base URL. Here's my reference: https://github.com/square/okhttp/issues/1517#issuecomment-560486265
IMO, the fix might be different in each case, so you might want to try other suggestions.

Does logback-android support DBAppender?

The android implementation of logback appears to be missing the DBAppender class.
Here's my relevant logback appender config, located in assets/logback.xml.
<appender name="DB" class="ch.qos.logback.classic.db.DBAppender">
<connectionSource class="ch.qos.logback.core.db.DriverManagerConnectionSource">
<driverClass>com.mysql.jdbc.Driver</driverClass>
<url>jdbc:mysql://10.2.2.222:3306/logback</url>
<user>username</user>
<password>thepassword</password>
</connectionSource>
</appender>
And gradle:
implementation 'org.slf4j:slf4j-api:1.7.25'
implementation 'com.github.tony19:logback-android:1.1.1-12'
and the resulting error in my logcat:
20:40:50,225 |-ERROR in ch.qos.logback.core.joran.action.AppenderAction -
Could not create an Appender of type [ch.qos.logback.classic.db.DBAppender].
ch.qos.logback.core.util.DynamicClassLoadingException:
Failed to instantiate type ch.qos.logback.classic.db.DBAppender
at ch.qos.logback.core.util.DynamicClassLoadingException:
Failed to instantiate type ch.qos.logback.classic.db.DBAppender
and
Caused by: ch.qos.logback.core.util.DynamicClassLoadingException:
Failed to instantiate type ch.qos.logback.classic.db.DBAppender
and
Caused by: java.lang.ClassNotFoundException:
Didn't find class "ch.qos.logback.classic.db.DBAppender"
Logback is properly working otherwise, if I comment out the database stuff and just have it log to a file, it instantiates correctly and generates text in the log file.
I've found examples of people using the DBAppender, but haven't found any that appear to be android based.
ps: I've also tried the other option, DataSourceConnectionSource (as opposed to the shown DriverManagerConnectionSource) but it actually uses the same appender, and so has the same error as a result. I also can't find any references to to DBAppender in the github files.

logback-android currently does not support DBAppender, and there are no firm plans to carry over that feature. The only database appender supported is SQLiteAppender.
It should be relatively simple to pull DBAppender's relevant source from logback into its own library that could be used in logback-android. For a future major release, I plan on splitting out several built-in appenders in this way to minimize the library size.

Spotify API crashing because of Library issue

I had been working with the SpotifyAPI for a long time, but randomly it just started to crash on me whenever it trys to load the player. Here is the error I get
12-22 20:20:01.995 28130-28130/com.skyrealm.brockyy.spotifyapi E/AndroidRuntime: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.skyrealm.brockyy.spotifyapi-2/base.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]] couldn't find "libgnustl_shared.so"
The line of code that I get this error in is
Spotify.getPlayer(playerConfig, this, new Player.InitializationObserver() {
Thank you for your time!
- Rockyfish

I think you might have just hit the 64k method limit
This is when the amount of code you have (including libraries) is more than Android usually packs into a dex file aka your apk. There is a solution
Try this to resolve the solution:
http://developer.android.com/tools/building/multidex.html
fyi it's sad when you hit this limit :-( and usually there is usused code in your project that could do with pruning to tidy it up (including unused library code).
The other possibility is you're writie native (NDK) code, and I can't help you so much with that :)

"trouble writing output: Too many field references: 70185; max is 65536. You may try using --multi-dex option." when building Android project

I hit this error and found no hits for the error message, so I thought I'd share the solution I came up with to save anyone else facing the problem repeating my work.
When writing a new Android library (apklib) for use in a (large) application, I'm getting the following error during dexing when I add my new project as a dependency:
trouble writing output: Too many field references: 70185; max is 65536.
You may try using --multi-dex option.
References by package:
<...long list of packages with field counts elided...>
The particular build step it fails on is:
java -jar $ANDROID_SDK/build-tools/19.0.3/lib/dx.jar --dex \
--output=$PROJECT_HOME/target/classes.dex \
<... long list of apklib and jar dependencies elided ...>
Using --multi-dex as recommended by the error message might be a solution, but I'm not the owner of the application project and it already has a large complex build process that I would hesitate to change regardless.
I can reproduce this problem with a no-op test library project that has literally no fields, but in the error output it's listed as having 6000+ fields. Of the packages listed in the error output, there are a handful with similar 6k+ field counts, but then the vast majority have more plausible <1k field counts.
This problem is similar to the "Too many methods" problem that Facebook famously hacked their way around. The FB solution seems insane, and the only other solutions I've found (e.g., this Android bug ticket, or this one, this SO answer, this other SO answer) all involve changing the main app's code which is well beyond the scope of what I want to do.
Is there any other solution?

The solution was to change the package in the AndroidManifest to match the main application's package.
A manifest like this:
<manifest package="com.example.testlibrary" ...
resulted in 6k+ fields and build failure. Changing it to match the main application's package
<manifest package="com.example.mainapplication" ...
resulted in the project building successfully.
Note that only the package in the manifest is changing, I did not make any changes to the library's Java source or its layout (the Java package was still com.example.testlibrary with directory structure to match).
I hypothesize that the different package name is causing all the Android fields to be included again under that package. All the packages in the error listing with 6k+ fields had a different package name than the main application.
I also (later, grr), found this blog post which details the same problem and the eventual same solution.

Is there a way to make DexGuard exit with an error condition if an error occurs?

I'm currently building an android application using ANT on a Jenkins server.
DexGuard is set to run on release in the custom_rules.xml.
Currently there is an issue when DexGuard tries to convert a method:
[dexguard] Unexpected error while converting:
[dexguard] Class = [o/?]
[dexguard] Method = [?(Ljava/lang/String;)Lo/?;]
[dexguard] Exception = [java.lang.IllegalStateException] (Variable v17 too large for instruction [neg-int v17, v17])
[dexguard] java.lang.IllegalStateException: Variable v17 too large for instruction [neg-int v17, v17]
...
Stack trace
...
[dexguard] Not converting this method
My question is, is there a way to get DexGuard to exit with an error status so that either ANT or Jenkins can mark the build as failed?
At the moment it simply prints the stack trace and continues.
I am currently using the Text-finder plugin for Jenkins as a post build step to match a DexGuard exception. If found it downgrades the build to failed.

DexGuard currently ignores methods that it can't convert from Java bytecode to Dalvik bytecode, for any reason -- notably corrupt input code. In this case, it looks more like a bug in DexGuard itself. We'll fix it as soon as possible, and we'll consider adding a flag to stop with an error status.
(I am the lead developer of ProGuard and DexGuard)