ppzhou1984 / gradle-android-plugin Goto Github PK

On my journey to develop a shared Android library project, I found that while 
there is some support for building projects with Gradle that depend on Android 
library projects, it's quite awkward and requires one to straighten out some of 
its rough edges.

The problem is this:

While we use the Android Ant task to build the APK (which means we get all the 
benefits like mashing the lib project resources into the app APK), there is no 
standard Ant task that we can re-use for the rest. The rest is making sure that 
the lib project's class files and library dependencies also end up being merged 
into classes.dex (that's before the APK is assembled).

Currently this *somewhat* works, because what you can do is simply declaring a 
normal Gradle compile dependency (plus transitives) on the lib JAR, so the 
classes will be added to classes.dex. However, this is awkward for two reasons:

1) even tho you declare a dependency to an artifact from a remote repository, 
you still need the source code sitting next to your app project, since the APK 
builder will use a relative path to lookup up the library resource files. This 
raises the question: why not also use the sources then, too? That's in fact wha 
the ADT and the Android Ant tasks do, they compile the library project straight 
into your own app.

2) with a compile dependency on your Gradle classpath, the Eclipse enhancement 
will break. That's because eclipseClasspath will add the classes (including 
R.class) from the JAR file to the project's classpath, but since in Eclipse the 
ADT already create an Eclipse symlink to the lib project's source code, you 
will end up having the library's R class twice on the classpath, and this will 
break the dexer. As a workaround, you can add this to your Gradle script:

eclipseClasspath {
  whenConfigured { classpath ->
    classpath.entries.removeAll { it.endsWith(<library-JAR-name>) }
  }
}

that makes sure that the Gradle build will see the library classes from the 
JAR, while Eclipse/ADT will see library classes by linking the source code 
straight into your app project.

I think we should modify the plugin to work like ADT and Android Ant do, i.e. 
by not requiring the user to declare a dependency to the library JAR, and 
instead add the lib's src folder to the compile classpath. Similarly, the lib's 
own library dependencies must be added, too.

What steps will reproduce the problem?
1. Create a simple project and declare xstream as a compile dependency
2. Execute gradle assemble

What is the expected output? What do you see instead?
Expected: The APK file is generated
Actual: The following error occurs

[ant:apply] trouble processing "javax/xml/stream/events/StartElement.class":
[ant:apply] 
[ant:apply] Ill-advised or mistaken usage of a core class (java.* or javax.*)
[ant:apply] when not building a core library.
[ant:apply] 
[ant:apply] This is often due to inadvertently including a core library file
[ant:apply] in your application's project, when using an IDE (such as
[ant:apply] Eclipse). If you are sure you're not intentionally defining a
[ant:apply] core class, then this is the most likely explanation of what's
[ant:apply] going on.
[ant:apply] 
[ant:apply] However, you might actually be trying to define a class in a core
[ant:apply] namespace, the source of which you may have taken, for example,
[ant:apply] from a non-Android virtual machine project. This will most
[ant:apply] assuredly not work. At a minimum, it jeopardizes the
[ant:apply] compatibility of your app with future versions of the platform.
[ant:apply] It is also often of questionable legality.
[ant:apply] 
[ant:apply] If you really intend to build a core library -- which is only
[ant:apply] appropriate as part of creating a full virtual machine
[ant:apply] distribution, as opposed to compiling an application -- then use
[ant:apply] the "--core-library" option to suppress this error message.
[ant:apply] 
[ant:apply] If you go ahead and use "--core-library" but are in fact
[ant:apply] building an application, then be forewarned that your application
[ant:apply] will still fail to build or run, at some point. Please be
[ant:apply] prepared for angry customers who find, for example, that your
[ant:apply] application ceases to function once they upgrade their operating
[ant:apply] system. You will be to blame for this problem.
[ant:apply] 
[ant:apply] If you are legitimately using some code that happens to be in a
[ant:apply] core package, then the easiest safe alternative you have is to
[ant:apply] repackage that code. That is, move the classes in question into
[ant:apply] your own package namespace. This means that they will never be in
[ant:apply] conflict with core system classes. JarJar is a tool that may help
[ant:apply] you in this endeavor. If you find that you cannot do this, then
[ant:apply] that is an indication that the path you are on will ultimately
[ant:apply] lead to pain, suffering, grief, and lamentation.
[ant:apply] 
[ant:apply] 1 error; aborting

