How to put my libraries in front of android.jar by editing build.gradle in Android-Studio

Question

First Here\'s my Java Build Path in Eclipse:

These four jars \'common.jar,core

Answer 1

Following script works for me:

allprojects {
    gradle.projectsEvaluated {
       tasks.withType(JavaCompile) {
           options.compilerArgs.add('-Xbootclasspath/p:/mylib.jar')
       }
    }
}

Answer 2

I use the following scenario, the perfect solution!

1. Add your XXX.jar to Library
2. Then change the "Scope" to "Provided"

3. Find this in your project .gradle:

   allprojects { repositories { jcenter() } }

4. Change it to:

   allprojects { repositories { jcenter() } gradle.projectsEvaluated { tasks.withType(JavaCompile) { options.compilerArgs.add('-Xbootclasspath/p:app\\libs\\XXX.jar') } } }

5. In YourApplicationName.iml file, adjust the XXX.jar to top, like this

so, it's ok!

Answer 3

You can't do what you want in Gradle(*), at least for the foreseeable future at the time this is written. A few problems are getting in your way:

• Gradle doesn't do ordering of dependencies in the build classpath the way that Eclipse does, which is what you were doing to put your classes ahead of android.jar. Gradle has the philosophy that you should be explicit about dependencies in your build so what's going on is understandable and repeatable; systems that rely on classpath ordering tend to be subtle and fragile. So what you would need to do is to tell Gradle that your project depends on your custom classes and not android.jar, but the plugin's DSL doesn't give you the means to do that. There's some discussion at http://forums.gradle.org/gradle/topics/classpath_ordering_again and http://www.gradle.org/docs/current/userguide/dependency_management.html
• Another way of looking at it is a reference to android.jar is hardcoded into the Android Gradle plugin, so you can't get at that dependency and replace it with something else.

(*) Having said all that, nothing is impossible -- you could make it work, but you're going to have to hack something together, so it's going to be more trouble-prone than the Eclipse approach, and tougher to maintain in the face of SDK and tooling updates. And when something goes wrong you'll be on your own.

• You could assemble your own custom SDK with your own android.jar.
• You could hack the Android Gradle plugin. This approach would definitely be tough -- the learning curve there is pretty steep, and the code is under heavy development, which would be a maintenance burden as you try to stay up-to-date.

I hesitate to offer much more insight into either of those approaches, partly because I don't know a lot about it and could pretty easily give you bad advice, and partly because I don't want inexperienced developers seeing this to think it's an awesome thing to do. But if you figure it out, it would be very much worthy of writing up, because I've seen this sort of question before, so you're not the only one.