I was trying to open cache.properties.lock file present in .gradle
and suddenly Android Studio got crashed with Incompatible magic error popup.
How to fix this issue? No idea.
I also struggled with this issue a lot while we were sending JAVA classes in an enterprise - this is primarily caused when class (compiled) classes that are sent over mails as attachments and the proxy servers tampers with the content.
This can happen when using a proxy server, and especially when the CLASS files were sent as .TXT extensions to avoid PROXY/FIREWALL blockings to secured enterprise environments.
Related
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.
Migrated application from 6.2 to 7.0. Server MobileFirst version: 7.0.0.00.20150312-0731
The application itself works great. When push new wlapp to server, the device see's update is available. Proceed to install update and fails.
logCat
W/PluginManager(11315): THREAD WARNING: exec() call to WLDirectUpdatePlugin.start blocked the main thread for 20ms. Plugin should use CordovaInterface.getThreadPool().
W/HardwareRenderer(11315): Attempting to initialize hardware acceleration outside of the main thread, aborting
W/PluginManager(11315): THREAD WARNING: exec() call to WLDirectUpdatePlugin.showProgressDialog blocked the main thread for 44ms. Plugin should use CordovaInterface.getThreadPool().
E/com.worklight.androidgap.directupdate.WLDirectUpdateDownloader( 9466): WLDirectUpdateDownloader.validateZipFileIntegrity in WLDirectUpdateDownloader.java:129 :: Invalid direct update zip file, original file might have been altered or replaced.
7.0.0.00.20150312-0731 is an awfully old build of MFPF 7.0; many fixes, including to Direct Update took place since.
I suggest that you will update to latest available iFix from IBM Fix Central to confirm this issue still happens to you.
This is an issue in which the content type of returned direct update zip is not "application/zip" as it should be.
Note that Worklight server returns "application/zip" content type for android direct update. We have a test fix right now where we just log the different content type and continue the direct update process since it can be correct zip and content type can be changed by firewall for example.
If you create a PMR, we can give you a test fix to test (just drop worklight-android.jar into Android project -> deploy onto device). Once we confirm that it works we can deliver it to production builds. When submitting the PMR please link them to this StackOverflow question to give full background of issue.
So I want to build an extensible android application where developers can add 'CustomDevice' classes and the main program will run them automatically without editing existing code.
I've read about Service Provider interface and thought that would be a nice way to go about it.
So I tested it and created an interface called 'ICustomDevice' which custom device classes are expected to implement.
I've created a class called 'DummyDevice' that implements ICustomDevice.
Both DummyDevice and ICustomDevice are in the same package "CustomDevicePackage".
So in my main program I run the following.
ServiceLoader<ICustomDevice> loader = ServiceLoader.load(ICustomDevice.class);
Iterator<ICustomDevice> devices = loader.iterator();
System.out.println("Does it have devices? " + devices.hasNext());
It always returns false, which means it's not finding the 'DummyDevice'
In my eclipse project I created a folder at 'src' called META-INF and under it, a subfolder called 'services'.
'Services' has a file named 'CustomDevicePackage.ICustomDevice' with a line of content 'CustomDevicePackage.DummyDevice'.
Am I doing it right? Every example I see about SPI is about loading JARS.
I'm not loading a JAR, I'm trying to run a class in the same Project. Does this method only works for loading JARs? I want my program to support loading local subclasses and external JARs alike.
I am adding this as an answer but leaving the prior "answer" to provide extended code detail for this workaround. I am working on reporting the prior answer results as a bug to Google.
Because the Android implementation of java.util.ServiceLoader is broken (always populating internal java.security.AccessControlContext field with AccessController.getContext() even if System.getSecurityManager() == null), the workaround is to create your own ServiceLoader class by copying the code found at OpenJDK for Java 8 into your class, add specific imports required from java.util without using import java.util.*;, and call that ServiceLoader in your code (you will have to fully reference the ServiceLoader you created to over ambiguity).
This isn't elegant but it is a functional workaround that works! Also, you will need to use a ClassLoader in your ServiceLoader.load() call. That ClassLoader will either have to be YourClass.class.getClassLoader() or a child ClassLoader of the class' ClassLoader.
Though it's an old post, This may be still be of some help to others:
When I was running or debugging a project that contained a ServiceLoader Class, I had to put the META-INF/services folder into the src/ folder in Eclipse.
If I tried to export the project as Runnable jar and tried to use the class with the service loader, it never worked.
When I checked the jar, unzipping it, I found the folder under src/META-INF/services though.
Only when I also added the META-INF folder directly in the root directory of the jar, it started to work.
I haven't found a fix though inside Eclipse, that makes sure it gets exported right...maybe an ANT script can solve this issue, but so far no attempts made...
This is an answer:
At some point, Android removed the AccessControlContext field in ServiceLoader and ServiceLoader now works. As my comments indicate, this was reproduceable using the "out-of-the-box" OREO (API 26) Intel Atom x86 emulator with Android Studio (also fresh download). 24 hours later, ServiceLoader no longer contained the acc field (as shown in the Android Studio debugger with the same emulator). The Android SDKs dating back to API 24 do not show the acc field.
Per the Android developer currently maintaining the ServiceLoader code:
He is not aware of ServiceLoader ever having the acc field in Android (it did as we were able to reproduce) and thought the debugger/emulator might have been using JDK code (but I showed the OpenJDK code works correctly). Somewhere along the way, the errant code was updated and I am no longer able to reproduce.
Be sure your OS is up-to-date and you should no longer see this phenomena.
I have a BIXOLON mobile printer, I can print by this device in windows mobile programs.
I want to print by this device in MONODOIRD applicaiton...
there is sdk, but the lib that use that sdk is java...
is any body know how can I print by this device in monodroid?!
Is your "lib" is a .jar file? If it is, bind it, which will make it accessible from C#.
after I read xamarin help about bindding jar file, I get some errors....
I listed in the end of this post...
I need this jar file compile completly...
Warning 1 missing class error was raised while reflecting com.bixolon.android.library.BxlService : android/hardware/usb/UsbManager
Warning 2 missing class error was raised while reflecting
com.bixolon.android.library.UsbLauncher : android/hardware/usb/UsbManager
Warning 3 For ConnectThread, could not find enclosing type 'BxlService'.
Warning 4 For ConnectThread, could not find enclosing type 'BxlService'.
Warning 5 For ConnectedThread, could not find enclosing type 'BxlService'.
Warning 6 For ConnectedThread, could not find enclosing type 'BxlService'.
The conversion of my Android application to the iPhone ObjectX environment as described in the XMLVM user manual works almost fine on my MAC, but I end up with 3 errors in the resulting XCode:
The first two errors simply relate to missing files, namely:
org_w3c_dom_Node.h
android_app_DatePickerDialog_OnDateSetListener.h
These are clearly not files from the converted Android application. Where can I get these from?
The third is an error that keeps coming up in the file
java_lang_String.h
The error message is:
typedef NSMutableString java_lang_String: redefinition as different kind of symbol
This error has been reported before in the XMLVM user group but as far as I know has never been answered sufficiently.
About the first error:
this is part of the Android API that has not yet been implemented.
This is the reason why it can't find the files.
Now, the second problem is not actually an error, but a warning and shouldn't stop you form compiling.
If it does, it means that in your project you have set the option to make errors from these types of warnings.
You can safely turn this off and completely ignore this warning.