What version of the product are you using? On what operating system?
Followed instructions on GitHub Wiki. Windows 7. Gradle Milestone 3.

Please provide any additional information below.

I found this post which describes the same problem I am having. Apparently 
Android does not like something about the way xstream is packaged, 
http://stackoverflow.com/questions/3454157/my-android-app-is-getting-the-trouble
-processing-error.

Is there some way a hook can be added so I can set the flag ("--core-library") 
that the error message is referring to?

For a pre-cursor to this, see 
https://github.com/jvoegele/gradle-android-plugin/issues/#issue/11

affects gradle-android 0.9.7

The problem is that even though I define dependencies in my gradle build file, 
the APK ends up being created without them. This results in 
ClassNotFoundExceptions at app runtime.

My project is a multi-module build:
:qype-android
  :qype-app
  :qype-tests-jvm
  :qype-tests-instrumentation

build.gradle for qype-app:

apply from: '../android.gradle'

sourceSets {
    main {
        java {
            srcDir 'src'
        }
    }
}

dependencies {
    compile fileTree(dir: 'lib', includes: ['*.jar'])

    compile 'com.github.droidfu:droid-fu:1.0-SNAPSHOT'
    compile 'oauth.signpost:signpost-core:1.2.1.2'
    compile 'oauth.signpost:signpost-commonshttp4:1.2.1.2'
}

NOTE that compilation works fine -- it's just that the class files are missing 
at runtime. I found this in gradle-android/AndroidPackageTask to look 
suspicious:

  private void createPackage(boolean sign) {
    logger.info("Converting compiled files and external libraries into ${androidConvention.intermediateDexFile}...")
    ant.apply(executable: ant.dx, failonerror: true, parallel: true) {
      arg(value: "--dex")
      arg(value: "--output=${androidConvention.intermediateDexFile}")
      if (verbose) arg(line: "--verbose")
      fileset(file: getJarArchivePath())
    }

    logger.info("Packaging resources")
    sdkTools.aaptexec.execute(command: 'package')
    sdkTools.apkbuilder.execute('sign': sign, 'verbose': verbose)
  }

fileset(file: getJarArchivePath()) does not look as if it actually bakes 
anything into classes.dex other than what's in the libs/ dir, but maybe I'm 
just missing something. In any case, the build doesn't work.

I've downloaded v0.9.9 and this task appears to be missing. 

I have a project with a dependency to Google Apis: it uses maps.jar (located in 
$ANDROID_HOME/add-ons/addon_google_apis_google_inc_7/libs).

When I run the Proguard task (both directly and as part of the whole build 
process), I get the error "cannot find common class of Class1 and Class2", 
where one of the classes is derived from class present in maps.jar.

Digging into the gradle-android-plugin I've noticed in the Proguard task code 
that the libraryjar parameter contains only the android.jar file. But even 
adding directly the maps.jar dependency, the error keeps coming up.

It breaks on my real Android project, but on a very simple one it works.

Right now, if you run gradle tasks, all Android related tasks show up as 
"other". This is quite messy. I vote for having all tasks exposed by 
gradle-android-plugin be assigned the 'Android' group, i.e. for all tasks we 
should task.group = "Android".

I can't get the Instrumentationtests working (with 1.0.0-SNAPSHOT).

Is there any example project for this?

Should i use two projects or one with src/test/...?

The documentation is very small for this point.

Thanks

What steps will reproduce the problem?
1. executing gradle commands 
2.
3.

What is the expected output? What do you see instead?
{{{
FAILURE: Build failed with an exception.

* What went wrong:
Could not find group:org.gradle.api.plugins, module:gradle-android-plugin, 
version:1.1.0.
}}}

part of my build.gradle:
{{{
...
buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.gradle.api.plugins:gradle-android-plugin:1.1.0'
    }
}
...
}}}

