Develop Reference

Xerces in Android Studio

I'm trying to use spring-context in an Android project and have gotten as far as trying to load a context file. I'm getting this error:
Your JAXP provider ... does not support XML Schema. Are you running on Java 1.4 or below with Apache Crimson? Upgrade to Apache Xerces (or Java 1.5) for full XSD support.
I've found partial answers from a couple years ago indicating the fix is to include Xerces in my project.
I'm using Android Studio, which forces me to use Gradle. I can't for the life of me figure out what to use as the classpath to include Xerces in Gradle. Does anyone know what it is? Is Xerces even available to Gradle? Is there some newer, easier fix that I've missed?

Was that the only thing you wanted? :)
'xerces:xercesImpl:2.11.0'

Xerces extends the core library javax.*. Extending core libraries is not allowed in Android. However you can use --core-library to suppress these warnings. However, this is not recommended. For more information see this.
You can overcome this problem by repackaging the needed classes with a tool like JarJar. This has been done in the Xerces-for-Android, wherein the package mf is placed above the "normal" Xerces packages.

java.lang.NoSuchMethodError: org.json.JSONObject.getNames on Android due to conflicting libraries

I am creating a cross platform application in java using libgdx. I am using Json in the core project and was trying to deploy on Android when I received this error:
E/AndroidRuntime(2030): java.lang.NoSuchMethodError: org.json.JSONObject.getNames
I read around and I found out that Android has a built in Json library that uses that same package name as the Json library I added to my core project. The library I use has the getName() method and the Android library has a name() method. Is there a way for me to specify the library I want to use? Alternatively, is there a way for me to ignore the Android library?
Update: I tested accessing the JSON method in my android project using
JSONObject.getNames(TEST);
which should have given me null, but instead gave me the same error.

if you happen to use a lib, that uses the same namespace/package name as another, you are at the mercy of the classloader, which usually picks the first place, where it can find the class by name.
so the easiest way to circumvent this is either to use the same library and version as used on android or move your library in another package.
if the library in question allows it (licence etc) and is reasonable small, you might be easier off just pulling in the source files in your project and let the IDE do the refactoring magic. Also there are tools like jarjar.
There are some question on SO (Calling same Method having same packageName From Different JARs, Java, Classpath, Classloading => Multiple Versions of the same jar/project). So you might be able to circumvent this problem, but my gut feeling is, that you will end up in big mess.

Xamarin java binding ignores support jar

I need to use http://viewpagerindicator.com/ to add static tabs below the actionbar on a Xamarin.Android project.
I downloaded the project and migrated it from maven to gradle to build it into an AAR file suitable for Xamarin consumption. I created a java binding project, added the AAR file as a LibraryProjectZip and added the v13 support jar as a ReferenceJar but it seems it is being lost somewhere in the way as evidenced by these xbuild logs:
BINDINGSGENERATOR: warning BG8C00: For type Com.Viewpagerindicator.IPageIndicator, base interface android.support.v4.view.ViewPager.OnPageChangeListener does not exist.
BINDINGSGENERATOR: warning BG8800: Unknown parameter type android.support.v4.view.ViewPager.OnPageChangeListener in method SetOnPageChangeListener in managed type Com.Viewpagerindicator.IPageIndicator
BINDINGSGENERATOR: warning BG8800: Unknown parameter type android.support.v4.view.ViewPager in method SetViewPager in managed type Com.Viewpagerindicator.IPageIndicator
The warnings chain continues for a long time, ending the process with a severely limited port
as the missing types make the methods depending on them to vanish away.
If i remove the support jar, the build fails because of missing classes from a utility named jar2xml, leading me to believe it is only used for part of the compilation/mapping process.
The support jar was taken from an unmodified android sdk at extras/android/support/v13/android-support-v13.jar.
Any help is most welcome.

There is a workaround to make these things work.
In my example, I had 2 reference jars (android-support-v4.jar and google-play-services.jar).
So if you just add these 2 jars with Build Action = ReferenceJar, you will see same errors as you posted.
BINDINGSGENERATOR: warning BG8800: Unknown parameter type com.google.android.gms.maps.model.Marker in managed type Com.Google.Maps.Android.MarkerManager.
Though the Marker and MarkerManager classes are defined in the jars, they're not getting resolved correctly on the C# side. To fix that you need to do is to just add already compiled C# bindings for these jars as references.
In my case I used Xamarin.GooglePlayServices package which had a dependency Xamarin.Android.Support.v4 (exactly as my jars).
In your case, you just need to add Xamarin.Android.Support.v4 package to your binding project.
In the end you will have something like this in your project structure:
Hope that helps!

changing or upgrading built-in org.json libraries, is possible and a good idea?

My application depends a lot on the JSON library org.json.*. This package is built-in into Android standard libraries, something I didn't know because I also included it in my source tree.
I need to use a function (JSONArray.remove) that is not supported on the built-in package, while it is in the source distribution jar from org.json (that I include in my project). So what happens is, everything compiles & all, but I get java.lang.NoSuchMethodError: org.json.JSONArray.remove at runtime.
My question is, how can I tell eclipse or Android to use the org.json.* from my source tree instead of its built-in version?
And a sub-question: Is it a good idea at all? May the built-in JSON package have native-level improvements or something like that vs. the official source code distribution?

My question is, how can I tell eclipse or Android to use the org.json.* from my source tree instead of its built-in version?
You can't. You do not control the runtime classpath, and the firmware always wins.
You are welcome to use jarjar or a similar tool to move your copy of the org.json classes into a new package. Or, find a better JSON library -- there's lots of them out there.

java.lang.NoSuchMethodError for method on the build path

I have a basic Android project created in Eclipse Indigo. I have a third-party library on my build path, and it is called is used when I instantiate a class from that library in my initial activity.
Although the app build just fine, I encounter the following error:
10-02 19:51:17.311: ERROR/AndroidRuntime(314): java.lang.NoSuchMethodError: org.apache.http.conn.scheme.Scheme.<init>
Earlier in logcat, I do observe the following error message:
10-02 19:50:48.670: DEBUG/dalvikvm(295): DexOpt: not verifying 'Lorg/apache/http/conn/scheme/Scheme;': multiple definitions
This class is included in the third-party JAR; is it used by Android somehow/somewhere to suggest a conflict or other source of "multiple definitions?"
Thanks!

How does one reconcile the conflict - do I have crack open the third-party JAR and exclude the conflicting files?
My guess is that this would not help, though you can certainly try it. Somebody would appear to be trying to call a method on Scheme that perhaps exists in the JAR's own private copy of that class but is not in the Android SDK.
If the third-party JAR in question is Apache HttpClient, simply don't put that JAR in your build path, as HttpClient is already part of Android, and stick to methods that are in the SDK. If the third-party JAR is not Apache HttpClient, I suspect that once you remove their duplicate org.apache.http classes, that something else will break that depended on their own private version of those classes. If that is the case, you should probably take it up with the third-party developer directly, to work with them on Android support for their JAR. You might be able to use tools like jarjar to get past this, but I would not count on it.

You can try something like jarjar, it can break open the jars and rename the packages to a different path at build time. This avoids conflicts like the ones you're having. I'm just not sure it will work with Android.