.gradle folder in project

Using gradlew with gradle 2.13. So I noticed that there is a .gradle folder in both my project and my home folder. For some reason, having the project .gradle folder is causing an odd issue with my build. I have a complicated gradle build script that downloads artifacts from a repository and package them into an AAR file but the first time the build ran, it didn’t include the downloaded artifacts and there is no build error. The same exact build command ran the 2nd time will include the artifacts. Has anyone seen this problem before?

The .gradle folder in your project has always been there. It is known as the project-cache-dir and can be overridden form the command-line.

I suspect the issue you are seeing has nothing to do with it, unless you accidentaly include it in your archive.

The behaviour you are mentioning is typical when one task depends on the output of another, but the de[ency has not been declared properly or the inputs of the second task are finalised prematurely.

I should clarify I am helping debug a fellow developer’s complex gradle issue, so I am still learning what the build script is doing. I discovered that the project build.gradle depends on gradle intermediate build paths like build/outputs/aar to store additional files that needed to be included in the final aar. This isn’t ideal as gradle may have changed how they handled the intermediate build steps and somehow clean out the additional files only on the 1st build and not subsequent builds. BTW, is there a reliable way to create a fat aar that includes files from an external source? I googled but couldn’t find a reliable way to do this still it seems. Any input is much appreciated. Thanks.

I cannot help with the AAR question, but may @Ken_Kousen, author of Gradle Recipes for Android, will know

thanks for your help @Schalk_Cronje. @Ken_Kousen if you have any tips, I would greatly appreciate it.

AAR files are like regular Java library dependencies, except that they include other Android dependencies like resource files and/or merged manifest info. If you were to create an Android Library from scratch using the wizard in Android Studio, it would add another module to your existing project with its own build file, and the top level settings.gradle file would show it as a subproject.

If your project depends on an existing aar file, then using it is much like adding another Java library dependency – it’s listed in your build.gradle file in the dependencies block. The hope then is that it’s already complete and self-contained, so any dependencies it needs are already bundled in. It’s hard to tell from your question, but that may be the issue with the lack of dependencies which are then filled in on the second build.

Either way, I agree with @Schalk_Cronje that I doubt the .gradle folder has anything to do with your issue.

Personally, I’ve used Android projects that had the additional Android Library project included in the source, and those have worked without a problem. I had one case where a client supplied an AAR file, and everything worked except for the manifest merger, which is supposedly fixed in the latest version of the Gradle plugin for Android.

When you ultimately create the apk, everything is bundled into that, including the aar file dependency. That’s effectively your “fat jar”, if I’m interpreting your question correctly. Deploying the app generates the (debug) apk, but you can always just run one of the Gradle assemble tasks to generate it directly.

Thanks for your feedback. My project needs to download an AAR file from a repo and then include it in the project’s AAR creating a fat AAR to be included in yet another project which then produces an APK. I have tried multiple ways to add the external AAR as a dependency, e.g., using flatDir and dependencies and it would build fine but it does include the external AAR contents as part of the final AAR.

Here’s the code snippet, I am putting the external AAR in libs folder

    dirs 'libs'
dependencies {
    compile 'abc:1.0.0@aar'

I have also tried to add this in dependencies:

compile fileTree(dir: 'libs', include: ['*.aar'])

But I am getting warnings like Only Jar-type local dependencies are supported. Cannot handle: aar. Am I missing something basic?

That should work - we actually use a similar style in the JRuby-Gradle plugin as part of our testing - https://github.com/jruby-gradle/jruby-gradle-plugin/blob/master/jruby-gradle-base-plugin/src/gradleTest/jrubyExec/build.gradle#L12

Agreed, it should work but it doesn’t, like I said it builds just fine but did not include the external AAR into the final AAR and compile fileTree only handles .jar file types, so I am not sure what’s going on. I assume compile is an Android gradle task, it’s not easy to determine which plugin a task belongs to.

You can get a rough idea, by running gradle model, finding your task and then by looking at its namespace and the name of its creator.

However compile is not a task, it is a configuration which is added by JavaBasePlugin.

@Ken_Kousen Got a question on this. If I have three dependencies in my project (1- AAR file in libs folder, 2- AAR file from a maven repo, 3 - Jar file in libs folder).

  1. Will all these dependencies be compiled/treated similarly?
  2. Will the final size of an AAR file include all the dependencies including other AARs and Jars( including from libs, repo etc)
  3. What happens to transitive dependencies and when its compiled to an APK? ( if there is a same dependency xyz in AAR 1 and AAR 2)