What steps will reproduce the problem?
1. create a gradle build file for a android project following android's source 
layout conventions (sources locate in $ROOT/src/
2. Specify the non standard source set location in build.gradle ,as indicated 
in the wiki:

sourceSets {
 main {
    java {
      srcDir 'src'
     }
   }
 }

2. create an aidl file somewhere in the src directory
3. run gradle androidPackage

What is the expected output? What do you see instead?

the plugin looks for aidl files in src/main/java, doesn't find any and hence 
doesn't generate the stubs at all.

a bit of debugging seems to indicate that the overridden source set is not 
found by the plugin. also only the first directory is used, should use the 
first existing directory.

What version of the product are you using? On what operating system?

0.9.9, 1.0.0-SNAPSHOT

Please provide any additional information below.

I have a very basic Android project generated via SDK and a following build 
file:

-------------------------
apply plugin: 'scala'
apply plugin: 'android'

proguard.enabled = true
version = '1.0.0'

buildscript {
  repositories {
    mavenRepo(urls: 'http://jvoegele.com/maven2/')
  }
  dependencies {
    classpath 'com.jvoegele.gradle.plugins:android-plugin:0.9.9'
  }
}

repositories {
    mavenCentral()
}

dependencies {
    scalaTools 'org.scala-lang:scala-compiler:2.8.1'
    scalaTools 'org.scala-lang:scala-library:2.8.1'
    compile 'org.scala-lang:scala-library:2.8.1'
}
-------------------------



What is the expected output? What do you see instead?

The task "androidPackage" fails with "trouble writing output: opcode == null". 
As far as I know, this error usually means that the dex tool has hit some 
internal limit, which is a known problem with the full ("unproguarded") Scala 
library. However this should not be the case if the library is processed with 
ProGuard.

By running gradle with the --info option, I get the following log from ProGuard:

-------------------------
ProGuard, version 4.4
ProGuard is released under the GNU General Public License. The authors of all
programs or plugins that link to it (org.codehaus.groovy.reflection, 
org.gradle.api.internal, groovy.util, groovy.lang, org.gradle.execution, 
org.gradle.initialization, org.codehaus.groovy.runtime, org.gradle.util, 
org.gradle.launcher, com.jvoegele.gradle.tasks.android, ...) therefore
must ensure that these programs carry the GNU General Public License as well.
Reading program jar [.../build/libs/Test-1.0.0.jar]
Reading library jar [.../android-sdk-linux_x86/platforms/android-10/android.jar]
-------------------------

This suggests that the Scala library has not been recognized by ProGuard which 
likely causes the dex generation issues.

Why is Scala library not processed by ProGuard? Is there a configuration step I 
have missed?

I should be testing this code this week as I overwrite the 
androidProcessResources task and put this before the other process resources 
code:

ant.exec(executable: ant.references['aidl'], failover: 'true'){
         arg(value: '-p')
         arg(path: ant.references['android.aidl'])
         arg(value: '-I')
         arg(path: project.tasks.compileJava.source.absolutePath)
         arg(value: '-o')
         arg(path: genDir.absolutePath)
         fileset(dir: 'src'){
             include(name: '** /*.aidl')
         }
     }

basically as:
 // AIDL processing first
     ant.exec(executable: ant.references['aidl'], failover: 'true'){
         arg(value: '-p')
         arg(path: ant.references['android.aidl'])
         arg(value: '-I')
         arg(path: project.tasks.compileJava.source.absolutePath)
         arg(value: '-o')
         arg(path: genDir.absolutePath)
         fileset(dir: 'src'){
             include(name: '** /*.aidl')
         }
     }
     // Process rest of resources
     ant.exec(executable: ant.references.['aapt'], failonerror: 'true') {
         arg(value: 'package')
         if (verbose) arg(line: '-v')
         arg(value: '-m')
         arg(value: '-J')
         arg(path: genDir.absolutePath)
         arg(value: '-M')
         arg(path: androidManifest.absolutePath)
         arg(value: '-S')
         arg(path: resDir.absolutePath)
         arg(value: '-I')
         arg(path: ant.references['android.jar'])
       }
That should handle the AIDL processing

What steps will reproduce the problem?
1. Use Gradle 1.0-milestone-5
2. Use gradle-android-plugin 1.0.0
3. apply plugin: 'eclipse'
4. apply plugin: 'android'
5. gradle eclipse

What is the expected output?

I expect to see a clean output without neither deprecation warnings nor 
exceptions.

Instead I get this:

$ gradle eclipse
Android SDK Tools Revision 13
Project Target: Android 2.1-update1
API level: 7

------------------
Resolving library dependencies:
No library dependencies.

------------------

The sourceSet.classesDir method is deprecated and will be removed in the next 
version of Gradle. You should use the sourceSet.output.classesDir method 
instead.
The DomainObjectCollection.getAll() method is deprecated as 
DomainObjectCollection is now a Collection itself. Simply use the collection.
The DomainObjectCollection.findAll() method is deprecated as 
DomainObjectCollection is now a Collection itself. Use the matching(Spec) 
method.
<someIdeTask>.beforeConfigured is deprecated! Replaced by beforeMerged() method 
placed on the relevant model object of eclipse/idea.
As a starting point, refer to the dsl guide for IdeaProject or EclipseProject.
For example, ideaProject.beforeConfigured was changed to 
idea.project.ipr.beforeMerged
:app:eclipseClasspath
The eclipseClasspath.containers method is deprecated and will be removed in the 
next version of Gradle. You should use the eclipse.classpath.containers method 
instead.
The eclipseClasspath.sourceSets method is deprecated and will be removed in the 
next version of Gradle. You should use the eclipse.classpath.sourceSets method 
instead.
:app:eclipseJdt
:app:eclipseProject
The eclipseProject.natures method is deprecated and will be removed in the next 
version of Gradle. You should use the eclipse.project.natures method instead.
The eclipseProject.buildCommands method is deprecated and will be removed in 
the next version of Gradle. You should use the eclipse.project.buildCommands 
method instead.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:eclipseProject'.
Cause: Failed to notify action.
Cause: java.lang.NoClassDefFoundError: 
org.gradle.plugins.eclipse.model.BuildCommand
Cause: org.gradle.plugins.eclipse.model.BuildCommand

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.

BUILD FAILED

Total time: 8.712 secs

What version of the product are you using? On what operating system?
Gradle 1.0-milestone-5
gradle-android-plugin 1.0.0
android-sdk-linux_x86 R13
Ubuntu 11.10

Additional info:

It works with gradle-android-plugin:0.9.9, but with the following deprecation 
warnings:

The sourceSet.classesDir method is deprecated and will be removed in the next 
version of Gradle. You should use the sourceSet.output.classesDir method 
instead.
The DomainObjectCollection.getAll() method is deprecated as 
DomainObjectCollection is now a Collection itself. Simply use the collection.
The DomainObjectCollection.findAll() method is deprecated as 
DomainObjectCollection is now a Collection itself. Use the matching(Spec) 
method.
:app:eclipseClasspath
:app:eclipseJdt
:app:eclipseProject
:app:eclipse

BUILD SUCCESSFUL

So far I've been able to do most things. The one thing that I've not figured 
out yet is how to start and stop an emulator during a build. This stops me 
doing a full CI cycle.

Any chance a start/stop emulator task is under development?

What steps will reproduce the problem?
1. Install android SDK r15 
(http://dl.google.com/android/android-sdk_r15-linux.tgz)
2. Install gradle 1.0-milestone-5 
(http://repo.gradle.org/gradle/distributions/gradle-1.0-milestone-5-all.zip)
3. Create a sample android project as per the Android plugin wiki ($ android 
create project --target 2 --path ./MyAndroidApp --activity MyAndroidActivity 
--package my.android.package)
4. Create a build.gradle file as per the Android plugin wiki w/ latest 
available version of plugin (1.0.0)
buildscript {
  repositories {
    mavenRepo(urls: 'http://jvoegele.com/maven2/')
  }
  dependencies {
    classpath 'com.jvoegele.gradle.plugins:android-plugin:1.0.0'
  }
}
apply plugin: 'android'
repositories {
    mavenCentral()
}

5. run gradle tasks

What is the expected output? What do you see instead?

I expect to see a list of available gradle tasks, including androidPackage. 
Instead I get the following:

FAILURE: Build failed with an exception.

* Where:
Build file 
'/energizedwork/gus/workspace/android/gradle-sample-project/MyAndroidApp/build.g
radle' line: 9

* What went wrong:
A problem occurred evaluating root project 'MyAndroidApp'.
Cause: 

Error. You are using an obsolete build.xml
You need to delete it and regenerate it using
    android update project



What version of the product are you using? On what operating system?
version 1.0.0 on linux x86_64

Please provide any additional information below.
Linux spinship 2.6.35-zen2 #8 ZEN SMP PREEMPT Thu Feb 17 18:29:06 GMT 2011 
x86_64 Intel(R) Core(TM)2 Duo CPU T9500 @ 2.60GHz GenuineIntel GNU/Linux
Welcome to Gradle 1.0-milestone-5.
Android SDK Manager Revision 15.

I would expect that "gradle cleanEclipse eclipse" tasks would generate all 
necessary project and classpath entries for an Android project, but they don't.

Two things that are missing specifically are:

1) source entry for the gen/ folder (not handled in EclipseEnhancement yet)
2) the Android framework container was not re-added for me when doing a clean 
first (not sure why that is, because it seems to be handled in the 
EclipseEnhancement)

Generally I think the EclipseEnhancement should be re-written by going through 
the configuration DSL that is documented on the official plugin wiki page and 
using hooks like beforeConfigured and whenConfigured rather than modifying the 
task graph directly. For instance:

eclipseClasspath {
   whenConfigured {
      containers 'com.android.ide.eclipse.adt.ANDROID_FRAMEWORK'
   }
}

should have the same effect and is the standard way of doing it.

What steps will reproduce the problem?
1. set proguard.enabled = true
2. assemble the app
3. unzip build/libs/*-unproguarded.jar

What is the expected output? What do you see instead?
I expect to see the same output as when running the build with proguard 
disabled. Instead, about half of the packages in my application are missing in 
this JAR (curiously, some are there...).

What version of the product are you using? On what operating system?
0.9.8-SNAPSHOT, MacOS 10.6

I've had some issues with running the plugin in gradle 1.0 milestone 3. 

I cloned the plugin repo and have been attempting to debug it. 

Firstly I had to correct a package name as I commented in issue #7.

Now I'm up against a wall because I've found that the copying of the test 
results is not working.

Following it through I've found that the issue is that when the plugin attempts 
to build a AdbExec object to do the copy, it's throws a NullPointerException in 
the constructor. I've aded logging code and dumped out this stacktrace:

16:56:53.067 [ERROR] [system.err] java.lang.NullPointerException
16:56:53.068 [ERROR] [system.err]   at 
org.gradle.api.internal.AbstractTask$TaskInfo.access$000(AbstractTask.java:421)
16:56:53.068 [ERROR] [system.err]   at 
org.gradle.api.internal.AbstractTask.<init>(AbstractTask.java:105)
16:56:53.068 [ERROR] [system.err]   at 
org.gradle.api.internal.AbstractTask.<init>(AbstractTask.java:95)
16:56:53.069 [ERROR] [system.err]   at 
org.gradle.api.DefaultTask.<init>(DefaultTask.java:31)
16:56:53.069 [ERROR] [system.err]   at 
com.jvoegele.gradle.tasks.android.AdbExec.<init>(AdbExec.groovy)
16:56:53.069 [ERROR] [system.err]   at 
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
16:56:53.069 [ERROR] [system.err]   at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorI
mpl.java:39)
16:56:53.069 [ERROR] [system.err]   at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorA
ccessorImpl.java:27)
16:56:53.070 [ERROR] [system.err]   at 
java.lang.reflect.Constructor.newInstance(Constructor.java:513)
16:56:53.070 [ERROR] [system.err]   at 
org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:7
7)
16:56:53.074 [ERROR] [system.err]   at 
org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCo
erce.callConstructor(ConstructorSite.java:102)
16:56:53.074 [ERROR] [system.err]   at 
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSi
teArray.java:52)
16:56:53.075 [ERROR] [system.err]   at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCa
llSite.java:190)
16:56:53.075 [ERROR] [system.err]   at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCa
llSite.java:194)
16:56:53.075 [ERROR] [system.err]   at 
com.jvoegele.gradle.tasks.android.instrumentation.InstrumentationTestsTask.publi
shTestReport(InstrumentationTestsTask.groovy:131)
16:56:53.075 [ERROR] [system.err]   at 
com.jvoegele.gradle.tasks.android.instrumentation.InstrumentationTestsTask.this$
5$publishTestReport(InstrumentationTestsTask.groovy)
...

At this stage I cannot figure this out because I have not been able to access a 
version of the gradle source code that matches the line numbers to see what 
might be blank. 

Looking at the source at 
https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/groovy/or
g/gradle/api/internal/AbstractTask.java I would guess the issue is the 
ThreadLocal taskinfo they are using. But thats just a guess at this time.